Spark:扩展核心数量时的性能数量不一致

Question

我正在使用排序基准测试对Spark进行简单的扩展测试 - 从1核,最多8核.我注意到8个核心比1核心慢.

//run spark using 1 core
spark-submit --master local[1] --class john.sort sort.jar data_800MB.txt data_800MB_output

//run spark using 8 cores
spark-submit --master local[8] --class john.sort sort.jar data_800MB.txt data_800MB_output  

每种情况下的输入和输出目录都是HDFS.

1核:80秒

8个核心:160秒

我希望8核性能有x倍的加速.

Answer 1

理论限制

我假设你熟悉阿姆达尔定律但这里有一个快速提醒.理论加速定义如下:

其中:

• s - 是并行部分的加速.
• p - 是可以并行化的程序的一部分.

在实践中,理论加速总是受到无法并行化的部分的限制,即使p相对较高(0.95),理论极限也非常低:

(此文件采用知识共享署名-网上百科全书许可证授权.
署名:Daniels220在英文维基百科)

实际上,这可以设定理论上的限制.在令人尴尬的并行工作的情况下,你可以预期p会相对较高,但我不会想到接近0.95或更高的任何东西.这是因为

Spark是一种高成本的抽象

Spark旨在以数据中心规模在商用硬件上运行.它的核心设计专注于使整个系统健壮并且不受硬件故障的影响.当您使用数百个节点并执行长时间运行的作业时,这是一个很好的功能,但它不能很好地缩小.

Spark并不专注于并行计算

在实践中,Spark和类似系统专注于两个问题:

• 通过在多个节点之间分配IO操作来减少总体IO延迟.
• 增加可用内存量而不增加每单位成本.

这是大规模数据密集型系统的基本问题.

与主要目标相比,并行处理更具有特定解决方案的副作用.Spark首先分布,并行第二.重点是通过向外扩展来保持处理时间随着数据量的增加而不变,而不是加速现有的计算.

使用现代协处理器和GPGPU,您可以在一台机器上实现比典型Spark集群更高的并行性,但由于IO和内存限制,它不一定有助于数据密集型作业.问题是如何快速加载数据而不是如何处理它.

实际影响

• Spark不能替代单个机器上的多处理或多线程.
• 在单个机器上增加并行性不太可能带来任何改进,并且通常会由于组件的开销而降低性能.

在这方面:

假设类和jar是有意义的并且它确实是一种类型,它只是更便宜的读取数据(单个分区,单个分区)和单个分区内存排序比使用随机文件和数据执行整个Spark排序机制交换.