Performance Spark:在缩放核心数时性能数不一致

我正在使用sort基准对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），理论极限也相当低：

（此文件根据Creative Commons Attribution Share Alike 3.0 Unported许可证进行许可。
署名：at）

这有效地设定了你能以多快的速度到达的理论界限。你们可以预计，在这种情况下，p将相对较高，但我不会梦想任何接近0.95或更高的值。这是因为

Spark是一种高成本的抽象产品

Spark设计用于数据中心规模的商用硬件。它的核心设计集中于使整个系统健壮并对硬件故障免疫。当您处理数百个节点时，这是一个很好的特性 并执行长时间运行的作业，但它的伸缩性不是很好

Spark不专注于并行计算

实际上，Spark和类似系统关注两个问题：

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

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

并行处理与其说是主要目标，不如说是特定解决方案的副作用。火花首先分布，然后平行分布。主要的一点是通过向外扩展，而不是加速现有的计算，使处理时间随着数据量的增加而保持不变

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

实际意义

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

在这种情况下：

---

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

提供有关CPU的信息，其他步骤的基准源和结果您是否看到了spark UI中使用的所有内核？我将添加以下信息：由于spark会尝试分割文件，因此我们会出现以下情况之一：spark会启动多个线程来读取同一文件，同时会招致I/O惩罚，通过搜索整个输入文件，而不是线性地读取它。或者，Spark仍会一口气读取文件，然后将其分散到同时进行的作业中，并导致本地洗牌，这也会降低性能。再加上排序所需的洗牌，性能明显下降。