在过去几年，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级 排序测试。
Hadoop World Record Spark 100 TB Spark 1 PBData Size 102.5 TB 100 TB 1000 TB
Elapsed Time 72 mins 23 mins 234 mins
# Nodes 2100 206 190
# Cores 50400 6592 6080
# Reducers 10,000 29,000 250,000
1.42 TB/min 4.27 TB/min 4.27 TB/min
Rate/node 0.67 GB/min 20.7 GB/min 22.5 GB/min
Sort Benchmark Daytona Rules Yes Yes No
Environment dedicated data center EC2 (i2.8xlarge) EC2 (i2.8xlarge)
--------------------------------------分割线 --------------------------------------
CentOS 6.2(64位)下安装Spark0.8.0详细记录
Spark简介及其在Ubuntu下的安装使用
--------------------------------------分割线 --------------------------------------
为什么会选择排序？
排序的核心是shuffle操作，数据的传输会横跨集群中所有主机。Shuffle基本支持了所有的分布式数据处理负载。举个例子，在一个 连接了两个不同数据源的SQL查询中，会使用shuffle将需要连接数据的元组移动到同一台主机；同时，类似ALS等协同过滤算法同样需要依赖 shuffle在网络中发送用户或产品的评级（ratings）和权重（weights）。
大部分数据管道开始时都会有大量的原始数据，但是在管道处理过程中，随着越来越多不相干数据被过滤，或者中间数据被更简洁的表示，数据量必 然会减少。在100TB原始数据的查询上，网络上shuffle的数据可能只有100TB的一小部分，这种模式也体现在MapReduce的命名。
然而，排序却是非常有挑战的，因为数据管道中的数据量并不会减少。如果对100TB的原始数据进行排序，网络中shuffle的数据必然也 是100TB。同时，在Daytona类型的基准测试中，为了容错，不管是输入数据还是输出数据都需要做备份。实际上，在100TB的数据排序上，我们可 能会产生500TB的磁盘I/O及200TB的网络I/O。
因此，基于上述原因，当我们寻找Spark的测量标准和提升办法时，排序这个最苛刻的工作负载成为了对比的不二之选。