Spark 颠覆 MapReduce 保持的排序记录

共计 6066 个字符，预计需要花费 16 分钟才能阅读完成。

在过去几年，Apache Spark 的采用以惊人的速度增加着，通常被作为 MapReduce 后继，可以支撑数千节点规模的集群部署。在内存中数 据处理上，Apache Spark 比 MapReduce 更加高效已经得到广泛认识；但是当数据量远超内存容量时，我们也听到了一些机构在 Spark 使用 上的困扰。因此，我们与 Spark 社区一起，投入了大量的精力做 Spark 稳定性、扩展性、性能等方面的提升。既然 Spark 在 GB 或 TB 级别数据上运行 良好，那么它在 PB 级数据上也应当同样如此。

为了评估这些工作，最近我们与 AWS 一起完成了一个 Sort Benchmark（Daytona Gray 类别）测试，一个考量系统排序 100TB 数据（万亿条记录）速度的行业基准测试。在此之前，这项基准测试的世界记录保持者是雅虎，使用 2100 节点的 Hadoop MapReduce 集群在 72 分钟内完成计算。而根据测试结果得知，在使用了 206 个 EC2 节点的情况下，Spark 将排序用时缩短到了 23 分钟。这意味着在使用十分之一计 算资源的情况下，相同数据的排序上，Spark 比 MapReduce 快 3 倍！

此外，在没有官方 PB 排序对比的情况下，我们首次将 Spark 推到了 1PB 数据（十万亿条记录）的排序。这个测试的结果是，在使用 190 个节点的情 况下，工作负载在短短不到 4 小时内完成，同样远超雅虎之前使用 3800 台主机耗时 16 个小时的记录。同时，据我们所知，这也是公用云环境首次完成的 PB 级 排序测试。

————————————– 分割线 ————————————–

Spark1.0.0 部署指南 http://www.linuxidc.com/Linux/2014-07/104304.htm

CentOS 6.2(64 位) 下安装 Spark0.8.0 详细记录 http://www.linuxidc.com/Linux/2014-06/102583.htm

Spark 简介及其在 Ubuntu 下的安装使用 http://www.linuxidc.com/Linux/2013-08/88606.htm

安装 Spark 集群 (在 CentOS 上) http://www.linuxidc.com/Linux/2013-08/88599.htm

Hadoop vs Spark 性能对比 http://www.linuxidc.com/Linux/2013-08/88597.htm

Spark 安装与学习 http://www.linuxidc.com/Linux/2013-08/88596.htm

Spark 并行计算模型 http://www.linuxidc.com/Linux/2012-12/76490.htm

————————————– 分割线 ————————————–

为什么会选择排序？    

排序的核心是 shuffle 操作，数据的传输会横跨集群中所有主机。Shuffle 基本支持了所有的分布式数据处理负载。举个例子，在一个 连接了两个不同数据源的 SQL 查询中，会使用 shuffle 将需要连接数据的元组移动到同一台主机；同时，类似 ALS 等协同过滤算法同样需要依赖 shuffle 在网络中发送用户或产品的评级（ratings）和权重（weights）。

大部分数据管道开始时都会有大量的原始数据，但是在管道处理过程中，随着越来越多不相干数据被过滤，或者中间数据被更简洁的表示，数据量必 然会减少。在 100TB 原始数据的查询上，网络上 shuffle 的数据可能只有 100TB 的一小部分，这种模式也体现在 MapReduce 的命名。

然而，排序却是非常有挑战的，因为数据管道中的数据量并不会减少。如果对 100TB 的原始数据进行排序，网络中 shuffle 的数据必然也 是 100TB。同时，在 Daytona 类型的基准测试中，为了容错，不管是输入数据还是输出数据都需要做备份。实际上，在 100TB 的数据排序上，我们可 能会产生 500TB 的磁盘 I / O 及 200TB 的网络 I /O。

因此，基于上述原因，当我们寻找 Spark 的测量标准和提升办法时，排序这个最苛刻的工作负载成为了对比的不二之选。

更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2014-10/107909p2.htm

产生如此结果的技术实现    

