排序性能 PK：Spark 完胜 MapReduce

作为Hadoop MapReduce后继者Apache Spark可以支撑数千节点规模的集群部署，尤其在内存数据处理上，Spark 比 MapReduce 更加高效，且支持 GB 或 TB 级别的数据。然而很多人都认为在磁盘数据计算上，MapReduce 比 Spark 更有优势。近日，大数据公司Databricks为了评估 Spark 在 PB 级磁盘数据计算的运行状况, 其技术团队使用 AWS 进行了一个 Daytona Gray 类别的排序基准测试。测试结果显示 Spark 打破了 MapReduce 保持的排序性能记录。这次测试是一个考量系统排序 100TB 数据（约万亿条记录）速度的行业基准测试。在此之前，这项基准测试的世界记录保持者是雅虎，他们使用 2100 节点的 MapReduce 集群在 72 分钟内完成了计算。而本次测试 Spark 只使用了 206 个 EC2 节点，就将排序用时缩短到了 23 分钟。也就是说在相同数据的排序上，Spark 只使用了 1/10 的计算资源就比 MapReduce 快了近 3 倍。

此外，在 Spark 官方没有 PB 数量级排序对比的情况下，Databricks 技术团队首次开展了 1PB 数据（十万亿条记录）的排序测试。这个测试使用了 190 个 EC2 节点耗时不到 4 个小时，同样远超雅虎之前使用 3800 台主机、耗时 16 个小时的记录，这也是在公用云环境中，首次完成的 PB 级排序测试。以上两个测试的具体结果如下表：

Spark 有以上的性能表现是因为 Databricks 与 Spark 社区为 Spark 在稳定性、扩展性、性能等方面的做了不断的改进，尤其是在超大规模工作负载下，他们投入了大量的精力来提升 Spark 的性能。从细节上看，与这个基准测试高度相关的工作主要有三个，首先，也是最关键的，在 Spark 1.1 中他们引入了一个全新的 Shuffle 实现，也就是基于排序的 Shuffle（SPARK­-2045）。其次，他们修订了 Spark 的网络模型，通过 JNI（SPARK­-2468）使用基于Netty的 Epoll 本地端口传输。同时，新的模型还拥有了独立的内存池，绕过了 JVM 的内存分配器，从而减少垃圾回收造成的影响。最后，他们创建了一个外部 Shuffle 服务（SPARK­-3796），它与 Spark 本身的执行器完全解耦，这个新的服务基于上文所述的网络模型。得益于以上三项改进措施， 在 map 阶段，Spark 集群的单节点能够支撑每秒 3GB 的 IO 吞吐量，在 reduce 阶段，单节点能够支撑每秒 1.1GB 的 IO 吞吐量。其他更多的技术细节包括TimSort 排序算法的实现、缓存位置的利用、Spark 的容错机制以及 AWS 方面的增强等。

感谢郭蕾对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。