开源点云数据处理 开源_开源和公共云团队创造了100 TB的世界纪录

开源点云数据处理 开源

2014年10月，Databricks参加了“排序基准”，并创造了新的世界纪录，用于排序100 TB的数据或1万亿个100字节的记录。 该团队在207个EC2虚拟机上使用了Apache Spark ，并在23分钟内分类了100 TB的数据。

相比之下，由Hadoop MapReduce创下的上一个世界纪录在一个私有数据中心中使用了2100台机器，花费了72分钟。 该条目与建立高性能系统的UCSD研究团队联系在一起，我们共同创造了新的世界纪录。

此外，尽管没有正式的PB竞争，但我们进一步推动Apache Spark（Spark）在不到4小时的时间内对190台计算机上的1 PB数据（10万亿条记录）进行了排序。 这个PB时间优于以前报告的基于Hadoop MapReduce的结果（在3800台计算机上为16小时）。 据我们所知，这是第一次使用开源软件（Spark）和公共云基础架构（EC2）的组合创下100 TB类别的新记录，这是有史以来第一个PB级的类别公共云。

基准工作负载以Jim Gray的名字命名，无论如何它都是资源密集型的：按照严格的规则对100 TB的数据进行排序会生成500 TB的磁盘I / O和200 TB的网络I / O。 来自世界各地的组织通常会构建专用的分类机（专用软件，有时还包括专用硬件）来竞争该基准。

	Hadoop MR 记录	火花 记录	火花 1 PB
Data Size	102.5 TB	100 TB	1000 TB
Elapsed Time	72分钟	23分钟	234分钟
# Nodes	2100	206	190
# Cores	50400实体	6592已虚拟化	6080虚拟化
Cluster disk throughput	3150 GB /秒 （美东时间。）	618 GB /秒	570 GB /秒
Sort Benchmark Daytona Rules	是	是	没有
Network	专用数据中心，10Gbps	虚拟化（EC2）10Gbps网络	虚拟化（EC2）10Gbps网络
Sort rate	1.42 TB /分钟	4.27 TB /分钟	4.27 TB /分钟
Sort rate/node	0.67 GB /分钟	20.7 GB /分钟	22.5 GB /分钟

什么是星火？

被广泛认为是Hadoop MapReduce的后继者， Apache Spark是用于大规模数据处理的快速通用引擎。 它提供Java，Python，Scala和SQL的编程API，可用于有效执行各种工作负载，包括常见的ETL，数据流，机器学习，图形计算和SQL。

Spark是最积极开发的开源项目之一。 2014年，它的贡献者超过465个，使其成为Apache软件基金会和大数据开源项目中最活跃的项目。

排序

排序基准（Benchmark）最初是由Jim Gray提出和赞助的，目的是衡量计算机系统的最新发展。 吉姆·格雷（Jim Gray）在2007年去世后，基准测试现在由过去的赢家组成的财团管理。 基准测试包含多个类别，每个类别都有不同的重点。 Daytona Gray（以Gray博士的名字命名）是最具挑战性的类别，因为它要求参与的系统在可能的最快时间内对100 TB的数据进行排序，而与所使用的计算资源无关。

排序的核心是洗牌操作，该操作可在所有计算机之间移动数据。 随机播放支持几乎所有分布式数据处理工作负载。 例如，连接两个不同数据源SQL查询使用重排将应连接在一起的元组移动到同一台计算机上，而诸如ALS之类的协作过滤算法则依靠重排在网络上发送用户/产品评分和权重。

大多数数据管道都从大量原始数据开始，但是随着管道的进行，由于过滤掉了无关数据或更中间数据的更紧凑表示，数据量减少了。 对100 TB原始输入数据SQL查询很可能只会在整个网络上100 TB的一小部分洗牌。 这种模式还反映在流行的数据处理框架MapReduce的命名中。

但是，排序是最具挑战性的任务之一，因为不会减少流水线中的数据。 对100 TB的输入数据进行分类需要在整个网络上对100 TB的数据进行混洗。 实际上，Daytona Gray竞赛要求我们复制输入和输出数据以实现容错能力，因此对100 TB的数据进行分类可以有效地产生500 TB的磁盘I / O和200 TB的网络I / O。

出于上述原因，当我们寻找度量指标来改进和改进Spark时，最苛刻的工作负载之一便是进行分类成为理所当然的选择。

是什么使它成为可能？

针对超大规模工作负载，为改进Spark进行了大量开发工作。 特别是，有三项主要工作与该基准高度相关。

首先，在Spark 1.1中，我们引入了一个新的shuffle实现，称为基于排序的shuffle（SPARK-2045）。 以前的Spark shuffle实施是基于哈希的，需要在内存中维护P（缩减分区的数量）并发缓冲区。 在基于排序的混洗中，在任何给定的点上都只需要一个缓冲区。 这大大减少了洗牌期间的内存开销，并且可以在单个阶段支持成千上万个任务的工作负载（我们的PB使用250,000个任务）。

其次，我们基于Netty通过JNI（SPARK-2468）的Epoll本机套接字传输，修改了Spark中的网络模块。 新模块还维护自己的内存池，从而绕过JVM的内存分配器，从而减少了垃圾回收的影响。

最后但并非最不重要的一点是，我们创建了一个新的外部随机播放服务（SPARK-3796），该服务与Spark执行程序本身分离。 这项新服务建立在上述网络模块上，并确保即使执行程序处于GC暂停状态，Spark仍可以提供随机播放文件。

通过这三个更改，我们的Spark集群能够在映射阶段维持3GB / s /节点的I / O活动，在缩减阶段维持1.1 GB / s /节点的网络活动，从而使这些机器上的10Gbps链路饱和。

坚韧不拔

TimSort：在Spark 1.1中，我们将默认排序算法从quicksort切换为TimSort，这是合并排序和插入排序的派生。 在大多数实际数据集中，它的性能要比快速排序好，尤其是对于部分排序的数据集。 我们在地图阶段和缩减阶段都使用TimSort。

利用缓存局部性：在排序基准中，每个记录为100字节，其中排序键为前10个字节。 在分析排序程序时，我们注意到缓存未命中率很高，因为每个比较都需要随机查找对象指针。 我们重新设计了记录的内存布局，以将每个记录表示为一个16字节的记录（JVM中为两个long），其中前10个字节代表排序键，​​后4个字节代表记录的位置（实际上由于字节序和符号，因此比这稍微复杂一些）。 这样，每个比较只需要一个大多数是顺序的高速缓存查找，而不是随机的内存查找。 最初由Chris Nyberg等提出。 在AlphaSort中，这是高性能系统中常用的技术。

Spark出色的编程抽象和体系结构使我们能够在几行代码中在用户空间中实现这些改进（无需修改Spark）。 将TimSort与我们的新布局相结合以利用缓存局部性，用于排序的CPU时间减少了5倍。

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

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

阿帕奇
鹅毛笔

本文是由Jason Hibbets协调的Apache Quill专栏的一部分。 通过open@opensource.com与我们联系，在Apache Software Foundation的项目内分享您的成功案例和开源更新 。

翻译自: https://opensource.com/business/15/1/apache-spark-new-world-record

开源点云数据处理 开源