在超大规模工作负载上，我们投入了大量的精力来提升 Spark。从细节上看，与这个基准测试高度相关的工作主要有 3 个：

首先及最关键的，在 Spark 1.1 中我们引入了一个全新的 shuffle 实现，也就是基于排序的 shuffle（SPARK­2045）。在此之前，Spark 做的是基于哈希的 shuffle 实现，它需要在内存中同时保持 P（reduce 的分割数 量）个缓冲区。而在基于排序的 shuffle 下，任何时候系统只使用一个缓冲区。这个操作将显著地减少内存开销，因此同一个场景下可以支撑数十万任务（我 们在 PB 排序中使用了 2.5 万个任务）。

其次，我们修订了 Spark 的网络模型，通过 JNI（SPARK­2468）使用基于 Netty 的 Epoll 本地端口传输。同时，新的模型还拥有了独立的内存池，绕过了 JVM 的内存分配器，从而减少垃圾回收造成的影响。

最后但同样重要的是，我们建立了一个外部 shuffle 服务（SPARK­3796），它与 Spark 本身的执行器完全解耦。这个新的服务基于上文所述的网络模型，同时，在 Spark 本身的执行器忙于 GC 处理时，它仍然可以保证 shuffle 文件处理的继续执行。

通过这三项改变，我们的 Spark 集群在 map 阶段单 节点可以支撑每秒 3GB 的 IO 吞吐，在 reduce 阶段单节点可以支撑 1.1GB，从而榨干这些机器间 10Gbps 的网络带宽。

更多的技术细节    

TimSort： 在 Spark 1.1 版本中，我们将默认排序算法从 quicksort 转换到 TimSort，它是合并排 序和嵌入排序的一个衍生。在大部分现实世界数据集中，TimSort 比 quicksort 更加高效，在部分排序数据中表现则更为优秀。不管在 map 阶段还 是 Reduce 阶段，我们都使用了 TimSort。

缓存位置的利用： 在排序基准测试中，每条记录的大小都是 100 字节，而被排序的键是前 10 个字节。在排序项目的性能分析阶 段，我们注意到缓存命中率不如人意，因为每次比较都需要进行一个随机的对象指针查询。为此，我们重新设计了记录在内存的布局，用 16 字节长度（两个长整 形）的记录来表示每条记录。在这里，前 10 个字节代表了排序的键，后 4 个字节则代表了记录的位置（鉴于字节顺序和符号，这点并不容易发现）。这样一来，每 个比较只需要做一次缓存查询，而且它们都是连续的，从而避免了随机的内存查询。

使用 TimSort 和新的布局方式来利用缓存命中，排序所占用的 CPU 时间足足减少了 5 倍。

大规模下的容错机制： 在大规模下，许多问题都会暴露。在这个测试过程中，我们看到因为网络连通问题出现的节点丢失，Linux 内核自旋，以及因为内存碎片整理造成的节点停滞。幸运的是，Spark 的容错机制非常好，并且顺利的进行故障恢复。

AWS 的能量： 如上文所述，我们使用了 206 个 i2.8xlarge 实例来跑这个 I / O 密集测试。通过 SSD，这些实例交付了非常高的 I / O 吞吐量。我们将这些实例放到一个 VPC 放置组中，从而通过单 SR-IOV 增强网络性能，以获得高性能（10Gbps）、低延时和低抖动。
   

Spark 只能在内存中大放异彩？    

这个误解一直围绕着 Spark，特别是刚进入社区中的新人更是如此认为。不错，Spark 因为内存计算的高性能闻名，然而 Spark 的设计 初衷和理念却是一个通用的大数据处理平台——不管是使用内存还是磁盘。在数据无法完全放入内存时，基本上所有的 Spark 运算符都会做一些额外的处理。通 俗来说，Spark 运算符是 MapReduce 的超集。

如本次测试所示，Spark 可以胜任集群内存大小 N 倍的数据集处理。

总结    

击败 Hadoop MapReduce 集群创造的大规模数据处理记录不仅是对我们工作的一个证明，也是对 Spark 承诺的一个验证——在任何数据体积，Spark 在性能和扩展性上都更具优势。同时，我们也希望在用户使用过程中，Spark 可以带来时间和开销上的双节省。

