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

理论限制

我假设您熟悉Amdahl's law，但这里有一个快速提醒。理论加速定义如下：

在哪里：

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

在实践中，理论加速总是受到无法并行化的部分的限制，即使 p 相对较高（0.95），理论限制也很低：

(此文件已获得知识共享署名-相同方式共享 3.0 未移植许可。
署名：Daniels220English Wikipedia)

实际上，这设定了您可以获得多快的理论界限。您可以预期 p 在embarrassingly parallel jobs 的情况下会相对较高，但我不会梦想接近 0.95 或更高。这是因为

Spark 是一种高成本抽象

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

Spark 不专注于并行计算

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

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

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

并行处理更多是特定解决方案的副作用，而不是主要目标。 Spark首先是分布式的，其次是并行的。要点是通过横向扩展来保持处理时间不变，而不是加速现有计算。

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

实际意义

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

在这种情况下：

假设类和 jar 是有意义的，并且它确实是一种排序，那么读取数据（单个分区输入，单个分区输出）和在单个分区上的内存中排序比使用 shuffle 执行整个 Spark 排序机制更便宜文件和数据交换。