英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料

Clash of the Titans：MapReduce与Spark的大规模数据分析

摘要：MapReduce和Spark是两个非常流行用于大规模数据分析的开放源码集群计算框架。这些框架隐藏任务并行性和容错的复杂性，通过公开一个简单的编程API给用户。在本文中，我们评估MapReduce和Spark框架的主要组件，包括：打乱，执行模型和缓存，通过使用一组重要的分析工作负载。为了进行详细的分析，我们开发了两个分析工具：（1）我们的任意一个MapReduce和Spark任务执行计划的资源利用率，而且直观地显示这种相关性;（2）我们提供的任务执行时间深入分析。通过详细的实验，我们量化MapReduce和Spark之间性能差异。此外，我们认为这些性能上的差异，因为两个框架不同架构不同的组件造成的。 我们进一步通过探寻这些性能差异的来源通过一组微基准测试实验。总体而言，我们的实验表明Spark相比与MapReduce在字数，K-均值，和PageRank三个方面分别是约2.5倍，5倍，和5倍的速度。主要的这些加速比的原因是基于散列的组合组件的效率，以及减少CPU和磁盘的过载，由于Spark的RDD缓存开销。一个例外是在排序方面的工作量，MapReduce的速度是Spark的2倍。

1.引言

在过去的十年，在开源分析软件上运行商品硬件使得它更容易运行作业，而此前曾经是复杂和繁琐运行。 例子包括：文本分析，日志分析和SQL查询处理，运行在一个非常大的规模。两种最流行的开源框架适用于如此大规模的数据处理上的商品硬件有：MapReduce[7]和Spark[19]。 这些系统提供简单的API，并为用户隐藏并行任务执行的复杂性和容错。

1.1集群计算体系结构

MapReduce的是国际最早，最知名的大宗商品之一集群框架。MapReduce包括功能编程模型[8]，并在计算阶段进行显式同步。MapReduce的提供了一个简单的编程API，术语是map() 和reduce()函数。Apache Hadoop是[1]MapReduce的一个广泛使用的开源实现。

MapReduce的简单性对用户有很大的吸引力，但其框架工作仍然存在有几个限制。 应用例如机器学习和图表分析迭代处理数据，这意味着会在同一数据上进行多轮计算。在MapReduce中，每一个作业读取输入数据，进行处理，然后再写回HDFS。对于接下来的工作使用先前运行的作业的输出，它必须重复读取，处理和再写入。对于迭代算法，通过读取一次，并且实现迭代多次，MapReduce的模型造成了显着的开销。 为了克服的MapReduce的上述限制，Spark[19]采用弹性分布式数据集（RDDS）[19]执行内存中的数据结构，用于在一组节点中缓存中间数据。因为RDDS可以保持在内存中，所以算法可以非常有效地实现从RDD中实现数据的多次迭代。

虽然MapReduce是专为批量作业而设计的，然而也被广泛用于迭代工作。另一方面，Spark主要是设计为了实现迭代工作，但它也可用于批处理作业。这是因为新的大数据架构使得了多个框架可以一起工作的工作在相同的数据，这些数据已被存储在HDFS [17]上。 我们选择这两个框架，是由于这两个框架已被广泛分布在采用大数据分析。所有主要的Hadoop的厂商，如IBM，Cloudera的，Hortonworks和MAPRbundle，都将MapReduce和Spark捆绑在他们的Hadoop发行版中。

1.2主要架构组件

在本文中，我们进行了详细的分析，以了解如何Spark和MapReduce是如何实现处理批量和迭代工作，以及什么建筑部件在每种作业中发挥关键作用。在特别是，我们（1）解释运行在MapReduce和Spark一组通常是重要的分析工作负载的行为，（2）量化两框架之间的性能差异，（3）把这些性能上的差异，追寻到在他们的建筑构成的差异。

我们确定以下三个结构组件和通过详细的实验评估。研究这些组成部分涵盖了MapReduce和Spark大部分的结构差异。

洗牌：打乱组件负责交换两个计算阶段之间的数据。 例如，在MapReduce的的情况下，数据在地图阶段和处理阶段之间被打乱以此实现同步。打乱组件影响框架的可扩展性。非常频繁的，排序操作就是在这个阶段完成的。外部排序算法，如合并排序，通常需要处理非常大的数据，不适合在主内存中进行。此外，聚合和组合经常进行在一个打乱阶段。

执行模型：执行模型组件确定用户自定义函数是如何转化成物理执行计划。执行模型往往会影响并行任务执行的资源利用率。特别是，我们感兴趣的是（1）任务之间的并行性，（2）计算阶段的重叠，并（3）计算阶段之间的数据流水线。

