2014年11月5日更新：我们的基准条目已经过基准委员会的评审，Apache Spark赢得了2014年Daytona GraySort竞赛！请看这篇新的博文更新。apachespark得到了广泛的应用，被广泛认为是hadoopmapreduce的继承者，并且被部署在从少数到数千个节点的集群中。虽然大家都很清楚Spark比MapReduce更有效地处理内存中的数据，但我们听说有些组织在将其推送到无法放入内存的大规模数据集时遇到了困难。因此，自从Databricks诞生以来，我们与Spark社区一起投入了大量的精力来提高Spark的稳定性、可伸缩性和性能。Spark可以很好地处理千兆字节或兆兆字节的数据，它也可以很好地处理千兆字节。为了评估这些改进，我们决定参与Sort基准测试。在Amazon Web Services的帮助下，我们参加了Daytona Gray category，这是一个行业基准，用于衡量一个系统对100 TB数据（1万亿条记录）进行排序的速度。虽然我们的参赛作品仍在审核中，但我们很乐意与您分享我们的参赛作品。此前的世界纪录是72分钟，由雅虎使用一个由2100个节点组成的hadoopmapreduce集群创造。在206个EC2节点上使用Spark，我们在23分钟内完成了基准测试。这意味着Spark用更少的机器将相同的数据排序速度提高了3倍。所有的排序都在磁盘（HDFS）上进行，而没有使用Spark的内存缓存。此外，虽然没有官方的PB排序竞争，但我们进一步推动Spark在不到4小时的时间内，在190台机器上对1PB的数据（10万亿条记录）进行排序。这个PB时间超过了之前报告的基于2009年HadoopMapReduce的结果（3800台机器上16小时）。据我们所知，这是第一次在公共云中进行PB级排序。Hadoop公司世界纪录火花100 TB*火花1 PB数据大小102.5 TB100 TB1000 TB运行时间72分钟23分钟234分钟#节点2100206190#核心5040065926080#减速器10000个29000个25万费率1.42 TB/分钟4.27 TB/分钟4.27 TB/分钟速率/节点0.67 GB/分钟20.7 GB/分钟22.5 GB/分钟排序基准Daytona规则是的是的不环境专用数据中心EC2（i2.8X大）EC2（i2.8X大）不是官方的分类基准记录 为什么要分类？排序的核心是shuffle操作，它在所有机器上移动数据。Shuffle支持几乎所有分布式数据处理工作负载。例如，连接两个不同数据源的SQL查询使用shuffle将应该连接在一起的元组移动到同一台机器上，而诸如ALS之类的协作过滤算法则依赖shuffle在网络上发送用户/产品评级和权重。大多数数据管道从大量的原始数据开始，但是随着管道的发展，由于过滤掉不相关的数据或中间数据的更紧凑的表示，数据量会减少。对100TB的原始输入数据的SQL查询很可能只会在整个网络中洗牌100TB的一小部分。这种模式也反映在MapReduce本身的命名中。然而，排序是最具挑战性的工作之一，因为在管道中没有数据的缩减。对100TB的输入数据进行排序需要在整个网络中重新排列100TB的数据。事实上，Daytona的竞争要求我们复制输入和输出数据以实现容错，因此对100 TB的数据进行排序可以有效地生成500 TB的磁盘I/O和200 TB的网络I/O。基于以上原因，当我们在寻找度量和改进Spark的度量标准时，排序（最苛刻的工作负载之一）自然成为我们关注的一个选择。 告诉我是什么技术工作使这成为可能为了提高Spark的工作负载，已经进行了大量的开发。特别是，有三项主要工作与此基准高度相关。首先，在apachespark1.1中，我们引入了一个新的shuffle实现，称为基于排序的shuffle（Spark-2045）。以前的Spark shuffle实现是基于散列的，需要在内存中维护P（reduce partitions的数量）并发缓冲区。在基于排序的洗牌中，在任何给定的点上只需要一个缓冲区。这在shuffle过程中大大减少了内存开销，并且可以在一个阶段支持数十万个任务的工作负载（我们的PB sort使用了250000个任务）。其次，我们在Netty的Epoll原生套接字传输（Spark-2468）的基础上对Spark中的网络模块进行了改进。新模块还维护自己的内存池，从而绕过JVM的内存分配器，减少垃圾回收的影响。最后，我们创建了一个新的外部shuffle服务（SPARK-3796），它与SPARK executor本身分离。这个新的服务建立在上述网络模块之上，并确保即使在执行器处于GC暂停状态时，Spark仍然可以为shuffle文件提供服务。通过这三个变化，我们的Spark集群能够在映射阶段维持3GB/s/节点的I/O活动，在reduce阶段维持1.1Gb/s/节点的网络活动，使这些机器上可用的10Gbps链路饱和。 你还没有告诉我其他的细节吗？TimSort：在apachespark1.1中，我们将默认的排序算法从quicksort切换到TimSort，TimSort是merge sort和insertion sort的派生。在大多数实际数据集中，它的性能优于快速排序，特别是对于部分排序的数据集。我们在map和reduce阶段都使用TimSort。利用缓存局部性：在sort基准测试中，每个记录是100个字节，其中排序键是前10个字节。在分析排序程序时，我们注意到缓存未命中率很高，因为每次比较都需要随机的对象指针查找。我们重新设计了内存中的记录布局，将每条记录表示为一个16字节的记录（JVM中有两个long），其中前10个字节表示排序键，最后4个字节表示记录的位置（实际上，由于endianness和signedness，它比这稍微复杂一些）。这样，每次比较只需要一个缓存查找，而不是随机内存查找，而大部分是顺序的。最初由Chris Nyberg等人提出。在AlphaSort中，这是高性能系统中常用的技术。Spark良好的编程抽象和体系结构允许我们在用户空间中（无需修改Spark）在几行代码中实现这些改进。结合TimSort和我们的新布局来利用缓存局部性，排序的CPU时间减少了5倍。规模上的容错：在规模上，很多东西都会崩溃。在这个实验的过程中，我们看到了节点由于网络连接问题而消失，Linux内核在循环中旋转，或者节点由于内存碎片整理而暂停。幸运的是，Spark是容错的，可以从这些故障中恢复。云的力量（AWS）：如前所述，我们利用了206个i2.8x大型实例来运行这个I/O密集型实验。这些实例通过ssd提供高I/O吞吐量。我们将这些实例放在VPC中的一个放置组中，以通过单根I/O虚拟化（SR-IOV）实现增强的网络连接。启用增强的网络将带来更高的性能（10Gbps）、更低的延迟和更低的抖动。我们要感谢所有参与AWS的人，他们帮助我们实现了这一目标，包括：AWS EC2服务团队、AWS EC2业务开发团队、AWS产品营销团队和AWS解决方案架构团队。没有他们，这个实验就不可能了。火花不只是记忆中的火花吗？这一直是人们对Spark最常见的误解之一，尤其是对新加入社区的人来说。Spark以其在内存中的性能而闻名，但从其诞生之初，Spark就被设计成一个在内存和磁盘上都能工作的通用执行引擎。当数据不适合内存时，几乎所有的Spark操作符都执行外部操作。更一般地说，Spark的操作符是MapReduce的严格超集。正如这个实验所证明的，Spark能够处理比集群中的聚合内存大很多倍的数据集。摘要Databricks在Spark社区的帮助下，为apachespark提供了许多改进，以提高其性能、稳定性和可伸缩性。这使得Databricks能够使用apachespark在23分钟内对206台机器上的100TB数据进行排序，这比之前在2100台机器上的hadoop100tb结果快3倍。类似地，Databricks在不到4小时的时间内在190台机器上对1PB的数据进行排序，这比之前在3800台机器上得到的Hadoop 1PB结果快了4倍多。在排序方面优于大型Hadoop MapReduce集群不仅验证了我们所做的工作，而且表明Spark正在履行其作为一个更快、更可扩展的引擎来处理各种大小的数据的承诺。我们希望Spark能够为我们所有的用户在时间和成本上都有同样显著的改进。免费试用Databricks。今天就开始吧