Spark 颠覆 MapReduce 保持的排序记录
Spark 颠覆 MapReduce 保持的排序记录
在过去几年,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 PB | |
Data 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) |
--------------------------------------分割线 --------------------------------------
Spark1.0.0部署指南
CentOS 6.2(64位)下安装Spark0.8.0详细记录
Spark简介及其在Ubuntu下的安装使用
安装Spark集群(在CentOS上)
Hadoop vs Spark性能对比
Spark安装与学习
Spark 并行计算模型
--------------------------------------分割线 --------------------------------------
为什么会选择排序?
排序的核心是shuffle操作,数据的传输会横跨集群中所有主机。Shuffle基本支持了所有的分布式数据处理负载。举个例子,在一个 连接了两个不同数据源的SQL查询中,会使用shuffle将需要连接数据的元组移动到同一台主机;同时,类似ALS等协同过滤算法同样需要依赖 shuffle在网络中发送用户或产品的评级(ratings)和权重(weights)。
大部分数据管道开始时都会有大量的原始数据,但是在管道处理过程中,随着越来越多不相干数据被过滤,或者中间数据被更简洁的表示,数据量必 然会减少。在100TB原始数据的查询上,网络上shuffle的数据可能只有100TB的一小部分,这种模式也体现在MapReduce的命名。
然而,排序却是非常有挑战的,因为数据管道中的数据量并不会减少。如果对100TB的原始数据进行排序,网络中shuffle的数据必然也 是100TB。同时,在Daytona类型的基准测试中,为了容错,不管是输入数据还是输出数据都需要做备份。实际上,在100TB的数据排序上,我们可 能会产生500TB的磁盘I/O及200TB的网络I/O。
因此,基于上述原因,当我们寻找Spark的测量标准和提升办法时,排序这个最苛刻的工作负载成为了对比的不二之选。
更多详情见请继续阅读下一页的精彩内容:
|
评论暂时关闭