缓存：缓存组件允许中间重用跨多个阶段的数据。有效的缓存可以提高迭代算法以额外的存储空间在存储器中或磁盘上作为代价。在这项研究中，我们评价可用缓存在不同级别中的有效性包括OS高速缓存，HDFS缓存[3]，快子[11]，和RDD缓存。

对于我们的实验中，我们用五个的工作负载包括Word计数，分类k均值，线性回归，和PageRank。 我们选择这些工作负载，因为它们覆盖了重要的分析负载参数，这些负载对与MapReduce和Spark而言是典型的，同时他们强调的关键架构组件也是我们感兴趣的，因此对这些工作负载进行研究是很重要的。字数用于评估的聚合组件，因为中间数据的大小可以通过地图边合成显著减少。排序是用来评估外部排序，数据传输，和地图和处理阶段之间的重叠，因为中间数据的大小是从大到小的排序。k-均值和PageRank是用来评估缓存，因为它们都是迭代算法。我们相信，我们从这些工作负载对MapReduce和Spark的运行结果可以推广到其他的工作负载具有相似的特性，因此是有价值的。

1.3分析工具

为了帮助我们量化MapReduce和Spark组件在上层建筑之间的差异，以及一套对不同框架重要的分析工作负载的行为，我们制定了以下工具用于这项研究。

执行计划可视化： 要理解一个物理执行计划，以及相应的资源利用的行为，我们关联了相关资源和任务执行计划级别，同时对这种相关性实现可视化，为MapReduce和Spark。

细粒度的休息时间表：要明白的什么地方和什么时间任务推移到关键部件中，我们在Spark源代码添加计时器以提供细粒度的执行时间分解。对于MapReduce，我们从日志文件中提取这些信息得到时间分解

1.4贡献

是本文的主要贡献如下。

（1）我们通过实验彻底了解MapReduce和Spark解决一系列重要的分析工作负载包括批量和重复作业。

（2）我们从详细的定时器框架和收集统计数据上详细解剖MapReduce和Spark，从而量化他们在打乱组件上的区别。

（3）通过详细的分析与相应的资源利用的执行计划，我们通过表现的差异，推出主要的建筑组件的差异。

（4） 我们设计微型测试床实验来进一步解释RDD缓存的不平凡。

本文的其余部分安排如下。第2节，我们提供工作负载说明。第3节中，我们提出我们有详细的分析以及实验结果。最后，我们在第4节展示我们的研究结果进行讨论和总结。

2. 工作负载描述

在本节中，我们确定了一系列重要的分析工作负载包括字数（WC）统计，排序，k均值，线性回归（LR），和PageRank。

如表1所示，所选择的工作负荷集体覆盖典型的批量和反复分析应用的特点系统蒸发散在MapReduce和星火运行。 我们同时评估一通和迭代工作。 对于每种类型的工作，我们将介绍不同的shufFLE选择性（即，map输出大小的到作业输入的比率大小，其表示的磁盘和网络I / O的量要洗牌），工作选择性（即减小输出大小的比率作业输入大小，其表示HDFS的量写入），和迭代选择性（即，输出大小与输入的比率尺寸对于每次迭代，其表示各次迭代交换的数据）。 对于每个工作负荷，给这些选择性代表的I / O行为，我们评估其系统行为（例如，CPU绑定，磁盘绑定，网络绑定）到进一步明确的MapReduce之间的结构差异和Spark。此外，我们使用这些工作负载来定量evalu-吃了关键的架构组件的不同方面，包括（1）洗牌，（2）的执行模型，及（3）高速缓存。 如表2所示，对于洗牌组件，我们评估聚合框架，外部排序和中间数据的转移。 对于都是空化模型组件，我们评估用户定义的函数如何翻译成一个物理执行计划，其重点任务并行，阶段重叠，和数据流水线。 对于缓存组件，我们可以评估缓存的有效性不同级别的缓存输入和中间数据。 如1.2节解释的那样，所选的工作负载集体涵盖所有特性评定所需这三个组件。

3. 实验

3.1 实验装置

3.1.1 硬件配置

我们的spark和 MapReduce 的集群部署在同一硬件上，总共有四台服务器。每一个节点有一个工作在2.9GHz的32位CPU,9个磁盘驱动器每个1T工作在7200转，还有190G的物理存储空间。总的来说，我们四个节点的集群具有 128 CPU 内核、 760 GB RAM 和附加的36 TB的本地存储。硬磁盘提供聚合带宽约为 125 GB/秒的读取和 45 GB /秒的写入到所有节点，来衡量使用 dd。节点连接使用 1 Gbps 以太网交换机。每个节点都运行 64 位红帽子企业 Linux 6.4（内核版本2.6.32）。

