Apache Spark是对pb进行排序的最快的开bob下载地址源引擎

2014年11月5日更新:我们的基准测试条目已经被基准测试委员会审查过了，Apache Spark赢得了代托纳灰色排序大赛2014年!请看这个新的博客文章更新．

Apache Spark已经被广泛采用，被广泛认为是Hadoop的继任者MapReduce，并部署在从少数到数千个节点的集群中。虽然每个人都清楚Spark在内存数据方面比MapReduce更有效，但我们听说一些组织在将其推广到无法容纳内存的大规模数据集时遇到了麻烦。因此，自Databricks成立以来，我们与Spark社区一起投入了大量的精力来提高Spark的稳定性、可伸缩性和性能。Spark可以很好地处理千兆字节或千兆字节的数据，也应该可以很好地处理千兆字节的数据。

为了评估这些改进，我们决定参加排序基准．在亚马逊网络服务的帮助下，我们参加了Daytona Gray类别，这是一个行业基准，衡量一个系统对100tb数据(1万亿条记录)排序的速度。虽然我们的作品仍在审查中，但我们渴望与您分享我们的作品。之前的世界纪录是72分钟，由雅虎使用2100个节点的Hadoop MapReduce集群创造。在206个EC2节点上使用Spark，我们在23分钟内完成了基准测试。这意味着Spark对相同的数据进行排序快3倍使用少了10倍的机器．所有排序都发生在磁盘上(HDFS)，而不使用Spark的内存缓存。

此外，虽然没有官方的PB排序竞争，但我们进一步推动Spark在4小时内对190台机器上的1pb数据(10万亿条记录)进行排序。这个PB时间超过了之前在2009年基于Hadoop MapReduce的报告结果(3800台机器上的16小时)。据我们所知，这是在公共云中进行的第一次pb级排序。

	Hadoop 世界纪录	火花 100tb *	火花 1 PB
数据大小	102.5结核病	100年结核病	1000年结核病
运行时间	72分钟	23分钟	234分钟
#节点	2100	206	190
#核	50400	6592	6080
#还原剂	10000年	29000年	250000年
率	1.42 TB /分钟	4.27 TB /分钟	4.27 TB /分钟
率/节点	0.67 GB /分钟	20.7 GB /分钟	22.5 GB /分钟
排序基准代托纳规则	是的	是的	没有
环境	专用数据中心	EC2 (i2.8xlarge)	EC2 (i2.8xlarge)

• 不是官方排序基准记录

为什么排序?

排序的核心是洗牌操作，它在所有机器之间移动数据。Shuffle是几乎所有分布式数据处理工作负载的基础。例如，连接两个不同数据源的SQL查询使用shuffle将应该连接在一起的元组移动到同一台机器上，并使用协作过滤算法，例如肌萎缩性侧索硬化症依赖shuffle通过网络发送用户/产品评级和权重。

大多数数据管道从大量原始数据开始，但随着管道的发展，由于过滤掉不相关的数据或更紧凑的中间数据表示，数据量会减少。对100tb原始输入数据的SQL查询很可能只会在网络中打乱100tb数据的一小部分。这种模式也反映在MapReduce本身的命名中。

然而，排序是最具挑战性的操作之一，因为沿管道的数据不会减少。对100tb的输入数据进行排序需要在网络上对100tb的数据进行变换。事实上，Daytona竞赛要求我们复制输入和输出数据以实现容错，因此对100tb数据进行排序有效地生成500tb磁盘I/O和200tb网络I/O。

由于上述原因，当我们在寻找衡量和改进Spark的指标时，排序(要求最高的工作负载之一)成为了我们关注的自然选择。

告诉我这一切背后的技术工作

针对大规模工作负载，已经进行了大量的开发以改进Spark。特别是，有三个主要的工作与这个基准测试高度相关。

首先，在Apache Spark 1.1中，我们引入了一个新的shuffle实现事洗牌（火星- 2045)．之前的Spark shuffle实现是基于哈希的，需要在内存中维护P (reduce分区的数量)并发缓冲区。在基于排序的shuffle中，在任何给定的点上只需要一个缓冲区。这大大降低了shuffle期间的内存开销，并且可以在一个阶段支持数十万个任务的工作负载(我们的PB排序使用了250,000个任务)。

