【原文】 A Comparison of Approaches to Large-Scale Data Analysis
【作者】
Andrew PavloBrown University pavlo@cs.brown.edu
【摘要】 当前，对“关于大尺度数据分析的MapReduce(MR)范式（paradigms）”的兴趣受到很广泛的关注【参见：17】。尽管框架的基本的控制流在并行SQL数据库管理系统DBMS中已存在20多个年头了，MR仍然被称为是一个引人注目的新计算模型【参见：MapReduce: Simplied Data Processing on Large Clusters以及17】。该论文中，我们描述与比较了两种范式。我们从性能和开发复杂度两方面来评估两种范式下的系统。作为结尾，我们定义了一个由“在两个并行的DBMS上，运行一开源版本的MR“这样的任务集合组成的基准线，对每一个任务，我们从不同的并行度上（有100个节点的集群），衡量了每个系统的性能。尽管装载数据的处理以及对并行DBMS的调优耗费了远较MR为多的时间。这些观察到的DBMS的性能表现却异常的好。我们推测性能显著提升的不同原因，以及从两种架构上考虑，均要的实施概念。类别与主题描述H.2.4 [ 数据库管理 ] ：系统 - 并行数据库Erik PaulsonUniversity of Wisconsin epaulson@cs.wisc.edu
Alexander RasinBrown University alexr@cs.brown.edu
Daniel J. AbadiYale University dna@cs.yale.edu
David J. DeWittMicrosoft Inc.dewitt@
Samuel MaddenM.I.T. CSAIL madden@csail.mit.edu
Michael StonebrakerM.I.T. CSAIL stonebraker@csail.mit.edu
1.介绍
最近专业刊物充满了有关革命性的“集群计算”的新闻。该范式承担了管理大数据量的廉价的，以并行的方式解决计算问题的，处理器单元。实际上，这表明通过“排列在大数量的廉价服务器上，而不是分布在少量的高端服务器上的”方式来构建数据中心。由于这种在集群上兴趣的增长，所以有更多的编程工具来对之编程。其中最早以及最有名的一个类似的工具就是（MR）【参见：MapReduce: Simplied Data Processing on Large Clusters】MapReduce是吸引人的，因为它提供了简单的模型，用户可以通过该模型表达相关的分布式编程（Distributed programs）。这引起了学习型社区的广泛的关注。比如，IBM和Google已经声明了一个计划来使1000台处理器组成的MapReduce集群用于教导学生学习分布式编程。
考虑到既然对MapReduce有兴趣，很自然的会问：为何不使用并行数据库管理系统（parallel DBMS） 来代替呢？如今在市场中有一打以上这样的并行系统，包括了Teradata，AsterData，Netezza，DATAllegro（以及随之马上要出的由Madison项目托管的微软SQL服务器），Dataupia，Vertica，ParAccel，Neoview，Greenplum，DB2（经由数据库分区特性），以及ORACLE(经由Exadata )。它们是健壮的，高性能的计算平台。就像MapReduce，它们提供了高端编程环境并已经并行化（parallelize readily）尽管看上去MR和并行数据库的目标受众不太一样，实际上“作为数据查询集（可能用到未定义函数以及聚合来过滤以及组合数据）或者MapReduce作业集合，以这两种方式写任何并行处理任务”都是可能的。由这个问题激发，我们的目标是理解“MapReduce方式来实施大范围数据分析”与“并行数据库系统方式去实施大范围数据分析”的异同。在许多关键领域，系统表现出不同的选择。例如，所有的DBMS要求数据遵循良好定义的范式，而MR允许数据以任何形式出现。其他的不同表现在各个系统如何提供索引以及压缩优化。数据以何种方式来分布， 以及查询执行的策略。
该文献的目的是考虑这些选择，以及这些系统所进行的权衡。我们在第二节开始一个简短的关于两种类型的系统的回顾，以及接下来第三节关于系统架构权衡（thearchitectural trade-offs）讨论。然后在第四节我们提供了“由一个来自 MR文献【参见：MapReduce: Simplied Data Processing on Large Clusters】，其余是更多的任务组成的一个collection”这样两种任务组成的基准（benchmark）。而且，我们提供了“为每个任务提供在100个节点上运行的基准的这么一个结果”（the results of running the benchmark on a 100-node cluster to execute each task）。我们测试了开源版本的MapReduce ：Hadoop 【参见：hadoop官网】，与之相对的是两个并行SQL数据库管理系统：Vertica 【参见：】以及主要相关供应商。我们同样在每个系统装载测试数据时提供结果，以及提供关于“需要安装的程序”的非正式报告给“为调优软件目地的”每个任务。
总体而言，SQL 数据库管理系统明显的更加快速, 而且就每个任务需要编码实施的数量更加少。但花费更长时间来调优与装载数据。因此，我们以讨论“在各方法上不同的原因，与提供关于大范围数据分析方法的最佳实践的建议”作为总结。
MR 可能确实能够扩展1000个节点，现代数据库管理系统的更高级的效功效减轻了这样的使用需求，诸如于“范围从1到2PB的（1000个节点，每个磁盘/节点有2TB容量的话，总体磁盘容量就是2PB） ”数据集上使用大量的硬件。比如，eBay的Teradata配置使用了72个节点（每个节点：两个四核CPU，32GB RAM，104 300G硬盘 ）来管理约2.4PB的相关数据。另一个例子是，福克斯互动媒体的数据仓库使用40个节点的Greenplum 数据库管理系统实施的。每个节点是SUN X4500 机器与两个四核处理器， 500GB 硬盘， 以及16GB RAM（总磁盘空间是1PB）【参见：MAD：对大数据的分析实践】。由于世界上很少有数据集达到了拍字节大小，现在并不是非常清楚有多少MR 用户真的需要1000个节点。
2.两种大范围数据分析方法 （ TWO APPROACHES TO LARGE SCALE）
该文献中我们考虑的这两种系统运行于一种称之为：无共享集合的计算机（“sharednothing”collection of computers）【参见：the case for shared nothing】。就是说，系统部署在诸独立机器的一个聚集上（collection），每一个都是仅本地磁盘，本地主存，通过高速局域网互联。两种系统都“通过将任何需用的数据集合分割到分区的方式”并行化，这些分区将派发到不同的节点来促进并行处理。在该节中，我们提供了一个关于“在该环境下MR模型如何操作，以及传统的并行数据库管理系统如何操作的”概览。
2.1 MapReduce
MapReduce编程模型一个吸引人的特性是其简单性（simplicity）：一MR 程序仅由两个功能组成，称为Map和Reduce，由用户书写用于处理键值对形式的数据对（pairs）。输入数据集存储于一个“分布于集群上每个节点中的分布式文件系统”分区上的聚集。程序然后就注入分布式处理框架，并以将详细说明的方式执行。
Map 功能从输入文件读取记录的集合，执行任何期望的过滤 与/或 转换，在Map功能产出这些输出结果时，一个分割（split）功能通过“对每条输出记录的键应用一个功能”将记录分区到R个不相连的桶（disjointbuckets）。这个分割函数典型的是一个哈希函数，尽管任何deterministic function也是满足的。每个map 桶被写到处理节点的本地磁盘。Map功能结束于产出R个输出文件，每个桶一个。总体而言，有多个运行于集群上不同节点的Map功能的实例。我们用术语“实例”（instance ）来表示或者是Map，或者是Reduce这样的唯一的运行调用（unique runninginvocation）。每个Map 实例“通过MR调度程序”被分配一个输入文件的独立部分来处理。如果有M个这样的输入文件的独立部分，则对M个Map任务中的每一个而言，都有在磁盘存储上有R个文件；对总体的M × R文件而言：F[i,j] , 1 <=i <= M,1<= j <= R .关键所在是，所有的Map实例用了相同的哈希函数，因而，所有的有相同哈希值的输出记录存储于同一个输出文件。
MR 程序的第二个阶段执行Reduce程序的R个实例，这里的R典型的表示节点的数量。每个Reduce实例的输入R[j]包含了文件 F[i,j] ,1<=i<=M。这些文件从Map节点的本地磁盘通过网络传转移出去（transferred）。注意到，再一次从Map阶段来的所有输出记录（这些记录有相同的哈希值），由同一个Reduce实例消耗。（ Note that again all output records from theMap phase with the same hashvalue are consumed by the same Reduce instance），而不用去考虑是哪一个Map实例产生了这个数据。每个Reduce有一些方式去处理或组合赋予它的记录，然后将这些记录写到输出文件（于分布式文件系统中），该文件是计算的最终输出的一部分。
输入数据集以“一个或多个分区的聚集”的形式存在于分布式文件系统中。MR调度程序的指责需要决定“多少个Map实例需运行以及如何分派它们到可用节点”。类似的，调度程序还必须决定节点的数量以及运行Reduce实例的位置。MR中央控制器（centralcontroller）负责协调每个节点上的系统活动。一旦最终结果被写出（像一个新的文件于分布式文件系统中） ，MR 程序就结束执行了。
2.2 并行数据库管理系统（Parallel DBMSs）
从上世纪80年代晚期起，可运行于shared nothing节点组成的 集群上的数据库系统已经出现。这些系统都支持标准关系表以及SQL, 以及“数据存储于多个机器上”这样的特性对终端用户是透明的。许多这些系统构建在来自Gamma 【参见：GAMMA - A High Performance Dataflow Database Machine】和Grace 【参见：并行关系数据库GRACE简介】并行DBMS项目一类前卫研究。
两个允许并行执行的关键点是：
大多数表通过集群中的节点被分区。系统使用优化器将SQL 命令转换为查询计划，该查询计划的执行是被分割到多个节点中去的。
由于程序员只需要在高级编程语言级别指定其目标，他们不会被底层的存储细节所困扰，诸如索引操作以及连接策略。
考虑一个SQL命令去过滤表T1中基于谓语的记录，随同连接第二个表T2（在连接的结果上进行聚合计算）。关于这个命令如何在并x行DBMS中处理的基本梗概有三阶段组成。由于数据库将会已经在节点分区的一些聚集上存储了T1（ will have already stored T1 on some collection of the nodes partitioned on someattribute），过滤子查询首先在这些地点并行执行，类似于在Map功能中执行。这个步骤接下来，两个常用并行连接算法之一，被依照数据表的大小部署上去（areemployed）。比如，如果在T2中记录的数目比较小的话，那么一旦数据被装载，DBMS将在所有的节点上替换它。这允许Join以并行方式在所有节点中执行。再其次，每个节点用关于join的回答部分来计算总计（each node thencomputes the aggregate using its portion of the answerto the join ）最后的上翻（roll-up）步骤需要从这些部分总结(partialaggregates)【参见：基于哈希的多处理器连接算法】计算最后答案。
如果在T2表中的数据大小太大了话， 那么T2的内容会通过多个节点被分布出去。如果这些表较之那些用连接的方式，在不同的属性之间分区（are partitioned on different attributes than those used in the join），系统将会对T2以及T1的过滤版本进行，利用通用哈希函数的连接属性的，哈希。关于T2以及T1的过滤版本两者的到节点的重分配（redistribution）类似于“发生在Map以及Reduce 函数上的处理”。一旦每个节点有必要的数据，它就执行一哈希连接，并计算初步总计功能（preliminaryaggregate function）。再次的，一上翻计算必须作为产生最终结果的最后一步来实施。
初看起来， 这两种分析处理数据的方法有许多共同点：然而，我们在接下来的节中会看到它们还是有显著的差异的。
3. 构架元素 （ARCHITECTURAL ELEMENTS）
在该节中， 我们从“分布式环境下必须的处理大数据量”角度考虑两个系统架构。我们讨论的一个主题是：MR模型的特质很好的适合“只有少数程序员的”开发环境，以及受限应用域（limitedapplication domain）。然而缺乏约束可能不会适用于长期的、较大的项目。
3.1 模式支持 （Schema Support）
并行DBMS强制要求数据去适应行和列的相关范式（paradigm）。作为比较， MR模型不需要数据文件受“用相关数据模型的”模式定义的约束。那就是，MR程序能自由的，以任意方式，甚至是完全没有组织结构，去构建其数据。
有人可能会认为严格模式的缺位自动的会使得MR称为更好的选择。比如，SQL常常被人诟病：其“程序员必须在数据定义功能中定义好数据的形状”的需求。就另一方面而言，MR程序员必须经常写定制解析器（customparser），从而可以对它们的输入记录来推断适当的语义（derive the appropriate semantics for their inputrecords）。至少是同等以上的工作（work）。但如果在大数据集上不用模式的话，也有另外的潜在问题。
无论什么样的“存在于MR输入文件中的”结构（structure ）必须内置到Map 和Reduce程序中去。目前的MR实施提供了内建函数来把控简单的键值对格式，但是程序员必须显式的书写以支持更复杂的数据结构， 比如最合键。如果MR 数据集不是通过多应用获取的（not accessed by multiple applications），这可能是一种可接受的方法。如果这样的数据共享时存在的，且，第二个程序员必须对第一个程序员写的代码进行解码，以决定如何处理输入文件。一种更好的方法，是所有SQL 数据库管理系统都采用的方式，是从应用中分离出模式 ，并存储于可以查询的系统目录集。
但即便模式从应用中独立出来，并通过描述工具可用于多MR程序，开发者必须还认同单一模式。这明显的需要一些对数据模型或其它模型的承诺，并且输入文件必须服从这个承诺，就好像一旦文件生成了，它对修改数据属性的反应很迟钝。再一次从应用中分离出这些约束，并通过运行时的机器强制自动的执行它们（enforcingthemautomatically），作为正在开展的所有SQL数据库管理系统（asis done by all SQL DBMSs），数据的完整性不受更多的程序员利益角度的工作影响（enforced without additionalwork on the programmer’s behalf）。
总结一下，当预期no sharing时，MR范式非常的灵活。 如果需要共享（sharing）， 则我们认为“在应用程序之外，用数据描述语言、因子模式定义和完整性约束对程序员是有利的”（itis advantageousfor the programmer to use a data description language and factor schema definitions and integrity constraints out ofapplication programs）。该信息应当装载到“适当的用户和应用可以获取的”通用信息目录中。
所有现代的数据库管理系统都使用哈希或者B树索引来加速获取数据。设若寻找一个记录的子集（如，员工工资大于$100,000），那么使用一个适当的索引将显著的缩小查找范围。大多数数据库系统也支持单表多索引（multipleindexes per table）。因此，查询优化器可以决定对每个查询使用哪个索引，或是否简单执行一蛮力顺序搜索（brute-forcesequential search）。
3.2 索引
由于MR模型如此简单，MR框架不提供内建索引。程序员必须在其应用中实施“他/她希望加速获取的数据上的任何索引”。这不容易完成， 因为框架的数据获取机制还必须被装配，以在发布数据运行Map实例时，使用这些索引。再次的，如果索引无需在多个程序员间共享时，这是一种可接受的方案，而无需每一个MR程序员再次实施相同的基本功能。
如果共享是需要的，那么，就要提供何种索引的说明，以及程序员就怎样来使用这份说明形成共识。这再次比“在系统目录中以标准方式存储该索引信息”更好，（Itis again preferable to store thisindex information in a standardformat in the system catalogs,）从而程序员可以查询该结构来发现这样的知识。
3.3 并行模型 （Programming Model）
在1970年代，数据库搜索社区卷入了有争议的探讨关系型主张和数据系统语言会议Codasyl的主张【参见：18】讨论中凸显的问题是程序获取DBMS中的数据通过以下何种方式：
从你想要的地方开始 – 而不是提供了一个就如何达到它的算法（关系型）；提高了获取数据的(Codasyl)。
最后，前述第一种方式盛行起来了，并在最后30年的实践中，对关系型数据库系统的价值形成了一个明证。高层编程语言，诸如SQL， 更易于编写，修正以及易于让新人理解。Codasyl被讥讽为“用汇编语言方式和DMBS打交道”。我们认为MR程序在一定程度上和Codasyl程序是类似的：必须用低级语言（low-levellanguage）写算法以执行记录级别（record-leve）的操作。另一方面，对许多成长于程序语言下的人，诸如 C/C++ 或Java，将任务用类似SQL一样的陈述语言（declarative language）描述是一个挑战。
来自MR 社区的轶事证据显示了广泛的分享MR 代码框架去做一些通用的工作，诸如连接数据集。为减轻重复执行冗余重复任务的负，MR社区正在从目前的接口上迁移高级语言，把这些函数功能放入运行时（move such functionality into the run time）。Pig【参见：Pig Latin: A Not-So-Foreign Language for Data Processing】和Hive【参见：/】是这种迁移项目的两个有名的例子。
3.4 数据分布 （Data Distribution）
涉及大尺度数据库，传统智慧是对数据发送计算（sendthe computation to the data），而非其它方式。换种说法， 应当通过网络发送小程序到节点， 而不是从节点导入大量数据（译注：似应为导出），并行DBMS 最优的使用了“数据分布和为止的知识”：并行查询优化努力去平衡计算工作负载（balance computationalworkloads），同时最小化连接集群上节点的网络数据传送量。
除关于“何处去排产Map实例”的初始决策以外，MR程序员必须手动的去执行（perform）。比如，假设一用户写了一个MR程序去处理两个部分中的文档的聚集（to process a collection of documents in two parts）。首先，Map函数扫描文件并产生一“经常发生的单词的”柱状直方图。该文档然后就传递到Reduce功能，该功能通过它们的初始站点来聚合文档（that groups files by their site of origin）。使用该数据，那么用户或者其他“使用建基础于第一个用户工作的”用户，则会想要找到这样的站点（sites）：该站点包含了一个“多于五次出现的诸如‘Google’或‘IBM’单词这样的文件”。该查询的默认实现中（ In the naive implementation of this query），Map 是在累计统计基础上执行的（Map is executed over the accumulatedstatistics），过滤在“所有文档的统计被计算完”后完成，并迁移到（shipped to）reduce工作，即便只有一个小的文档子集满足关键字过滤。作为对比，下面的SQL 视图以及select查询实现了类似的计算：
CREATE VIEW Keywords ASSELECT siteid, docid, word, COUNT(*) AS wordcountFROM DocumentsGROUP BY siteid, docid, word;SELECT DISTINCT siteidFROM KeywordsWHERE (word = ‘IBM’ OR word = ‘Google’) AND wordcount > 5;
现代DBMS会重写第二个查询，以至于视图定义代替了FROM从句中的关键字表。然后，优化器可以把查询中的WHERE从句下推（push…down ），以便可以在COUNT计算前，应用于文档表（Documents table），从而充分的降低计算量（substantially reducingcomputation）。如果文档在多个节点上分布，那么该过滤器（filter）可以在“属于相同站点的文档聚集在一起”前，应用于每个节点，从而更少产生网络I/O。
3.5 执行策略 （Execution Strategy）
关于MR有一个潜在的严重性能问题：MR在Map 和Reduce 作业间的处理数据转换问题。回忆一下，N个Map实例中的每个都产生M个输出文件，每个流转到不同的Reduce实例（译注：‘每个’ 指Map实例中的每个还是M个输出文件中的每个？），这些文件被写到了“处理每个特定的Map实例的”节点之本地磁盘。如果N是1000，M是500，则Map阶段的程序会产生500,000个本地文件。当Reduce阶段开始，这500个Reduce 实例中的每一个都需要读其1000个输入文件，且必须用到文件传输协议（file-transfer protocol）来从Map节点运行的实例上“拉”其各个输入文件。若同时运行100个Reduce实例（With100s of Reduce instances running simultaneously ）， 则不可避免的会有两个或多个Reduce实例尝试：从相同的map节点同时的读取其输入文件，这会引发大数量的磁盘探查（seeks）并减缓有效磁盘迁移率（transfer rate）。这就是为什么并行数据库系统不会实现他们的分离（split）文件，而是以“推的方式代之以拉的方式传输数据”代替之（ This is why parallel database systemsdo not materialize their split files and instead use a push approach to transfer datainstead of a pull）。
3.6 灵活性 （Flexibility）
尽管有广泛的应用，SQL仍旧由于其不充分的表达能力而被诟病。有些人相信这对于70年代的数据库研究团队来说聚焦于可以内嵌到任何编程语言中的数据子语言（data sub-languages） 是一个错误，而非将高阶数据存取添加到所有语言。幸运的是，新的应用框架，诸如Ruby on Rails【参见：Agile Web Development with Rails】以及 LINQ 【参见：LINQ: Reconciling objects, relations and XML in the .NETframework】，通过应用“新的编程语言函数来实现对象关系映射模式（object-relational mappingpattern）”开始逆转这种局面。这些编程环境允许开发者从健壮的DBMS技术中获益，同时免去书去复杂SQL语句的负担。
MR模型的支持者争辩认为：SQL不会使得MR所提供的预想生成变得更容易（SQL does not facilitate the desired generality that MRprovides）。DBMS 产品（商业的以及开源的）目前提供对用户定义函数功能、存储过程以及用户定义的SQL中的聚集（aggregates ）的支持。尽管这没有覆盖MR的大部分功能（does nothave the full generality of MR），但确确实实的改进了数据库系统的灵活性（flexibility ）。
3.7 容错 （Fault Tolerance）
MR 框架较之并行DBMS提供了一个更加复杂的错误处理模型。虽然两种类型的系统都用到了某种形式的冗余来应对磁盘失效，MR在“执行MR计算”时，显然更能处理节点失效。在MR系统中，如果一工作单元失效了（例如，处理一数据块），然后MR调度程序可以在另外一个节点上自动重启任务。灵活性的一部分是这样一种事实的结果：“代之以运行Reduce任务时涌入该节点的是，Map阶段的输出文件在本地被产出（materialized）。”类似的，MR作业的管道，例如将在4.3.4节描述的，将中间结果实现到“该方式的每一步中的”每个文件。这就与并行DBMS不同了， DBMS有更大的工作粒度（如，事务）可以在时间失败的时候重新执行。这种方法的部分原因是因为DBMS避免了任何时候可能的“保存中间结果到磁盘”。因此，如果是在DBMS中做一个长期运行的查询，并且是在单一节点上做的而且还失败了，则整个查询显见必须推倒重来。
4. 性能基准程序测试数值 （PERFORMANCE BENCHMARKS）
该节中，我们提供了一个基准程序测试数值，由五个任务组成，我们用其比较MR 模型以及并行关系数据库管理系统DBMS的性能。第一个任务是直接从一篇论文中得来【参见：MapReduce: Simplied Data Processing on Large Clusters】，该作者声称其为通用MR任务的代表。由于该任务非常的简单， 我们还提供了四个其它任务。由更复杂的“设计用于开发前述节提及的交易“这样的分析工作量组成。我们于“一著名的MR实现以及俩个并行DBMS”上执行了基准程序测试数值。
4.1 基准测试环境 （Benchmark Environment）
当我们描述我们的基准测试环境的细节时，我们注意到在不同的操作假设下的测试差异，这种数据分析系统如何不同；以及讨论了我们如何来处理它们，从而使得以实验统一。
4.1.1 受测系统 （Tested Systems）
Hadoop：Hadoop系统是最受欢迎的MapReduce 框架的开源实现，由Yahoo!以及Apache软件组织开发【参见：/】。不同于谷歌的用C++书写的独创（original ）MR框架实施，核型Hadoop 系统是完全用JAVA写的。本文献我们的四个实验，用Hadoop 版本0.19.0 运行于Java 1.6.0上。我们用默认配置设置部署了该系统， 除了我们发现的一点“不影响MR基本原则大局的”变化：
数据代之以默认64MB 的是，用256MB数据块存储。每份任务执行器（task executor）JVM 配以最大堆（heap）大小为512MB，且数据节点/作业追踪。器（DataNode/JobTracker）JVM配以最大堆大小1024MB（每个节点的总大小是3.5GB）。我们对在集群中的本地数据使用了Hadoop的机架感知（rack awareness）特性。我们允许Hadoop重用任务执行器JVM，取代对每个 Map/Reduce任务开启一个新的处理。
而且，我们把系统配置成：在每个节点上同时有两个Map实例以及单个Reduce实例运行。
Hadoop框架还提供了谷歌分布式文件系统的一种实现【参见：/】。对每个基准测试而言，我们在Hadoop分布式文件系统HDFS上存储了所有的输入输出数据。我们用HDFS的默认设置“每一块有三个复制，且无压缩”；也测试了其它的配置，诸如使用每块单一复制，以及块与记录级压缩，但发现我们的测试以相同速度或更糟的方式（见5.1.3节）去经常执行。在每个基准测试对“特定节点范围级别”运行结束后，我们删除每个节点上的数据目录，并重新格式化HDFS，从而使下一个输入数据集在所有节点上统一的得到复制。
Hadoop使用一个中央作业追踪器（centraljob tracker）和主 HDFS守护进程来协调节点的活动。为了确保这些守护进程不会影响工作节点的性能，我们在集群中分离的节点的执行了这些附加的框架组件（译注：既然是集群，怎么会有分离节点？）。
DBMS-X:我们使用了最新的DBMS-X，一个来自主要关系型数据库厂商的并行SQL 关系型数据库管理系统，以基于行的格式来存储数据。该系统装在每个节点上并配置成使用4GB共享内存段，为缓存池以及其他零时空间之用。每个表为了特定表上的凸显属性，经由所有节点上进行哈希分区；然后排序以及在不同的属性上索引（参看 4.2.1 和 4.3.1）。像Hadoop实验，我们删除DBMSX中的表并为每次试验（trial）去重新装载数据，以保证元组一致的分布在集群中。
默认的 DBMS-X不会在其内部存储（internalstorage）中压缩数据，但它却会提供“用众所周知的基于字典的模式去压缩表（dictionary-basedscheme）”这样一种能力。我们发现压缩，就“几乎所有的基准程序测试任务”而言，减少了执行时间50%，并且我们只是报告了可以压缩那部分的结果。如果我们只发现了一种情况，那就是压缩实际上性能表现的更差了（Inonly one case did we find that usingcompression actually performed worse）。进一步的，由于我们所有的基准程序测试数值是只读的，我们不允许DBMS-X中有复制功能，这是因为该功能不会提升性能，并且反而会增加安装时的复杂度。
Vertica：Vertica 数据库是一个并行DBMS ，设计用于大规模数据仓库【参见：】。Vertica 与其他的DBMSs（包括DBMS-X） 主要的不同在于其所有的数据以列的方式存储而非行的方式【参见： 20】。它用到一独特的，特别定制的用于在基于行（column-oriented）的存储层上进行操作的，执行引擎。不似DBMS-X，Vertica 是默认的压缩数据，因为其执行器可以直接在压缩后的表上进行操作。由于关掉（disabling）这个特性，在Vertica部署中不是很典型，本文献所述之Vertica将只使用压缩后数据来生产。Vertica 也基于集群化索引（clustered index），通过1或多个属性去排序所有表。
我们发现每个节点默认的256MB缓存配置在我们实验中表现良好。Vertica资源管理器负责设置用于查询的内存量，但我们给系统提供了一个暗示，以期望仅仅每次执行一个查询（only one query at a time）。因此，每个查询接收到大多数在每个节点的运行时可用的最大量内存（each query receives most the maximumamount of memory available on each node atruntime）。
4.1.2 节点配置 （Node Configuration）
所有的三个系统都部署于100个节点的集群上。每个节点有一个2.4G英特尔酷睿2处理器，运行于64比特红帽公司版linux 5(kernel是2.6.18)，且有4GB RAM 以及 250GB SATA-I 硬盘。通过显示设置硬盘参数hdparm，硬盘以7GB/s的速度传输（deliver ）进行高速缓存（cached ）读，并且以74MB/s的速度进行缓存读。节点是通过思科Catalyst 3750E-48TD型交换器进行连接。该交换有适用于每个节点的吉比特（gigabit ）以太网端口，并有128Gbps内部交换光纤【参见：Cisco Catalyst 3750 Series Switches】。每个交换（switch）涉及50个节点。这些交换通过思科StackWise连接， StackWise会产生交换器之间的64Gbps环路(ring)。在同一个交换器下的两个节点之间的交通（Traffic ）对交换而言完全是本地的，且不会影响环路上的交通。
4.1.3 基准程序测试执行 （Benchmark Execution）
对每一个基准程序测试任务，我们描述了用于实现MR程序的步骤，以及可能的两个数据库系统的SQL状态执行。我们对每个任务执行三次并给出试验（trials）的平均报告。每个系统独立的执行基准程序测试任务，从而保证了以排它的方式存取集群资源。为了测了基准性能而没有协调并行任务的干扰，我们首先在单独节点上执行了每个任务。然后我们在不同大小的集群上执行，以显示当“数据处理量以及可用资源增加时的”每个系统的尺度（scale）。我们仅报告那些所有节点可用的以及系统软件在基准程序测试执行期间正确操作的那些试验（trials ）结果。
我们还测量了每个系统消耗在测试数据装载上的时间。这些测量值的结果是在下述两者之间的分离：前者是实际数据装载，后者是每个系统实施的装载后的附加操作，后者诸如压缩或者创建索引。每个节点上的初始输入数据存储于其两个本地安装磁盘（locallyinstalled disks）中的一个。
除非另行说明， Vertica 以及 DBMS-X中查询执行的最终结果被以管道的方式从shell命令送入磁盘上的“DBMS不会用到的”文件。尽管可能在Hadoop中有类似的操作， 通常存储MR程序的结果到分布式文件系统是一个更加常见的，也更加容易的方式。然而该过程却不类似于“DBMS过程如何产出它们的输出数据”；较之存储于结果于一个单一文件， MR程序对每个Reduce实例产生一个输出文件，并在单一目录下存储它们。接下来，的程序员来说的标准实践就是用这些输出目录作为对其它MR作业而言的单独输入单元。然而，若用户期望以非MR应用的方式使用其数据，他/她们首先必须合并其结果到一个单一文件，并且将这个单一文件下载到本地文件系统。
由于该差异， 我们对每个MR程序性能基准测试（benchmark）任务（该任务仅简单的把最终输出合并到HDFS上的单一文件）执行了一个额外的Reduce功能。我们的结果在“Hadoop运行于实际的程序性能基准测试任务的执行时间”同“附加的合并（combine）操作”之间有所差异。因而，在本文献的图形中所展示的“Hadoop结果”是以分段条形图（stacked bar）的形式出现：每个bar的低端部分是对特定benchmark任务而言的执行时间，同时其上端部分是单一Reduce功能用于合并所有程序产出数据到单一文件所消耗的执行时间。
4.2 初始MR任务 （The Original MRTask）
我们第一个程序基准测试任务就是来自有关MapReduce 的原始文献的“Grep任务”【参见：MapReduce: Simplied Data Processing on Large Clusters】，其作者描述一个事实：“代表由MapReduce用户书写的真是程序的一个大的子集”。就该任务而言，每个系统必须扫描以100字节记录为单位的数据集以寻找三字母模式（a three-characterpattern）。每条记录由“最初的10个字节组成的唯一键以及跟随的90自己的随机码”组成。查询模式（search pattern）仅仅在“每10，000条记录的最后90字节匹配时”时匹配（The search pattern is onlyfound in the last 90 bytes once in every 10,000records）。
每个节点中存储的输入数据以纯文本（plaintext files）的形式出现，每一行一条记录。就Hadoop试验（trials）而言，我们将这些文件未经改变的直接放入HDFS。为将该数据装载进Vertica和DBMSX，我们执行了每个系统专有的“在每个节点上并行执行的”装载命令行，并用以下模式（schema）存储数据：
CREATE TABLE Data ( key VARCHAR(10) PRIMARY KEY,field VARCHAR(90) );
我们用两个不同的数据集执行Grep 任务。关于MapReduce 的原始文献中的测量方法是“在约1800个节点上处理1TB数据”，大致560万条记录或者每节点约535MB数据。就每个系统，我们分别在集群大小是1，10，25，50，100个节点的情况下，执行了Grep任务。各大小不等的上述集群处理的总的记录数因此是节点数量的560万倍。（The total number of records processed for each cluster size is therefore 5.6 million times the number ofnodes）各个系统的性能不仅“显示了当数据量增加时，每个系统的伸缩性（scales）如何”，而且允许我们（在一定程度上）与原始文献中的MR系统比较结果。
当我们第一个数据集将每个节点上的数据大小修复为与原初MR程序性能基准测试值一致的时，以及仅在节点数量上有所不同时；我们的第二个数据集将整个数据集大小修复为与原初MR程序性能基准测试值（1TB）一致，并在可变数量的节点上均匀的分割数据（evenly divides thedata amongst a variable number of node ）。该任务测试了各系统伸缩性在可用节点数量增加时表现的如何。
由于Hadoop 需要总计3TB的磁盘空间以存储HDFS中每个块的3份拷贝，我们在运行该程序性能基准测试值时，被限制仅25，50，100个节点（当少于25个节点时， 将没有足够的磁盘空间用于存储3TB数据）。
4.2.1 数据装载（DataLoading）
我们现在描述用于“从本地节点文件装载数据到每个系统的内部存储表述（representation）”的过程。
Hadoop：有两种方式装载数据到Hadoop的分布式文件系统：
用Hadoop的命令行文件工具来上传本地文件系统中的文件到HDFS, 或者制作一个客户数据装载程序，该程序写Hadoop的内部I/O API。
我们无需为我们的MR程序转换（alter）输入数据，因此我们在每个节点上并行的装载文件，将其“作为使用命令行工具的纯文本”直接放入HDFS。以这种方式存储数据使得MR程序可以通过Hadoop的TextInputFormat数据格式获取数据，其键是每个文件的行号，相应的值是每行的内容。我们发现该方法将在装载处理以及任务执行时产生最佳效果，而不是使用Hadoop的序列化格式或者压缩特性。
DBMS-X: DBMS-X中的装载过程分成两个阶段。首先，我们在集群中的每个节点上并行的执行LOAD SQL命令，把数据从本地文件系统读取并插入其内容到数据库的特定表。我们在该命令中详细说明了本地数据被特殊字符分隔，我们因之不需要写“在装载之前转换数据的”客户程序（didnot need to write a custom program to transform the data before loadingit）。但由于我们的数据生成器仅简单的对每个节点上的每条记录生成随机键，系统必须重新分布（redistribute）元组到集群中的其他节点，就好象它从基于目标表(target table)分区属性(partitioningattribute)的输入文件中读取每条记录。生成一个哈希敏感（hash-aware）版本的，允许DBMS-X仅装载各节点上的输入文件而无需该重分布处理的，数据生成器是可能的，但是我们并不相信这会极大改善装载时间的消耗。
当初始装载阶段完成后，其后我们执行管理员权限的命令（dministrativecommand）来识别每个表上的数据。该过程并行的执行于每个节点来压缩数据，制作每个表的索引，并执行其余日常工作。
Vertica：Vertica 同样提供了一个 从单点主机上发行的COPYSQL命令（ a COPY SQL command that is issued from a singlehost），并协调集群内的多个节点之间并行的装载处理。用户将COPY命令用作输入节点的列表以执行装载操作（The user gives the COPY command as input a list of nodes to execute the loading operation for.）。该过程类似于DBMS-X：在每个节点上，Vertica 装载器用分隔符（delimiter）分割输入文件，为输入文件中的每一行生成一个新的元组（tuple），并重新分布元组到不同的“基于其主键哈希的”节点。一旦数据装载后，列被自动的排序，并依据“数据库的物理设计”去压缩。
结果与讨论：装载535MB/每节点以及1TB/集群的数据集的结果各自显示在图1与图2中。
译注：该翻译文献中图片数据为伪造，没有经过真实系统的运行，其中hadoop执行秒数为原始文献中的记录。
结果与讨论：装载535MB/每节点以及1TB/集群的数据集的结果各自显示在图1与图2中。对DBMS-X， 我们区别了两个装载阶段的时间，在图形的条状中（stackedbar）显示出来了：底部的段(bottom segment)代表了并行LOAD 命令的执行时间，顶部的段(top segment)是重新组织的过程。
对装载时间的结果而言，最显著的特性是图一中的535MB每字节数据集明显在DBMS-X与Hadoop与Vertica三者之间的差异。除了在初始LOAD命令的并行与于每个节点上的第一步有争议外，数据实际上是顺序的在每个节点上进行装载。因此，当数据的总数量增加时，装载时间也相应的进行增加。这同样解释了为什么对1TB/集群的数据集而言，DBMS-X的装载时间“在下降了的存储于每个节点数据量情况下”，不会减少（decrease）。然而，DBMS-X的压缩与日常开销可以在节点上并行的执行，因而装载处理的第二阶段之执行时间，在“为存储1TB数据而使用了两倍的节点”时，缩小为原先的一半（cutin half）。
既不使用块级压缩，也不使用记录级压缩，Hadoop 高下立现的胜过DBMS-X和Vertica，那是由于每个节点从本地磁盘简单的拷贝每个数据文件到本地HDFS实例（local HDFSinstance），并在其后分布两份拷贝到集群中的其余节点。如果我们仅使用“每节点的单一拷贝（only a single replica per block）”装载数据进Hadoop ，那么装载时间就会比因子为3的情况要降低了（reduced by a factor of three）。但我们将在节5中讨论，缺少多份拷贝却常常会增加作业（job）的执行时间。
4.2.2 任务执行 （Task Execution）
SQLCommands:一个模式，查询特定域（field ），简单的跟随SQL中的查询。无论SQL系统包含索引在域属性上与否，该查询需要一个全表扫描。
SELECT * FROM Data WHERE field LIKE ‘%XYZ%’;
MapReduce 程序：MR 程序由“给定一个已分割到合适的键值对中的单独记录之” Map 功能，和其后的值上的子串匹配组成。 如果查询模式被找到，Map 功能简单的将输入键值对放入 HDFS 。由于没有一个Reduce功能的定义，每个Map 实例的产出就是该程序的最终结果了。
结果与讨论：该任务在三个系统上的性能结果显示在图4和图5上。让人惊奇的是，系统间的相关差异在这两个图形中不一致。在图4中，两个并行数据库执行大致相当，比Hadoop快了约2倍较多（ore than a factor of two faster in Hadoop）。但在图5中，DBMS-X以及Hadoop 的性能却不到Vertica的二倍。原因在于数据处理量在这两个实验（experiments）中极不相同（varies substantially）。就图4的结果而言，非常少的数据被处理（535MB/节点）。这导致了Hadoop的“并非毫无意义的启动阶段消耗”（non-insignificantstart-up costs）成为性能的限制因素。如将在5.1.2中描述的一样，对短暂的查询（short-runningqueries）而言（比如，小于一分钟的查询），Hadoop的启动阶段消耗在执行时间上占了主要成分。在我们的观察下，我们发现了这样的启动阶段：全速运行于集群的各节点情况下，在所有的Map任务开启前仅耗费10到25秒。进一步的，当分派的Map任务总数增加时，对协调节点活动的中央作业追踪器（central jobtracker）会增加日常开销。应此，这就部分地（slightly ）修复了当更多的节点添加进集群时的日常开销的增加，如图5所示，该修复了的消耗与“用于完成需求处理所需时间”相比，就相形见绌了。
这些图里每个Hadoop 条状的上面的段代表了用于“将输出合并到单一文件”的附加MR作业的执行时间。由于我们作为独立的MapReduce作业运行该测试，所以当“修复后的启动开销再次较之执行剩余任务的工作量占优”时，这些段消耗了图4中的大部分时间，（Since weran this as a separate MapReduce job,these segments consume a larger percentage of overall time in Figure 4, as the fixed start-up overhead cost again dominates the work needed to perform the rest of the task.）即便Grep 任务是可选的，图5中的结果显示了这种合并阶段（combine phase）如何因为“为了打开和合并许多小的输出文件”而持续数百秒。每个Map 实例的产出放于一HDFS 文件，从而即便当每个文件很小，仍旧有许多Map任务以及随之而来的各个节点上的许多文件（and thus even though each file is smallthere are many Map tasks and therefore many fileson each node）。
就1TB/集群数据集实验而言，图5显示了所有系统执行任务的一个情形是：当节点数量增加一倍时，执行时间减半。这点是有理由让人期待的，是因为总数据量是，就该实验而言，从遍布节点的观点来看的一个常量。Hadoop 和DBMS-X性能大致相当，由于Hadoop的启动消耗通过“对该实验而言，增加处理数据量”来摊销（amortized ）掉了。然而，结果清晰的显示出Vertica明显优于DBMS-X 和Hadoop。我们把Vertica的这个胜出归功其以积极进取的方式进行数据压缩（见5.1.3节），当每个节点上存储越多的数据时，这就变得越有效。
4.3 分析任务 （Analytical Tasks）
为了探索对两种类型系统的更加复杂的使用，我们开发了关于HTML文档处理的4种任务。我们首先生成了一个随机HTML 文档的集合，类似于网络爬虫（web crawler）所能够发现的。每个节点被赋予600，000个唯一HTML文档的集合，每个文档有独立的URL。在每个文档中，我们用齐夫分布，来随机生成到其它页面集的链接。我们同时生成两个“对模拟用于http服务器通信的日志文件很重要的”附加数据集。这些数据集由衍生自HTML文档的值和数个随机生成属性组成。这三个表的模式（schema）如下：
CREATE TABLE Documents (url VARCHAR(100)PRIMARY KEY,contents TEXT );
CREATE TABLE Rankings (pageURL VARCHAR(100)PRIMARY KEY,pageRank INT,avgDuration INT );
CREATE TABLE UserVisits (sourceIP VARCHAR(16),destURL VARCHAR(100),visitDate DATE,adRevenue FLOAT,userAgent VARCHAR(64),countryCode VARCHAR(3),languageCode VARCHAR(6),searchWord VARCHAR(32),duration INT );
我们的数据生成器产生有155 百万用户访问记录量（20GB每节点）的唯一文件（译注：每个用户有约140字节空间），以及每个节点上的18百万排名（Rankings）记录（1GB每节点）。用户日期（visitDate），广告收入（adRevenue）以及源IP地址（sourceIP ）统一的在特定范围内随机挑选（are picked uniformlyat random from specific ranges）。所有其他地址是通过来自真实世界的样本数据集，来统一的挑选的。每个数据文件存储在每个节点上，就好似限定了列的文本文件一般。
4.3.1 数据装载（Data Loading）
我们现在来描述装载用户访问以及数据集排名的过程。由于将在4.3.5节中讲述的原因，仅仅Hadoop 需要直接将文档文件装载到内部存储文件系统。DBMS-X和Vertica都执行一用户定义函数UDF，用以处理运行时每个节点上的文档，并将数据装载到临时文件中。我们对该方法的基准测试值时间（较之装载时间）消耗的常用支出说明原因。因之，我们不提供装载数据集的结果。
Hadoop：不类似Grep 任务的数据集， 不经修改的直接上载到HDFS中，用户访问以及排名数据集需要修改，从而第一列和第二列被tab分隔符分割，且其余所有在每一行中的字段被唯一分隔符分割。由于在MR模型中没有模式，为了在运行时获取不同的属性，每个任务中的Map以及Reduce 功能必须通过将分隔字符放入字符串去手动的分割值。
我们写一个定制数据装器（custom data loader ），并行的执行于每个节点上并读取数据集上的每一行。准备所需数据，其后将元组（tuple）以纯文本文件形式写到HDFS。以这种方式装载数据会比命令行工具方式慢三倍。但是无需我们在Hadoop中写用户输入句柄；MR程序可以在数据文件上使用Hadoop的键值文本输入格式（KeyValueTextInputFormat）接口，自动的由tab分隔符分割文本文件的行成为键值对。再次的，我们发现其余数据格式操作，诸如顺序文件输入格式（SequenceFileInputFormat）或者定制可写元组（ custom Writable tuples）， 将会导致了慢速的装载以及执行时间的下降。
DBMS-X:我们用在4.2节中描述过的装载程序来使用DBMS-X。排名表（The Rankings table）经过集群上页面URL(pageURL)的哈希分区以及数据在每个节点上由页面排名来排序。类似的，用户访问表在目的URL(destinationURL )上被哈希分区以及通过每个节点上的访问数据来排序。
Vertica：类似于DBMS-X， Vertica 用4.2节中讨论过的大块装载命令（bulkload commands）以及通过“可访问数据和页排名列”来各自独立的排列用户访问以及排名表。
结果和讨论：既然由于装载用户访问和排名数据集的结果是类似的，那我们就只提供装载更大的用户访问数据结果在图三中。就像装载Grep 535MB/节点的数据集（图一），每个系统的装载时间的增加是随着使用节点数的增加而增加的。
4.3.2 选择任务 （Selection Task）
选择任务（Selection Task）是一个轻量级的过滤器，用于找到1GB/节点环境下，排名表中的页面URL（pageURLs），且页面排名高于某用户定义的阈值（threshold）。就我们的实验而言，我们将这个阈值设置为10，这将产生出各节点上每数据文件约36000条记录。
SQL命令：数据库管理系统DBMS用以下简单的SQL状态去执行选择任务：
SELECT pageURL, pageRank FROM Rankings WHERE pageRank > X;
MapReduce 程序：MR程序仅适用单一Map功能。该功能会基于域分隔符去分离输入值，以及，只要页面排序是高于阈值话，就输出记录的页面 URL( pageURL ) 和页面排名（pageRank ）作为一个新的键值对。 该任务无需Reduce 功能， 那是因为在排名数据集中的每个页面 URL 是全部节点范围内唯一的。（译注：因为唯一，所以无需合并，Reduce的功能就是用于后期合并，所以该情况下，Reduce无所用武 ）。
结果与讨论：如我们在Grep 任务中讨论过的，该实验的结果，显示在图6， 再次强调了，通过集群伸缩范围级别的更明显的因子，并行DBMS做的比Hadoop要好（the parallel DBMSs outperform Hadoop by a rather significant factor across all cluster scaling levels）。尽管所有系统的相关性能在当节点数以及数据总量都增加时，都会下降，Hadoop 在这方面的趋势尤其明显。比如，在1个节点和10个节点的实验中，执行时间几乎有50%的不同。这再次是由于以下原因：当更多节点添加到集群中时，Hadoop所增加了的启动消耗，这会使短期（short-running）查询的总查询时间中成比例的更大的部分被消耗掉。
另一个并行DBMSs 之所以超越了Hadoop 的原因在于：Vertica 和DBMS-X都在页面排名列上使用了一个索引，并 存储已经被页面排名排序了的排名表。因此，执行该查询是小菜一碟。还应当注意的是尽管Vertica的绝对时间剩余很少（absolutetimes remain low），其相应性能随节点增加下降（its relativeperformance degrades as the number of nodes increases ）。
但是由于节点如此快速的完成了执行查询，系统就被充斥于太多节点涌现的控制信息，这将使系统耗费更多时间来进行处理。Vertica 使用一可信消息层（reliable message layer）用于查询散布（querydissemination）以及承诺协议处理【参见：遍布广域组织的通讯系统】，我们相信，在多于仅没几打节点用于处理查询时，有可观的日常消耗（we believe has considerable overheadwhen more than a few dozen nodes are involved in the query）。
4.3.3 聚合任务 （Aggregation Task）
我们下一个任务是要求每一个系统去计算，产自用户访问表中每一个源IP的，广告收入（adRevenue）的总量，由源IP列来分组（group）。我们同样运行了该查询的一个变体（variant），这里我们通过源IP列的七字符前缀（seven-characterprefix）来分组，以度量查询性能在“减少分组的总量后的”效应。我们设计该任务用于度量在单一只读表上并行分析（parallelanalytics）的性能，这里节点之间需要交换中间数据，以计算最终结果。不考虑集群中的节点数，该任务总会产出250万条记录（53MB）；查询遍体会产出2000条记录（24KB）。SQL命令：用于计算广告收入总量的SQL命令如下：
SELECT sourceIP, SUM(adRevenue)FROM UserVisits GROUP BY sourceIP;
变种查询（The variant query）是：
SELECT SUBSTR(sourceIP, 1, 7), SUM(adRevenue)FROM UserVisits GROUP BY SUBSTR(sourceIP, 1, 7);
MapReduce 程序：不似先前的任务，该任务的MR程序由Map 以及Reduce两个功能共同组成。Map功能首先根据域分隔符（field delimiter）分割输入值，然后输出源 IP 字段（作为输入键），以及将广告收入字段作为新的键值对。对变体查询，仅仅使用源 IP 的头七个字符（代表了头两个八位字节， 每一个作为三位数字存储）(representing the first two octets, each stored as three digits)。这两个Map功能共享了相同的Reduce 功能，从每个源 IP 去简单的加和所有广告收入值，然后输出前缀以及收入总和。我们也使用了MR的合并特性（Combinefeature）来实施，在数据传输到Reduce 例前的，“前聚合”（pre-aggregate），这将成倍数的提升第一个查询的执行时间【参见：MapReduce: Simplied Data Processing on Large Clusters】。
结果与讨论：聚合任务实验的结果在图7和图8中，再次显示了两个DBMS明显超过Hadoop。DBMS通过每个节点上扫描其本地表去执行这些查询，萃取出源IP以及广告收入字段，并执行本地分组。这些本地分组然后在查询协调器（query coordinator）下合并，产出结果给用户。图7中的结果显示了两个DBMS对大数据组而言，执行大致相当，那是因为他们的运行时间被“传输大数量本地组以及在协调器中归并它们的消耗”所统摄。就该实验使用更少的节点，Vertica在某种程度上表现更佳，那是因为其需要读取的数据更少（由于它可以直接获取源IP以及广告收入列），但是在增加更多的节点时系统将会稍稍变慢。
基于图8的结果，可以认为当对该任务处理更少的分组时，使用列存储系统更有优势。这是由于两列存取（源IP以及广告收入），相对于每用户访问元组的每200字节，仅由20字节组成的缘故，因此相对更少的组需要归并，从而通讯消耗相对于非变体计划（non-variantplan）要低得多。Vertica 可以超越其余两个系统，就在于不去读取用户访问元组的未用到部分。
注意到所有系统的执行时间，就“任意数量的节点”而言是一致的（当节点数量增加时，Vertica微小的下降）（moduloVertica’s slight slow down as the number ofnodes increases)。由于该程序基准测试值需要系统在全部数据集范围扫描，故运行时间总是受“衡量顺序扫描性能和每个节点的网络再分配”的约束。
4.3.4 联合任务 （Join Task）
联合任务由两个子任务组成，它们在两个数据集上执行复杂的计算。该任务的第一部分，每个系统必须找到源IP，该源IP将生成在一特定数据范围内的收入（generated the mostrevenue within a particular daterange）。一旦中间结果被生成，系统必须于该间隔中（译注：map 和reduce过程之间有一个间隔）计算所有访问过的页面的平均页面排名（pageRank）。在这个实验中，我们使2000年1月15号到22号这一周，匹配了用户访问表中约134000条记录。
该任务的凸显特性是它必须消耗两个不同的数据集（it must consume two data different sets），并且将它们联合起来（join）以找到排名对和匹配页面URL和目的URL值的用户访问记录。该任务通过“在大数据量使用相当复杂的操作”给各个系统的压力。其性能结果也是关于“DBMS的查询优化器产出有效率的联合计划”有多好的指示（howwell the DBMS’s query optimizer producesefficient join plans）。
SQL命令：作为与下述MR程序的复杂性之对比，DBMS只需要两个相当简单的查询来完成任务。第一个状态生成一临时表，并用之存储SELECT状态的输出，该SELECT将连接用户访问以及排名并计算聚合（ performs the join of UserVisits and Rankings and computes the aggregates ）。一旦该表占一定地位后，用第二个查询来输出带有最大总收入字段的记录就无足轻重了（Once this table ispopulated, it is then trivial to use a second query to output the record with the largest totalRevenue field）。
SELECT INTO Temp sourceIP,AVG(pageRank) as avgPageRank,SUM(adRevenue) as totalRevenueFROM Rankings AS R, UserVisits AS UVWHERE R.pageURL = UV.destURLAND UV.visitDate BETWEEN Date(‘2000-01-15’)AND Date(‘2000-01-22’)GROUP BY UV.sourceIP;SELECT sourceIP, totalRevenue, avgPageRankFROM TempORDER BY totalRevenue DESC LIMIT 1;
MapReduce 程序：由于 MR 模型没有内在的能力去联合两个或多个分离的数据集，实现了联合（ join ）的 MR 程序必须分为三个独立阶段。各个独立阶段的实现合起来作为Hadoop中的单独 MR 程序，但是在前一个阶段完成之前不能开始执行。
阶段一： 第一个阶段过滤期望的数据范围外的用户访问记录，其后联合具有资格的记录和来自排名文件的记录。MR程序初始化的将所有用户访问数据以及排名数据文件作为输入。
Map 功能：对每个键值输入对，我们通过，当在分隔符（delimiter）上分割值时，对字段的计数来判断其输入类型。如果是一个用户访问记录，我们就使用基于数据范围谓词的过滤器。这些具有资格的（qualifying）记录被生成为格式如（destURL, K1）的复合键，K1指示了其为一个用户访问记录。所有的排名记录被以（pageURL,k2）的形式生成，K2指示了其为一个排名记录。这些输出记录通过使用用户提供的“仅在组合键的URL上哈希的”分区函数被重分配（repartitioned）。
Reduce 功能：Reduce 功能的输入是一个以URL序单一已排序记录运行。对每个URL，我们将其值分割到基于组合键的标记组件的两个集中(based on the tag component of thecomposite key)。该功能然后形成俩个集合的叉积（crossproduct）以完成联合，并输出一新的键值对，源IP作为键，元组（页面URL， 页面排名，广告收入）（pageURL, pageRank, adRevenue）作为值。
阶段二 ：下一个阶段计算总的广告收入以及基于阶段1产生的源IP的页面排名。该阶段使用Reduce 功能，为了聚集单独节点上特定源IP的所有记录。我们使用Hadoop API中的同一个Map 功能来支持记录直接用于分割处理（ to supplyrecords directly to the split process）【参见：/和MapReduce: Simplied Data Processing on Large Clusters】。
Reduce功能： 对每一个源IP， 该功能加和广告收入并计算平均页面排名，保留有最大的总广告收入的一个。每个reduce实例产出单一记录，其源IP作为键，值作为形如（平均页面排名，总收入）的元组（avgPageRank，totalRevenue）。
阶段三： 在最终阶段中，我们再次仅需要定义一单一的reduce功能，其使用前一阶段的输出来产生最大总广告收入记录。我们仅执行单独节点上Reduce 功能的一个实例，扫描从阶段2中而来的所有记录，并找到目标记录。
Reduce功能：该功能处理各个键值对，并记录下（keepstrack of）有最大总收入字段的记录。由于Hadoop API并不会很容易的暴露Reduce实例将处理的记录之总数，所以没有什么办法让Reduce功能知晓其处理的是否为最后一条记录。因之，我们重写了（override）闭合回调方法（closing callback method），这样就可以使MR程序在其存在以前(译注：指的是谁存在以前？)正确的产出最大记录。
结果与讨论：该任务的性能结果显示在图9中。因为系统的优化bug所致，我们不得已稍稍改变用于Vertica 的100个节点的实验所用SQL，这是为何Vertica执行时间随节点从50扩大100而增加的原因。但即便是这种增加，仍然可以清晰的看到该任务会导致执行的介于“Hadoop和并行数据库系统”之间的最大不同。这种不同的原因是双重的（two-fold）。
首先，尽管查询的复杂度增加了，Hadoop的性能却再次的可以从磁盘中读取的大用户查询表（20GB每节点）的速度限制住了。MR程序必须执行一个完整的表查询，与此同时，并行数据库系统可以利用集群化索引的用户访问数据（clusteredindexes on UserVisits）。访问数据（visitDate）显著的下降了需要读取的数据量。当对Hadoop的查询之不同部分的消耗进行分解时，我们发现，不管集群中的节点数的话阶段2和阶段3各自平均消耗24.3秒，12.7秒。作为对比，在第一阶段，包含了“读取用户访问以及排名表的”Map任务，花费了1434.7秒来完成操作。有趣的是，这大致“对原始I/O从磁盘读取用户访问和排名表”会耗时600秒并有其后的300秒用于分割，解析以及对各种属性进行反序列化工作。因之，CPU 日常消耗需要解析这些忙碌的表（parse these tables onthe fly），对Hadoop是一个限制因素。
其次，并行DBMS可以利用“用户访问数据和排名表两者都被联合键分区”这一事实。这意味着两类系统都可以执行每个节点上的本地连接，而无需连接之前的再分配（repartitioning）的网络消耗。因此，它们只需只需在“排名表和各个节点上的用户访问表之选择区域”之间执行一本地哈希连接。
4.3.5 用户定义函数UDF的聚集任务 （UDFAggregation Task）
最后是一个常用作页面排名计算组件的任务：对数据集中的每个文档计算内部链接数。特别的，就该任务而言，系统必须读取各个文档文件，并搜寻内容中显现的所有URL。系统然后就必须对每个唯一URL而言，统计“在整个文件集范围内引用特定URL的”唯一页面的数目。正是这种任务类型被认为是MR的常用之所。
对这个任务我们做了两个调整，以便使Hadoop更容易的进行处理。其一，我们允许自引用包含在总计之中（we allow theaggregate to include self-references），就Mao功能发现其在处理中的输入文件名字而言，这并非毫无意义。其二， 在每个节点中我们拼接（concatenate）HTML文件到一个更大的文件，在HDFS中将这多个大文件进行排序。我们发现这成倍的提升了Hadoop的性能，并避免，当一个大数量的文件在系统中排序后的，带有中央HDFS主程序的内存问题（avoid memory issues with the central HDFS master）。
SQL命令：为了在并行DBMS中执行该任务，需要一个用户定义的函数F，该函数解析文档表（Documentstable）中每条命令的内容，并产出URL到数据库中。该功能可以用多用途语言（general-purpose language）语言书写，并且和以下讨论的Map程序完全相同。在这个函数F中， 我们用URL的列表填入一临时表，其后执行一简单的查询来预测导入链接数（we populate a temporary table with alist of URLs and then can execute a simple query tocalculate the inlink count）：
SELECT INTO Temp F(contents)FROM Documents;SELECT url, SUM(value) FROM Temp GROUP BY url;
尽管该用户定义函数 UDF 很简单，我们仍然发现实践中很难在 DBMS 中是实现这个函数。
就DBMS-X而言，我们把Hadoop中使用的MR程序翻译到相应的使用POSIX正则表达式库的C程序，以查询文件的链接。对每一个在文档内容中找到了的URL， UDF返回数据库引擎一新的元组（URL, 1）。我们最初想要以二进制大对象BLOB字符形式把各个HTML文档存储到DBMS-X，之后在各个文档上，且在数据库内完整的执行UDF。但是却没能做到这一点，那是因为我们系统内部的一个bug。取而代之的是，我们修正了用户定义函数UDF，在本地磁盘上打开各个HTML文档，就好象其存储于数据库中一般，并处理其内容。尽管该方法与我们必须Vertica中所采用的方法（见下）很类似，DBMS-X 用户定义函数并不会作为就数据库而言的外部处理去执行，并且不需要任何批量装载工具（bulk-loadingtools）来导入萃取的URL。
Vertica 目前不支持用户定义函数UDF，因此我们不得不用两个阶段来实现该基准（benchmark）。在第一阶段，我们使用一修改过的DBMS-X的UDF版本来从文件中萃取URL。但然后把输出文件写到各个节点的本地磁盘系统。不似DMBS-X， 该程序执行是一个独立于数据库系统之外的处理过程。各个节点然后装载这些文件的内容到一个使用Vertica批量装载工具的表中。当这个结束了以后，我们然后执行前述的查询来计算每个URL的导入链接（inlink）数。
MapReduce 程序：为了适应“所有数据必须定义为键值对形式的”MR模型，各个HTML文档由其行进行分割，并把行的内容作为值，且“把文件中出现的行号”作为键给Ma功能。Map功能然后就用正则表达式来查找各行中所有的URL。对每个找到了的URL，Map功能产出URL以及整数1作为新的键值对（译注，就是产生元组（URL,1））。有了这些记录以后， Reduce功能就简单的对“与给定键相对应的值”进行计数，并输出URL和计算后的导入链接计数作为程序的最终输出。
结果与讨论：图10的结果显示了DBMS-X和hadoop两者，就该任务而言，都有相近的常量执行性能。因为各个节点有相同的文档数据量来处理，并且当更多的节点添加到该实验中，该数据总量保持为7GB左右常量。如我们所料，Hadoop的附加操作“合并数据到HDFS中的一个单一文件”渐渐的变慢，那是由于单一节点必须处理的输出数据总量在新的节点增加进来时随之增大。DBMS-X以及Vertica 的结果显示在图10的状态条中，其底部段表示了执行用户定义函数/分析程序（UDF/parser）以及装载数据到表所消耗的时间，顶端是实际执行查询耗用的时间。DBMS-X 比Hadoop执行更差，那是因为UDF与存储在数据库外的输入文件一行一行的交互模式每次都有额外的日常消耗之缘故。Vertica的低效是“必须解析DBMS外部的数据以及先于将其装载进系统，先实现本地磁盘上的中间结果”所致。
5. 讨论
我们现在来讨论更广泛的关于基准结果的内容以及对各系统的原始数据不能达意的特定方面（that the raw numbers may not convey）作一些评价。在上述的基准中，DBMS-X和Vertica两者执行大多数任务，在所有的级别上都远快于Hadoop 。在下一个分段（subsections ）描述中中，远较前一分段为详细，描述了剧烈的性能差异之原因。
5.1 系统视角 （System-levelAspects）
在该节中，我们描述了在系统级别上的架构决策如何的影响到两类数据分析系统的相关性能。由于安装和配置参数可以在执行系统的最终性能上导致显著差异，我们以讨论“这些参数的相对简单设置”始。然后，我们讨论一些低级别的实现细节。当这些细节中的一部分以本质的方式影响了性能（例如，MR实质上在装载时并不转换数据，排除了各异的I/O优化以及导致CPU消耗增加的必要运行时解析），令一些细节更强调实现的方面（如，MR的高启动消耗）。
5.1.1系统安装， 配置以及调优 （Tuning）
我们已经安装了Hadoop以及不怎么困难的就运行了作业（running jobs with little effort）。安装系统仅需在各个节点上设置好数据目录，并部署好系统库和配置文件即可。为配置系统通过“反复试验（trial and error）”去优化性能。我们发现某些参数，诸如排序缓存的大小（size of the sort buffers）或者复制份数（number of replicas）对执行性能毫无影响，与此相反，另外一些诸如使用更大块的大小（larger block sizes）这样参数，显著的提升了性能。
DBMS-X安装过程相对的很直接（straightforward）。GUI 引导用户通过集群中的某一节点的初始步骤，在之后准备一“用于在其它节点上并行的安装工具的”文件来完成安装。尽管有这一简单过程，我们发现DBMS-X为了启动运行查询的配置是很复杂的。一开始，我们受挫于所有的但大多是却很基本操作的失败。最终我们发现各个节点的kernel把虚拟地址空间分配总量（the total amountallocated virtual address space）限制住了。当触碰到该限制时，新的进程不能被生成，故而DBMS-X操作就失败了（fail）。即便这是我们自己的管理错误（error），我们还是提及了这一点，那是因为我们惊讶于DBMS-X的广泛系统探测以及自我调整配置（extensive systemprobing and self-adjusting configuration）不能够侦测到这一限制。这个缺陷在我们最初的hadoop成功之后带来的却是失望。
即使是这些最初的议题（issues）被解决了，且我们让DBMSX跑起来了，我们还是例行公事般的被其它内存限制问题给拌住脚（were resolved and we had DBMSX running, we were routinely stymied by other memory limitations）。我们发现某些默认配置，诸如缓存池的大小以及排序堆，对现代系统而言都过于保守（译注：估计当时开发这些系统时硬盘空间都较小，所以当时的默认配置设置也较小所致）。此外， DBMS-X被证明是就“为改变的条件而调整内存分配”而言是无效的。比如，系统自动的扩大缓存池：从默认的4MB到仅仅5MB（我们之后将强迫其扩展到512MB）。系统警告我们执行性能可能会下降，如何我们增加排序堆的大小到128MB的话（实际上，系统执行性能提高了12倍）。手工的去修改某些参数会导致系统自动的去调整其它一些参数。有时偶尔的，这种手工和自动调整的组合会导致DBMS-X的配置引发其在下次系统启动时，拒绝系统自举（boot）。由于大多数配置设置需要DBMS-X在运行时来调整它们，我们不幸的采用无失败安全模式来重新存储前一阶段的状态（ it was unfortunately easy to lock ourselvesout with no failsafe mode to restore to a previous state） 。
Vertica 的安装相对简单，作为一RPM（译注：应为一种nix系统上安装软件的工具）部署于各个节点。一个和RPM绑定的附加配置脚本用于构建目录元数据（catalog meta-data ）以及调整某些kernel参数。数据库调优被降到最低限度，并通过资源管理器来完成（Database tuning is minimal and is done through hints to the resource manager）；我们发现默认配置工作的很好。该简化的调优方法的负面效应是没有显示的机制用于决定何种资源被分配到查询，或者是否有一种方法对每个查询资源配置去进行手工的调整。
我们努力的另一发现是（Thetake-away from our efforts is）我们发现并行DBMS较之Hadoop 在安装以及适当配置方面的挑战要大的多。考虑到易于安装以及配置在不同的并行数据库产品上，这显然有一个显著差异。数据库系统的一个小小的优势是所需的调优总在查询执行之前已经完成，并且某些调优参数（如，排序堆大小）对所有任务而言都使用。作为对比，对Hadoop我们不仅需要调优系统（如，块大小），而且我们偶尔还需要调优各个体任务以在系统中良好运行（如, 改变代码）。最后，并行数据库产品有一工具帮助调优过程的分析，而就Hadoop，我们只能诉诸反复试验的调优手段了；很明显的,一个更加成熟的MR实现应当包含类似的调优工具。
5.1.2 任务启动 （Task Start-up）
我们发现MR 程序在所有节点以完全负载能力运行前，会耗用一定的时间。在有100个节点的集群上，在第一个Map任务开始执行前， 从一个作业被传递到作业追踪器（JobTracker）的花费超过了10秒，且直到集群中的所有节点执行了该作业时花费了25秒（it takes 10 seconds from the moment that a job is submitted to the JobTracker before the first Map task begins to execute and 25 seconds until all the nodes in the cluster are executing the job）。这和【参见：MapReduce: Simplied Data Processing on Large Clusters】中的结果相吻合，在有1800个节点的集群上的数据处理速率在约60秒中并没有达到峰值。该“冷启动”（cold start）特性是Hadoop 实施（同时也可能是谷歌的）的病症，并没有被实际的MR模型本身继承。例如， 我们同样发Hadoop的前一个版本会对一个节点上的各Map以及Reduce实例生成一新的JVM进程，我们发现了在大数据集上运行作业所增加的日常消耗；使JVM重用最近版本Hadoop中的特性，这提升了MR的结果达10–15%。
作为对比，并行DBMS在OS系统启动时（boot time）亦同时开启，并通常被视作一个保持等待查询执行的状态（considered to always be “warm”）。而且，所有现代DBMS被视作用多线程和多进程来进行处理，这使得目前运行的代码可以接受附加的任务以及执行排程时的进一步优化。最小化启动时间是DBMS的早期优化之一，并注定以某种MR系统应当能够与之合并的且无需“大规模重写基础架构”的系统。
5.1.3 压缩（Compression）
几乎所有DBMS（包括了DBMS-X和Vertica）都允许对存储数据进行压缩操作。压缩到原先的6至10倍的空间利用率并非不常见。Vertica的内部数据陈述形式（representation）就数据压缩是高度优化了的，并有一个执行引擎直接在压缩后的数据之上进行操作（即，避免了任意时刻可能的解压数据操作）（it avoids decompressing the data duringprocessing whenever possible）（译注：可以直接对压缩数据进行逻辑处理而无需解压后再处理么？）总体而言，既然大数据集上的分析任务常常受I/O限制（bound），用CPU周期（需要解压输入数据）交换I/O带宽（压缩数据也就意味着所需读取的数据更少了）是一个好的策略，并且转变为更快的执行。在执行可以直接在压缩后的数据上处理的情况下，经常出现无交易权衡（trade-off）的情况（译注：应指CPU周期和I/O带宽两种相对稀缺计算资源），且压缩明显的胜出（译注：作者似应采用了牺牲CPU周期来换取I/O带宽的策略）。
Hadoop 及其底层的分布式文件系统对输入数据支持锁级别和文件级别的压缩。然而我们却发现，hadoop性能的技术进步以及一些例子中实际的降低了执行效率（that neither technique improved Hadoop’s performance and in some cases actually slowed execution）。这同样需要我们在“改变代码或者准备输入数据”上作更多的努力。同样需要注意的一点是压缩并不用于初始MR基准【参见MapReduce: Simplied Data Processing on Large Clusters】。
为了利用Hadoop中的块级压缩（block-level compression），我们首先必须把数据文件切割为（split the data files into）各个本地节点上的多个小文件，然后就用gzip工具来压缩各个文件。以这种方式来压缩数据，就简化（reduced）各个数据集相对于初始大小而言，20到25个百分点。Hadoop当文件被压缩完时，会自动的侦测到，并在它们进入Map实例的当口，将对这些压缩文件联机进行解压缩（decompress them on the fly），因此为了运用压缩数据，我们无需改变我们的MR程序。尽管有较长的装载时间（如果其包含了分割以及压缩过程），Hadoop 使用了块级压缩（block-level compression）“当计算密集型（CPU-bound ）任务执行性能下降50%时”，将在没几秒内减慢大多数任务（Hadoopusing block-level compression slowed most the tasks by a few seconds while CPU-bound tasks executed 50% slower）。
我们也试着用记录级压缩去执行该基准。这需要（1）用Hadoop API写一个定制元组对象，（2）调整数据装载程序以转换压缩记录，并序列化客户元组，以及（3）重构（refactor）各基准。我们起初认为这将提升计算密集型任务的性能，这是基于“Map和Reduce任务不再需要由分隔符来分割字段”的考虑（split the fields by the delimiter）。然而我们却发现该方法实际执行性能，在数据压缩率仅为10%时，较“块级压缩（block-levelcompression）”为差。
5.1.4 装载与数据布局 （Loading and DataLayout）
并行DBMS在装载时有识别输入数据文件的机会。这允许某些优化，诸如分别的对表中的各个属性进行排序（就像如Vertica这样的列存储所做的一样）。就“仅接触到表中子集属性的那部分”只读查询而言，这种优化可以通过“允许特定查询所不能获取的那部分属性弃置于（be left on）磁盘并不在读取”来提升性能。类似于上述提及的压缩优化，这会保存关键性的I/O带宽。MR系统，当其装载到其分布式文件系统时，默认的不会转换数据，并因此不会改变输入数据的布局（layout），这将排除该类的优化机会（precludesthis class of optimization opportunities）。进一步而言，Hadoop 在运行相同任务时，远较并行DBMS有CPU密集（CPU intensive）的特点，因为Hadoop必须解析（parse）以及在运行时去并行化（deserialize）输入文件中的记录，与此同时，并行DBMS在装载时进行解析（do the parsing at load time）并快速的，本质上以0成本方式，从元组中萃取（extract）出属性。
但MR的简化后的装载过程确实使得装载较之DMBS大为简单以及迅捷。我们在4.2.1节以及4.3.1节的结果显示了Hadoop达到装载吞吐量（throughputs） 较Vertica快了3倍，且比DBMS-X快了20倍。这揭示出仅对分析任务上给定类型的数据进行一次性装载时，“在DBMS上制作索引以及改组”不太划得来（ it may not be worthit to pay the cost of the indexing andreorganization cost in a DBMS）。这同样的强烈的提示了：一DBMS可以从“允许用户直接获取的就地操作模式（“insitu”operation mode），以及查询文件存储于本地文件系统”当中获益。
5.1.5 执行策略 （ExecutionStrategies）
如先前所述，并行DBMS中的查询规划器（the query planner）仅仅在确有必要时，才小心翼翼的转换节点间的数据。这允许系统，基于数据的字符，优化连接算法（join algorithm），并在无写中间数据集情况下，执行面向推的消息（perform push-oriented messaging）。随着时间的流逝，MR的拥护者应当学习用于并行DBMS的技术，并和与其模型密切相关的概念合作。设若这样做了的话，我们相信MR框架的性能将再次的显著得到提升。
此外，并行DBMSs 构建了一个完整的查询规划，该查询规划在查询开始时，被发送到所有处理节点。由于数据只在必要时，会在站点间以推的方式传送，在处理过程中没有控制消息（control messages）。作为对比， MR系统大量使用了控制消息（control messages）来使处理同步（ to synchronize processing），由于增加了的日常开销，这必然导致较差的性能。Vertica 同样也经历了这个问题带来的干扰，但是干扰影响范围却小的多（见4.2节）。
5.1.6 故障模型 （Failure Model）
如前所述，当对事物处理（transactions）不提供支持时，MR以一种大多数并行数据库系统所不能的方式，从“查询执行到一半的”故障中恢复。随时间推移，由于并行DMBS将部署于更大的集群，中等规模查询的硬件失败之可能性会不断增加。因此，就长时间运行的查询而言，实现这样的故障容错模型（Fault tolerance model）可能就很重要了。尽管提升DBMS的故障容错特性是一个显而意见的好主意，同时我们要提防这样的想法：贡献了巨量的计算集群以及蛮力计算方式，去计算“那些复杂软件以更小的硬件以及消耗更少的能量的方式却同样可以执行”相同的处理，或者在更短的时间内，从而排除复杂的故障容错模型之需要（hereby obviating the need for a sophisticated fault tolerance model）。一个数千节点的集群，类似Google, Microsoft, 以及Yahoo!的运行耗费了许多资源，我们的结果显示了，就许多数据处理任务而言，并行DBMS可以在使用更少的节点情况下，达到相同的效能。就其本身而论，理想的方式是使用一个有适度并行计算的高性能算法（use high-performance algorithms with modestparallelism）而非更多大型集群上的蛮力计算方式。
5.2 用户级别视角 （User-level Aspects）
一个数据处理系统的性能与用户或者组织无关，如果这个系统不可用的话。本节中，我们讨论各个系统的“当依据基准程序测试的指导，可能提升或抑制应用开发时，我们所遇到的来自用户级观点的”方面（from a userlevel perspective whileconducting the benchmark study that may promote or inhibit application development andadoption）。
5.2.1 灵活使用 （ Ease of Use）
一旦系统上线且数据已装载，程序员然后就开始写查询或者他/她们所需的用于执行任务之代码。和其他程序类似，这常常是一个迭代（iterative）的过程：程序员写了一丁点代码， 对其测试然后写更多。程序员可以容易的决定，在两种类型的系统中，是否他/她的代码是语法正确的：MR框架可以对户代码编译与否进行核查，且SQL引擎可决定查询语法分析（queriesparse）是否正确。两类系统都提供了运行时支持，以方便用户对其程序进行调试。
考虑程序员书写查询的方式是值得而为的。Hadoop中的MR程序首先是用Java写的（尽管其他的语言绑定也存在）。大多数程序员相对于其他语言技术，对面向对象的命令式的编程，诸如SQL更加熟悉。那就是说，SQL作为许多大学程序教程，并完全可移植（fairly portable ）–我们可以在DBMS-X以及Vertical之间作些许修改就可共享SQL命令。
总体而言，我们发现使得MR程序启动并运行于Hadoop，相对于其他系统会更加的容易。我们无需为了开启数据处理，而构建一个模式或者注册用户定义函数。然而，在获取我们的初始结果后，我们扩展了标准检查程序（benchmark）任务的数目，使得我们增加了新的列于我们的数据集之上。为了处理这种新的数据， 我们必须调整我们现存的MR代码，并重新测试各个MR程序，以确保其在“关于数据模式的”新的假设下之工作。进一步而言，Hadoop 中的一些API方法在“我们升级到更新的版本”之后被弃置了，这就再次需要部分的重写（rewrite）我们的代码。作为对比，一旦我们构建了初始化的基于SQL的应用，那么尽管对我们的标准检查程序模式（benchmark schema）作了一些改变，我们仍无需调整代码。
我们认为尽管对开发者而，以MR为学习的起点而言会更加容易， 但就应用开发者来说，维护MR程序可能会随着时间流逝而导致很大的痛苦（maintenance of MR programs is likely to leadto significant pain for applications developersover time）。同样如我们在3.1节中所认为的， 在两次部署，或者两个不同的数据集间，重用MR代码是困难的，这是因为就MR模型中的数据而言，缺失了显式的模式表达（explicit representation of the schema）。
5.2.2 附加工具 （Additional Tools）
Hadoop 伴生于初步网页接口（rudimentary web interface），允许用户浏览分布文件系统的内容，并侦测作业的执行。任何附加工具现在最可能以内部方式开发（译注：非外包方式）。
SQL数据库，就另一方面而言，有成堆的现存工具与应用可用于报告（reporting）与数据分析（dataanalysis）。整个软件工业界围已开发出绕着提供DBMS用户的第三方扩展。这种类型的软件有许多，包含了（1）数据可视化（data visualization），（2）商务智能（business intelligence），（3）数据挖掘(data mining)，（4）数据重现（datareplication），以及（5）数据库设计自动化（automaticdatabase design）。由于MR技术仍然刚刚诞生（nascent），对MR的类似软件市场还很小。然而， 由于潜在用户的增长，许多现存的基于SQL的工具很可能会支持MR系统。
6. 总结 （CONCLUSION）
该文献中呈现的诸多结果中可以提取一些有趣的结论。其一，在我们所规定的实验规模下，两中并行数据库系统都展示了，在执行不同数据密集（intensive）的分析基准测试下，相对于Hadoop MR的显著的性能优势。五个所有任务平均有100个节点，DBMS-X较之MR快了3.2倍，而Vertica又比DBMS-X快了2.3倍。尽管我们不能验证以下断言（claim），我们仍然认为系统在1000个节点下的相关性能表现还是类似的。（最大的Teradata配置是少于100个节点，但管控着超过4拍字节的数据）。这些数字中的两个是 在拥有少得多的处理器情况下，提供了相同的反应时间的并行数据库系统必然会耗用少得多的能量。集群的在数千节点上的MapReduce 模型是一个蛮力解决方案。尽管社会上谣传说谷歌版本的MR程序要比Hadoop版本的MR跑的快，但是我们没有获取其代码，因而无法测试它。我们对两个MR版本中，“迫使对整个输入文件进行扫描的”运行查询，是否有本质的执行性能不同不能确定。
这种两个数据库系统的性能优势是“过去25年来一系列技术进展”的结果，包括了（1）B树作为一种“选择操作的速度”的指标（execution of selection operations），（2）新的存储机制（如，列导向的）（column orientation），（3）可以直接在压缩后数据上操作的聚集压缩技术，以及（4）查询大量相关数据的复杂并行算法。在类似Vertica这样的列存储数据库的例子中，仅那些需要执行查询的列被实际的从磁盘中读取。再则，列存储数据（column-wise storage of data）会导致更好的压缩因子（compression factors）出现（就Vertica而言，约2.0；就DBMS-X，约1.8；就Hadoop而言，1.25）。这进一步的规约（reduces）用于执行查询的磁盘I/O量。
尽管我们就两个并行数据库系统提供的相关性能的表现毫不惊讶，我们实在是对“相对于数据库，Hadoop是如何简单的配置以及使用”留下了深刻印象。Vertica 安装过程也是很直接的，但对某些系统参数是临时的。另一方面而言，DBMS-X难于适当的配置，并需要供应商的重复支持一获取良好运行所需的配置。对如DBMS-X这样的成熟产品而言，整个经历令人失望。考虑到Hadoop的前述消耗优势（Given the upfront cost advantage that Hadoop has），我们对为什么大量用户团体被其吸引就不奇怪了。
扩展性是另外一个“我们发现受测的数据库系统缺失的”领域。由用户定义类型以及函数来扩展DBMS是一个已经有25个年头的概念了【参见： 16】。我们测试的并行系统中无一对UDF聚集任务，执行了一个好的作业（Neitherof the parallel systems we tested did a goodjob on the UDF aggregation tasks），迫使我们在遇到限制（如，Vertica）与bug时（如，DBMS-X），去发现变通的方法（workarounds）。
尽管所有DB系统对各种各异的软件失效（failures）有容错能力，但毫无疑问的是：MR就“在硬件失效出现时，最小化丢失的工作量上”做的更加出色。然而与这种能力相半生的是潜在的大性能惩罚（large per formancepenalty），这是由于物化（materializing ）map 和reduce之间的中间文件的消耗所致。剩下的还没有回答的就是该种惩罚的程度有多少？不幸的是，合宜的深入该问题需要在通用框架中实现物化与非物化策略两者（implementing both the materialization and no-materialization strategies in a common framework），这就超出了本文献的论述范围。尽管在该领域中是这是清晰的优势，但就“Hadoop之于容错的能力，该因子在实际实践执行中有多重要”却不是完全清晰（Despite a clear advantage in thisdomain, it is not completely clear how significant a factor Hadoop’s ability to tolerate failures during execution really is in practice）。而且， 如果一个MR系统需要1000个节点来匹配100个并行数据库系统节点的性能，当一个查询执行时，有多于10倍的可能性使一个节点失效（fail）。这就是说，对失效的更好容错是任何数据库用户会欣赏的能力（capability）。
许多人发现SQL起初并不好用。这是因为需要在解决问题时，以不同的方式思考， 并且SQL已进化为一个相对于1970年代由Don Chamberlin刚发明时候的复杂语言。尽管大多数语言随时间流逝变得更加复杂， SQL却由于“其许多特性由相互竞争的数据库公司来设计出，其中每家期望包好其自己的属性扩展”而特别的坏（译注：两个和尚挑水喝，三个和尚没水喝）。
尽管有这个缺点， SQL仍旧是一个强有力的工具。考虑以下查询，生成雇佣者列表，由其薪水以及相应的各自薪水的等级排列（即，最高支付的雇佣者获得第一等级）：
SELECT Emp.name, Emp.salary,RANK()OVER (ORDER BY Emp.salary) FROM Employees AS Emp
并行的进行该计算需要产出对所有雇佣者的总排序，跟着的第二个阶段是每个节点调整“每个节点所剩余的记录进行计数的”其记录的排序值（即，那些有严格的小得多的薪水值的节点）。尽管 MR 程序可以并行的执行该种排序， 但却不易使该种查询植入通过聚合的分组 MR 范式（ fit this queryinto the MR paradigm of group by aggregation ）。 RANK 只是诸多有有现代并行数据库系统提供的有力的分析功能中的一个。比如， Teradata 以及 Oracle 这两个并行数据库产品都支持功能的富集（ a rich set of functions ），诸如 win 上的排序记录功能。
两种架构的不同看上去将长期存在下去。MR就“后模式”甚至是“无模式”作出承诺。但这种模式的缺失会引发一系列重要的事件。首当其冲的是，意味着在运行时解析（parsing）记录是不可避免的了，相较于DBMS， 其是在装载时执行的解析（parsing）。这种差异使压缩在MR中的价值较小，并引发两种类型系统中部分的性能差异。没有模式，每个用户必须写定制语法分析器（a custom parser），在多应用间以更复杂的方式应用数据。其次，模式对保持信息来说是必要的，对优化命令式查询是很关键的， 包括了何者指示了存在， 表如何分区， 表基数（table cardinalities），以及于列中捕获了的值分布之直方图（histograms）。
在我们的操作中，从两种系统中有许多需要学习。最重要的是高端接口，如Pig【参见Pig Latin: A Not-So-Foreign Language for DataProcessing】，Hive【参见/】，两者被放于MR基金的顶端， 以及一系列“较MR表达能力为强的”分割中类似的已开发工具，诸如Dryad 【参见Dryad: 来自顺序构建块的分布式并行数据程序】以及Scope【参见Scope: 简单有效的并行处理巨量数据集】。这会使复杂任务，以MR风格的系统书写的代码，变得简单些，并移除一个SQL引擎的大优势，就是（namelythat）它们“于我们的标准检测程序的”任务上花费少得多的代码。就并行数据库而言，我们相信商业以及开源系统两者都显著的提升了用户定义函数的并行性（parallelization ）。因此，两类系统的API有明显的相互融合的趋势（moving toward each other）。这一点的前期证据可以在就Greenplum和Asterdata提供的整合SQL与MR的解决方案中见到。
8. 索引 （REFERENCES）
[16] J. Ong, D. Fogg, and M. Stonebraker.Implementation of data abstraction in the relational database system ingres
Rec., 14(1):1–14, 1983.
[17] D. A. Patterson. Technical Perspective:The Data Center is the Computer
[18] R. Rustin, editor. ACM-SIGMODWorkshop on Data
Description, Access and Control, May 1974
[20] M. Stonebraker and J. Hellerstein.What Goes Around Comes Around
2–41. The MIT Press, 4th edition, .
（完）
