spark:核心数量缩放中的性能数不一致

9o685dep  于 2021-05-29  发布在  Hadoop
关注(0)|答案(1)|浏览(435)

我正在使用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数量的加速。

yzuktlbb

yzuktlbb1#

理论局限性
我想你熟悉阿姆达尔定律,但这里有一个快速的提醒。理论加速比定义如下:

哪里:
是平行部分的加速比。
p是程序中可以并行化的部分。
在实践中,理论加速比总是受到不能并行化的部分的限制,即使p相对较高(0.95),理论限制也相当低:

(此文件根据creative commons attribution share Simpled 3.0 unported许可证进行许可。
署名:daniels220(英文维基百科)
实际上,这设定了你能以多快的速度到达的理论界限。你可以预计,p将相对较高的情况下尴尬的平行工作,但我不会梦想任何接近0.95或更高。这是因为
spark是一个高成本的抽象概念
spark设计用于数据中心规模的商用硬件。它的核心设计集中于使整个系统健壮,并且不受硬件故障的影响。当您处理数百个节点并执行长时间运行的作业时,这是一个很好的特性,但它的伸缩性不是很好。
spark并不专注于并行计算
在实践中,spark和类似系统主要关注两个问题:
通过在多个节点之间分配io操作来减少总体io延迟。
在不增加单位成本的情况下增加可用内存量。
这是大规模数据密集型系统的基本问题。
并行处理与其说是主要目标,不如说是特定解决方案的副作用。Spark首先分布,其次平行分布。主要的一点是保持处理时间不变,随着数据量的增加,通过缩小,而不是加快现有的计算。
使用现代协处理器和gpgpu,您可以在一台机器上实现比典型的spark集群高得多的并行性,但由于io和内存限制,它不一定对数据密集型作业有帮助。问题在于如何快速加载数据,而不是如何处理数据。
实际意义
spark不能替代单机上的多处理或多读取。
在一台机器上增加并行性不太可能带来任何改进,而且通常会由于组件的开销而降低性能。
在这种情况下:
假设类和jar是有意义的,而且它确实是一种排序,那么在一个分区上读取数据(单分区输入,单分区输出)和在内存中排序要比执行一个带有无序文件和数据交换的完整spark排序机制便宜。

相关问题