博文链接：Spark Breaks Previous Large-Scale Sort Record（CSDN 翻译 / 童阳 责编 / 仲浩）

Spark 的详细介绍 ：请点这里
Spark 的下载地址 ：请点这里

在过去几年，Apache Spark 的采用以惊人的速度增加着，通常被作为 MapReduce 后继，可以支撑数千节点规模的集群部署。在内存中数 据处理上，Apache Spark 比 MapReduce 更加高效已经得到广泛认识；但是当数据量远超内存容量时，我们也听到了一些机构在 Spark 使用 上的困扰。因此，我们与 Spark 社区一起，投入了大量的精力做 Spark 稳定性、扩展性、性能等方面的提升。既然 Spark 在 GB 或 TB 级别数据上运行 良好，那么它在 PB 级数据上也应当同样如此。

为了评估这些工作，最近我们与 AWS 一起完成了一个 Sort Benchmark（Daytona Gray 类别）测试，一个考量系统排序 100TB 数据（万亿条记录）速度的行业基准测试。在此之前，这项基准测试的世界记录保持者是雅虎，使用 2100 节点的 Hadoop MapReduce 集群在 72 分钟内完成计算。而根据测试结果得知，在使用了 206 个 EC2 节点的情况下，Spark 将排序用时缩短到了 23 分钟。这意味着在使用十分之一计 算资源的情况下，相同数据的排序上，Spark 比 MapReduce 快 3 倍！

此外，在没有官方 PB 排序对比的情况下，我们首次将 Spark 推到了 1PB 数据（十万亿条记录）的排序。这个测试的结果是，在使用 190 个节点的情 况下，工作负载在短短不到 4 小时内完成，同样远超雅虎之前使用 3800 台主机耗时 16 个小时的记录。同时，据我们所知，这也是公用云环境首次完成的 PB 级 排序测试。

————————————– 分割线 ————————————–

Spark1.0.0 部署指南 http://www.linuxidc.com/Linux/2014-07/104304.htm

CentOS 6.2(64 位) 下安装 Spark0.8.0 详细记录 http://www.linuxidc.com/Linux/2014-06/102583.htm

Spark 简介及其在 Ubuntu 下的安装使用 http://www.linuxidc.com/Linux/2013-08/88606.htm

安装 Spark 集群 (在 CentOS 上) http://www.linuxidc.com/Linux/2013-08/88599.htm

Hadoop vs Spark 性能对比 http://www.linuxidc.com/Linux/2013-08/88597.htm

Spark 安装与学习 http://www.linuxidc.com/Linux/2013-08/88596.htm

Spark 并行计算模型 http://www.linuxidc.com/Linux/2012-12/76490.htm

————————————– 分割线 ————————————–

为什么会选择排序？    

排序的核心是 shuffle 操作，数据的传输会横跨集群中所有主机。Shuffle 基本支持了所有的分布式数据处理负载。举个例子，在一个 连接了两个不同数据源的 SQL 查询中，会使用 shuffle 将需要连接数据的元组移动到同一台主机；同时，类似 ALS 等协同过滤算法同样需要依赖 shuffle 在网络中发送用户或产品的评级（ratings）和权重（weights）。

大部分数据管道开始时都会有大量的原始数据，但是在管道处理过程中，随着越来越多不相干数据被过滤，或者中间数据被更简洁的表示，数据量必 然会减少。在 100TB 原始数据的查询上，网络上 shuffle 的数据可能只有 100TB 的一小部分，这种模式也体现在 MapReduce 的命名。

然而，排序却是非常有挑战的，因为数据管道中的数据量并不会减少。如果对 100TB 的原始数据进行排序，网络中 shuffle 的数据必然也 是 100TB。同时，在 Daytona 类型的基准测试中，为了容错，不管是输入数据还是输出数据都需要做备份。实际上，在 100TB 的数据排序上，我们可 能会产生 500TB 的磁盘 I / O 及 200TB 的网络 I /O。

因此，基于上述原因，当我们寻找 Spark 的测量标准和提升办法时，排序这个最苛刻的工作负载成为了对比的不二之选。

更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2014-10/107909p2.htm