作为比较，我们的物理集群硬件规格，大致等同于有约 100 个虚拟机 (Vm) (例如，在 AWS2 m3.medium) 的集群。我们的硬件设置适于评价各种spark和 MapReduce 框架的可伸缩性瓶颈。举个例子， 我们在这个系统中具有足够的物理内核来运行大量的并发任务从而暴露同步开销。然而，实验，可能需要大量的服务器 （例如，评估主节点的可扩展性） 超出了本文的范围。

3.1.2 软件配置

MapReduce 和Spark都部署在 Java 1.7.0 版本

Hadoop︰ 我们使用 Hadoop 2.4.0 版本运行 MapReduce YARN [17]。我们使用 8 块磁盘来存储中间数据，MapReduce，以及HDFS 数据存储。我们为 HDFS配置 128 MB 的块大小和 3 个复制元素。我们配置 Hadoop的每个节点运行 32 位的容器，（即，一个每个 CPU 核心）。为了更好地控制工作的并行度，我们启用 CGroups YARN同时启用 CPU 调度 。每个任务的默认 JVM 堆大小设置为 3 GB。我们调整以下参数以优化性能：（1）我们使用快速压缩来处理map输出；（2）对于所有工作负载除了排序，我们通过重叠的计算和减少网络传输的网络开销来实现地图之间重叠的减少。但是它仅仅当地图的并行计算的减少和网络呢开销不再是工作量（除了排序）的瓶颈时才成立。（3）（4）我们将每个任务的并行复印机数目设置为 2 来减少上下文切换开销 [16]；（5）我们将地图输出缓冲区设置为 550 MB，以避免 map排序输出时出现额外溢漏；（6）对于排序，我们设置了减少输入的缓冲区为 75%的 JVM 堆大小，以减少磁盘开销引起的泄漏。

Spark: 我们使用Spark 1.3.0 版在 HDFS 2.4.0 在独立模式下运行。我们还使用 8 磁盘来存储Spaek的中间数据。对于每个节点，我们共运行8个分别配置了4个线程的workers（即，每个 CPU 核心的一个线程）。我们也测试了其他配置。我们发现，当我们使用 32 个线程运行 1 名 worker时，CPU 利用率大大减少。例如，在此配置下 CPU 利用率分别下降到 33%和 25%，字数和第一个迭代的 k-均值。这可能引起为多线程任务分配内存的同步开销。因此我们在这个实验中采用这一设置。我们将Spark的驱动和执行的JVM堆大小设置为16GB，此外，我们为Spark调整以下参数：（1）我们使用 Snappy 在洗牌过程中压缩设备中线的结果（2）对于输入为500G的排序，我们设置打乱读取任务的数量为2000，对其他工作，这个参数设置为120。

3.1.3 分析工具

在本节中，我们提出目前有能力执行所选运行的工作负载上Spark和 MapReduce 深入的分析可视化和分析工具的。

执行计划可视化：为了了解并行执行的情况，我们对 MapRe duce 和Spark采用可视化任务级别执行计划。首先，我们从 MapReduce 和Spark的作业历史记录中提取任务的执行时间。为了创建一个紧凑的视图，以显示任务之间的平行度，我们将任务分组到水平线上。

我们在集群上部署节，并坚持轮番周期的查询mysql数据库。最后，我们将系统资源利用率 （CPU、 内存、 磁盘和网络） 与使用时间线视图任务的执行计划相关联。图 1 即这种执行计划可视化的一个例子。在最初，我们提出了一个可视化的物理执行计划，其中每个任务被表示为一个水平线。这条线的长度是任务的成正比的实际执行时间。属于不同阶段的任务用不同的颜色表示。物理执行计划可以与 图1 提到的CPU、 内存、 网络和磁盘资源等可视化关联。在资源利用图中，x 轴在几秒钟内表达了经过的时间，并与水平轴的物理执行计划相关。此外，我们分解并减少 MapReduce的 任务，将其分三个阶段 ︰ 复制、 排序和减少。对于每一批的同时运行的任务 （即波），我们可以直接阅读到发生在这一波的相关资源处理。

此工具可以显示: （1） 并行任务 （即波），例如，图 1 (a)中标记的第一个波，(2) 标记重叠的阶段，例如，在图2 (b)中展示的地图之间的

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[28843]，资料为PDF文档或Word文档，PDF文档可免费转换为Word