第二，我们改进了网络模块基于Netty的Epoll本地套接字传输通过JNI (火星- 2468)．新模块还维护自己的内存池，从而绕过JVM的内存分配器，减少了垃圾收集的影响。

最后，我们创建了一个新的外部shuffle服务（火星- 3796)，与Spark执行器本身解耦。这个新服务建立在前面提到的网络模块之上，确保即使执行器处于GC暂停状态，Spark仍然可以提供shuffle文件。

通过这三个改变，我们的Spark集群能够在map阶段维持3GB/s/节点I/O活动，在reduce阶段维持1.1 GB/s/节点网络活动，使这些机器上可用的10Gbps链路饱和。

你还有什么细节没告诉我吗?

TimSort在Apache Spark 1.1中，我们将默认的排序算法从快速排序切换到快速排序TimSort，归并排序和插入排序的派生。在大多数真实世界的数据集中，特别是部分有序的数据集中，它的表现比快速排序要好。我们在map和reduce阶段都使用了TimSort。

利用缓存位置:在排序基准测试中，每条记录为100字节，其中排序键是前10个字节。在分析排序程序时，我们注意到缓存丢失率很高，因为每次比较都需要随机查找对象指针。我们重新设计了内存中的记录布局，将每个记录表示为一个16字节的记录(JVM中的两个长记录)，其中前10个字节表示排序键，最后4个字节表示记录的位置(实际上，由于字节顺序和符号性，它比这稍微复杂一些)。这样，每次比较只需要一个缓存查找，而不是一个随机的内存查找。最初由Chris Nyberg等人在AlphaSort中提出，这是一种在高性能系统中使用的常用技术。

Spark出色的编程抽象和架构允许我们在用户空间(无需修改Spark)中实现这些改进，只需几行代码。将TimSort与我们的新布局结合起来以利用缓存局部性，用于排序的CPU时间减少了1 / 5。

大规模容错在规模上，很多东西都可能破裂。在这个实验过程中，我们看到节点由于网络连接问题而消失，Linux内核在循环中旋转，或者节点由于内存碎片整理而暂停。幸运的是，Spark具有容错功能，可以从这些故障中恢复。

云的力量(AWS):如前所述，我们利用206个i2.8xlarge实例来运行这个I/O密集型实验。这些实例通过ssd提供高I/O吞吐量。我们将这些实例放在VPC中的放置组中，以通过单根I/O虚拟化(SR-IOV)增强网络。启用增强的网络将带来更高的性能(10Gbps)、更低的延迟和更低的抖动。我们要感谢AWS所有参与其中的人，包括AWS EC2服务团队、AWS EC2业务开发团队、AWS产品营销团队和AWS解决方案架构团队。没有他们，这个实验是不可能进行的。

Spark不是只在内存中吗?

这一直是对Spark最常见的误解之一，特别是对于刚进入社区的人来说。Spark以其在内存中的性能而闻名，但从一开始，Spark就被设计成一个通用的执行引擎，可以在内存中和磁盘上工作。几乎所有Spark操作符都在数据无法装入内存时执行外部操作。更一般地说，Spark的操作符是MapReduce的严格超集。

正如这个实验所证明的，Spark能够处理比集群中聚合内存大许多倍的数据集。

总结

Databricks在Spark社区的帮助下对Apache Spark做出了许多改进，以提高其性能、稳定性和可伸缩性。这使得Databricks可以使用Apache Spark在23分钟内对206台机器上的100TB数据进行排序，比之前在2100台机器上的100TB结果快3倍。类似地，Databricks在不到4小时的时间内对190台机器上的1PB数据进行排序，这比之前在3800台机器上的Hadoop 1PB结果快了4倍多。

在排序方面优于大型Hadoop MapReduce集群不仅验证了我们所做的工作，而且还表明Spark正在履行其作为各种规模数据处理的更快、更可扩展引擎的承诺。我们希望Spark能够在时间和成本上为所有用户带来同样显著的改善。