我正在使用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数量的加速。
1条答案
按热度按时间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排序机制便宜。