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



apache-spark hadoop (1)

我正在使用排序基准测试对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倍的加速。


理论限制

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

其中:

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

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

此文件根据知识共享署名 - 相同方式共享3.0 Unported许可进行许可。
署名: 英语维基百科的 Daniels220

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

Spark是一种高成本的抽象

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

Spark并不专注于并行计算

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

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

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

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

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

实际影响

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

在这方面

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





benchmarking