火花:磁芯缩放数中不一致的性能数

Question

我正在做一个简单的测试星火使用排序基准-从一个核心，最多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-是并行部分的加速比。
• P-是可以并行化的程序的一部分。

在实践中，理论加速比总是受到不能并行化的部分的限制，即使p相对较高(0.95)，理论极限也是相当低的：

​

(此文件是在3.0未移植许可下获得许可的。

归因：https://en.wikipedia.org/wiki/User:Daniels220 at https://en.wikipedia.org/wiki/)

实际上，这设置了理论上的界限，你能得到多快。您可以预期p会相对较高，以防令人尴尬的平行工作，但我不会梦想任何接近0.95或更高的东西。这是因为

火花是一种高成本的抽象

Spark是设计用于在数据中心规模上生产商品硬件的。它的核心设计重点是使整个系统的鲁棒性和对硬件故障的免疫力。当您与数百个节点一起工作并执行长时间运行的作业时，它是一个很好的特性，但是它并不能很好地缩小。

火花并不专注于并行计算

在实践中，星火和类似系统的重点是两个问题：

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

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

并行处理更多地是特定解决方案的副作用，而不是主要目标。火花首先分布，其次是平行分布。重点是通过扩展来保持处理时间不变，以增加数据量，而不是加速现有的计算。

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

实用含义

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

在此上下文中

假设类和jar是有意义的，而且它确实是一种排序，那么在单个分区上读取数据(单个分区，单个分区)和在内存中排序比使用混洗文件和数据交换执行整个星火排序机制要便宜。