1、大规模数据分析方法对比A Comparison of Approaches to Large-Scale Data Analysis 作者作者1：Andrew Pavlo，Brown University 1 MapReduce and parallel DBMSs:friends or foes?朋友还是冤家 2 A comparison of approaches to large-scale data analysis 3 H-store:a high-performance,distributed main memory transaction processing system 4
2、The NMI build&test laboratory:continuous integration framework for distributed computing software 5 Smoother transitions between breadth-first-spanning-tree-based drawings主要做Hadoop(Mapreduce)和并行数据库管理系统比较，用于大规模数据集分析。作者简介 作者作者2 Erik Paulson，University of Wisconsin 1 MapReduce and parallel DBMSs:friend
3、s or foes?2 A comparison of approaches to large-scale data analysis 3 Clustera:an integrated computation and data management system和第一作者一样，主要做Hadoop(Mapreduce)和并行数据库管理系统比较，用于大规模数据集分析。作者作者3 Alexander Rasin，Brown University 1 CORADD:correlation aware database designer for materialized views and indexe
4、s 2 MapReduce and parallel DBMSs:friends or foes?3 HadoopDB:an architectural hybrid of MapReduce and DBMS technologies for analytical workloads 4 Correlation maps:a compressed access method for exploiting soft functional dependencies 5 A comparison of approaches to large-scale data analysis 6 H-stor
5、e:a high-performance,distributed main memory transaction processing system 作者在本文的基础上，设计了HadoopDB系统，一个Mapreduce和并行数据库管理系统结合的系统。摘要 目前有相当大的兴趣在基于MapReduce（MR）模式的大规模数据分析。虽然这个框架的基本控制流已经存在于并行SQL数据库管理系统超过20年，也有人称MR为最新的计算模型。在本文中，我们描述和比较这两个模式。此外，我们评估两个系统的性能和开发复杂度。最后，我们定义一个包含任务集的基准运行于MR开源平台和两个并行数据库管理系统上。对于每个任务
6、，我们在100台机子的集群上衡量每个系统的各个方面的并行性能。我们的研究结果揭示了一些有趣的取舍。虽然加载数据和调整并行数据库管理系统执行的过程比MR花费更多的时间，但是观察到的这些数据库管理系统性能显著地改善。我们推测巨大的性能差异的原因，并考虑将来的系统应该从这两种架构中吸取优势。ABSTRACT：There is currently considerable enthusiasm around the MapReduce(MR)paradigm for large-scale data analysis.Although the basic control flow of this fr
7、amework has existed in parallel SQL database management systems(DBMS)for over 20 years,some have called MR a dramatically new computing model.In this paper,we describe and compare both paradigms.Furthermore,we evaluate both kinds of systems in terms of performance and development complexity.To this
8、end,we define a benchmark consisting of a collection of tasks that we have run on an open source version of MR as well as on two parallel DBMSs.For each task,we measure each systems performance for various degrees of parallelism on a cluster of 100 nodes.Our results reveal some interesting trade-off
9、s.Although the process to load data into and tune the execution of parallel DBMSs took much longer than the MR system,the observed performance of these DBMSs was strikingly better.We speculate about the causes of the dramatic performance difference and consider implementation concepts that future sy
10、stems should take from both kinds of architectures.1引言 本文主要目的是如何在Hadoop、DBMS-X、Vertica中取舍和选择。第二部分主要介绍大规模数据分析的两种方法，Mapreduce和并行数据库管理系统。第三部分主要介绍系统架构，包括支持的数据格式、索引、编程模型等。第四部分主要是基准测试，在100个节点集群上运行几个任务来测试Mapreduce，DBMS-X，Vertica。对100个节点上测试有没有代表性进行解释：eBay 的TeraData配置使用72个节点（两个四核CPU，32GB内存，104个300GB磁盘）管理2.4P
11、B的关系型数据；Fox互动媒体仓库运行在40个节点的Greenplum DBMS上（Sun X4500机器，两个双核CPU，48个500GB的硬盘，16 GB内存，1PB的总磁盘空间）。2 两种大规模数据分析方法 两种方法都是通过把数据分块，分配给不同的节点实现并行化处理。本节概述Mapreduce和并行数据库管理系统。2.1Mapreduce Mapreduce最吸引人的地方是编程模型简单。MR包含两个函数Map和Reduce，用来处理键/值数据对。数据被分块存储在部署在每个节点上的分布式文件系统中。程序载入分布式处理框架然后执行。具体过程如下：Map函数从输入文件中读入一系列记录，然后以键
12、/值对的形式输出一系列中间记录。Map函数使这些中间值最终产生R个输出键/值对文件，具有相同值的输出记录存储在一个输出文件下。Reduce函数总结Map阶段具有相同值的输出记录。最终结果写入到新文件。2.2并行数据库管理系统 并行数据库执行的两个关键方面是（1）大部分表分割到集群的节点上（2）系统使用优化器把SQL命令转化成查询计划，使其在多个节点上执行。因为程序员只需用高级语言中具体化他们的目标，所以无需关注底层存储细节。SQL命令执行过程分三步：首先过滤子查询在节点上并行执行，如map函数。接着根据数据表的大小选用一种并行连接算法。最后把每个节点的答案聚焦输出。乍一看，两种方法的数据分析和
13、处理有很多共同点，下一节讲差异。3 架构元素 Architecture elements 3.1架构支持Schema support MR适合少数程序员和有限应用领域的开发环境，由于这种限制，不适合长期的大项目。并行数据库管理系统要求数据满足行和列的关系范式。而MR对数据的结构无要求。3.2索引Indexing 现代数据库系统都使用哈希或二叉树索引加速访问数据。MR不提供内嵌索引，程序员需要在应用程序中添加。3.3编程模型 关系型数据库系统，程序用高级语言写，容易读写和修改。MR 使用低级语言执行记录集操作，引入现象过程语言编程。为减轻执行重复任务，把高级语言迁移到当前接口，如数据仓库工具Hi
14、ve和分析大规模数据平台Pig。3.4数据分发Data distribution 并行数据库系统 使用并行查询优化器平衡计算工作量，最小化数据在网络中的传输。除了最初决定把Map实例安排在哪个节点，MR程序员需要手动执行其他的任务。3.5执行策略 MR处理Map和Reduce job之间传输有一个很严重的性能问题。Reduce阶段，不可避免的，两个或更多的reduce实例通过文件传输协议pull同时从一个map节点读取输入文件，减慢有效的磁盘传输速率.并行数据库系统不分块文件，采用推送方式push代替pull。3.6灵活性 由于SQL表达能力不足，新的应用程序框架开始扭转这种局面，通过利用新的
15、编程语言功能来实现对象-关系映射模式。由于数据库管理系统的健壮性，使开发者减轻写复杂SQL的负担。虽然没有MR完全的一般性，但数据库管理系统现在提供的支持用户自定义函数，存储过程，在SQL中聚合等，也提高了灵活性。3.7容错性 MR更善于处理执行MR计算过程中节点失败。如果一个节点失败，MR调度器会在另外一个节点上重启这个任务。如果一个节点失败，数据库管理系统整个查询必须完全重新启动。4 基准的性能 Performance benchmarks 使用包含5个任务的基准来比较MR和并行数据库系统的性能。第一个任务是论文【8】中的文章作者认为有代表性的实验。另外四个任务是更复杂的分析工作负载。在知
16、名的MR（Hadoop）和两个并行数据库管理系统(DBMS-X Vwrtica)上执行基准。4.1基准环境Benchmark environment 4.1.1测试系统 Hadoop 0.19.0 Java 1.6.0 默认配置，除了数据块大小改为256M，JVM heap size 1024M（每个节点3.5G），每个节点上运行2个map实例和1个reduce实例。DBMS-X 系统安装在每个节点上，配置4GB内存段用于缓冲池和临时空间。数据以行的格式存储，每个表哈希分到各个节点，然后根据不同的属性排序和索引。Vertica 是为大型数据仓库设计的，以列的格式存储，默认压缩数据，因为执行器可
17、直接操作压缩数据，本文的结果是执行压缩数据产生的。4.1.2节点配置 三个系统都部署在100台机子的集群，每个节点CPU 2.4GHz intel core 2 操作系统64位red hat enterprise linux 5 内存4G 硬盘 2个250GSATA-I.交换机 128Gbps 50个节点一台交换机。4.1.3基准执行 每个系统执行基准任务三次取平均，先在一个节点上执行每个任务，然后在不同的集群数量上执行不同的数据大小。还测量了每个系统加载数据的时间。由于MR每个reduce输出一个文件，而数据库管理系统总共输出一个文件，在HDFS中执行一个额外的reduce函数来结合成一个文
18、件再输出。4.2原始的MR任务The original MR task 第一个基准任务是文献【8】中的Grep task 作者认为具有代表性的大数据集MR程序，这个任务是在100位记录的数据集寻找三个特征模式，每个记录中在前十位中包含一个唯一的键，后90位是随机的值。Grep task在1,10,25,50,100个节点上分别执行。4.2.1数据加载 加载535M/node和1T/node如下图，对于DBMS-X，下半段是执行加载命令时间，上半段是重组过程。Hadoop性能明显好。4.2.2任务执行 三个系统的性能结果如下。Hadoop上半段是MR job把输出文件结合成一个的时间。下半段是执
19、行任务时间。对于每个节点535M，DBMS-X和Vertica性能差不多；对于每个节点1T，DBMS-X和Hadoop性能差不多。4.3 分析任务 为了探索处理更复杂的应用，开发四个关于HTML文档处理的任务。每个节点分配6000个HTML文档，还自己利用产生器创造2个数据集，1.55亿UserVisits 记录，每个节点20G，1800万Ranking 记录，每个节点1G。4.3.1数据加载由于加载UserVisits与Ranking数据集是相似的，只提供数据集较大的UserVisits的加载。节点数越多，相比较Hadoop性能越好。4.3.2选择任务 选择任务是轻量级过滤器在Rinking
20、s 表(1G/节点)中寻找pageURLs。设置临界参数为10，每个节点上每个数据文件大约产生36000条记录。结果如下，随着数据量增大，Hadoop影响最大。Vertica性能较好。4.3.3聚集任务Aggregation task 要求每个系统计算在UserVisits表中生成每个源IP总收益数（20GB/节点）。任务分别产生250万（53M）和2000(24K)组记录当组数量大时，Vertica和DBMS-X性能差不多；当组数量小时，Vertica性能较好。4.3.4 联合任务Join Task 加入任务包括两个子任务来进行两组数据的复杂计算。首先，每个系统找出在特定时间内产生最大收益的
21、源IP，一旦这些中间记录产生时，系统必须计算在此间隔期间的所有网页访问的平均PageRank。实验中使用表UserVisits 1月15日至22日，2000年，约13.4万记录相匹配。Vertica和DBMS-X性能差不多。4.3.5 UDF的聚集任务UDF Aggregation Task 任务是计算数据集中每个文档的inlink，这个任务经常作为PageRank计算的一个组件。具体来说，这项任务时，系统必须读取每个文件的内容和搜索内容中出现的所有URL，然后针对每个唯一的URL，计算唯一网页的数量。Vertica性能比较好。节点数越多，BMS-X查询的时间相比较增长更快。Vertica和DBMS-X的下面部分代表执行UDF/分析和加载数据到表中的时间，上面部分是执行真正查询的时间。结论 平均在100个节点上运行这5个任务，DBMS-X比MR快3.2倍，Vertica比DBMS-X快2.3倍。估计在1000个节点上，性能也差不多。谢谢！
