MapReduce and Parallel DBMSs Friends or Foes

 

MR架构更像一个ETL（extract-transform-load提取-传输-装载）系统，

它可以即时的快速地装载处理大规模数据，所以说MR是并行数据库的补充。

由A Comparison of Approaches to Large-Scale Data Analysis的benchmark可得一条结论：DBMSs效率要优于MR，但是数据装载开销长于MR。

并行数据库系统：

应用技术：关系表的水平分割和SQL查询的分割执行

水平分割：将表中的行分布到集群中的各个节点上以便并行处理

大多数并行数据库提供分割策略：哈希，排序，循环分割

如哈希分割，当每一行都被装载完成，哈希函数通过行中的一个或多个属性值来决定目标节点及磁盘。

水平分割表的缺点：SQL查询性能缺乏扩展性 =>SQL操作的分割执行

例如：SELECT custId, amount FROM Sales WHERE date BETWEEN “12/1/2009” AND “12/25/2009”;

Select操作将通过多个在存放对应数据的节点上的Select操作的并行执行来实现。每个节点将得到的select结果发到一个单独的节点进行合并操作从而得到查询的最终结果

又例如：SELECT custId, SUM(amount) FROM Sales WHERE date BETWEEN “12/1/2009” AND “12/25/2009” GROUP BY custId;

Sales表是循环分割的。则对应一个customer的行可能会分布在集群的所有节点上。DBMS系统将该查询编译成三个操作：如图a，然后将操作并行执行。每个Select扫描存储在节点上的Sales表片段，将符合要求的行发送到shuffle。Shuffle将这些行通过custID值的hash函数进行重划分，再将它们map到另外的一台机器上进行sum操作。

又例如：SELECT C.name, C.email FROM Customers C, Sales S WHERE C.custId = S.custId AND S.amount > 1000 AND S.date BETWEEN “12/1/2009” AND “12/25/2009”;

假设Sales表是循环分割的。DBMS系统编译这条SQL查询如图B，每个节点上的Select操作扫描满足以下要求的行：

S.amount > 1000 and S.date BETWEEN “12/1/2009” and “12/25/2009.”

所有的结果通过管道传送给Shuffle节点。Shuffle节点通过hash将输入行重分割，然后shuffle节点将每个符合结果的sales行映射到存储对应的customer元组的节点上，使join操作可以并发的执行。

DBMS的另一个好处是：DBMS针对不同的查询自动地管理划分策略

例如：如果sales表和customer表都是在custID属性上hash划分的，查询优化器就会发现两个表在join元组上是hash划分的，然后忽略查询计划中的shuffle操作。然而，如果两个表是循环分割的，查询优化器就会插入shuffle操作使两个表的join操作在同一个节点完成。

Mapping Parallel DBMSs onto MapReduce

MR架构的优势之一是简单。

大略解释了MR架构。作者并指出MR实现的语义不是独一无二的，通过SQL可以达到一样的效果。UDF（user-defined-function）即是实现的方法。

怎么用UDF模仿MR：

UDF可以实现同map一样的效果，用户定义的聚集操作实现同reduce一样的效果，Map和Reduce之间的reshuffle可以由SQL中的group by替代。

并行DBMS的线性伸缩性已经得到了发展，数据库的规模可以在保持常数级的响应时间的情况下成比例的增长。

Possible Application（MR系统的适用范围）

ETL和读取一次的数据集

1， 从不同的源读取信息日志

2， 解析清理日志数据

3， 执行复杂的传输

4， 决定存储数据的分布节点

5， 将信息装载到DBMS或其他存储引擎

复杂分析

在数据挖掘和数据集群应用中，需要使一部分的输出成为另一部分的数据的复杂的数据流项目

半结构化数据

很多半结构化的数据都很像key/value对，适用MR架构

而在关系型数据库系统中，存储这样的数据需要一张很多元组的大表以满足众多的数据类型。元组记录中没有的属性用NULL来表示。基于行的DBMS在处理这种表的时候性能表现的不好，然而基于列的DBMS在查询中可以只读取相关元组而抑制NULL值，所以基于列的DMBS性能更好

快速和脏数据分析

MR装载数据时间短，DMBS装载数据花费高。DBMS适合反复分析的数据，而MR适合只需要快速处理得数据。

预算有限的操作

DBMS费用昂贵，MR是开源免费

DBMS sweet spot

本文的benchmark同Comparison那篇论文，略；

Architectural Differences

重复的记录解析

MR将数据解析的任务交给了用户代码

Hadoop提供了将数据存为key/value对的SequenceFiles的存储格式，但是据测试其对性能有负作用。

并行数据库在装载数据的阶段对数据进行解析，提高了执行时候的性能

MR架构也可以对数据进行预处理，数据可以用协议缓存（protocol buffer）来存储。

作者提出一种改善方法：将数据移出MR架构，将数据改为用DMBS似的优化存储的结构化数据。

压缩

压缩在MR架构中的作用非常微弱

管道

数据库是从生产者到消费者，数据流向是个PUSH的过程

MR架构是从消费者到生产者，数据流向是个PULL的过程。

关于两者的区别和可能造成的问题在comparison中提及

调度

DBMS是编译时调度的，系统可以优化执行计划缩短数据传输。

MR是运行时调度的，开销要更大。但是好处是可以动态调节负载均衡

基于列存储

见半结构化数据一节

容错性

DBMS可以通过在查询执行的过程中标记一个或多个操作实现操作级的重启

MR和数据库结合，MR做复杂分析，为DMBS的嵌入查询提供接口

Learning From Each Other

MR：并行查询的效率，高层次的语言

Parallel DBMS：快速安装和运行查询，处理文件系统中存放的表（situ data）

Conclusion

两者架构上的区别主要是两者关注目标不同造成的。并行数据库系统善于处理大数据集上的高效查询。MR善于处理负载分析和ETL任务。两者对对方的方向都不擅长，所以两者与其说是竞争关系不如说是互补的。我们期待将MR架构作为并行DBMS的上游。

总结

1，本文是对A Comparison of Approaches to Large-Scale Data Analysis这篇文章的补充，在前文基础上总结MapReduce的适用范围，架构上的区别并总结说“用MapReduce去做适合并行数据库的任务是不能得到满意的结果”。最后本文阐述了如何让MapReduce和并行数据库互相学习结合，提高两者的性能。

2，本文对并行数据库的阐述较 A Comparison of Approaches to Large-Scale Data Analysis详细，将并行数据库的原理讲解较前文通俗易懂，阅读此文有助于前文知识的理解。

3，本文对MR的适用范围有了更为深入和全面的诠释。说明MR与并行DBMS所擅长的领域不同，所以可以互相补充。本文提出了一些两者如何互相补充的想法

4，本文分析了MR和parallel DBMS架构上的不同和优缺点，对两者的改进都提出来建议。