我目前正在一个小型集群(3 个节点，32 个 CPU 和 128 GB RAM)上评估 Spark 2.1.0，并进行线性回归 (Spark ML) 基准测试。我只测量了参数计算的时间(不包括启动、数据加载等)并识别出以下行为。对于 0.1 Mio – 3 Mio 的小数据集，测量时间并没有真正增加，保持在大约 40 秒。只有像 300 Mio 数据点这样的大型数据集，处理时间才会长达 200 秒。因此，集群似乎根本不可扩展到小型数据集。
我还将本地PC上的小数据集与仅使用10个worker和16GB RAM的集群进行了比较。群集的处理时间大 3 倍。那么这是否被认为是 SPARK 的正常行为，并且可以通过通信开销来解释，或者我做错了什么(或者线性回归并不真正具有代表性)？
该集群是一个独立的集群(没有 Yarn 或 Mesos)，基准测试由 90 个工作线程提交，每个工作线程具有 1 个核心和 4 GB RAM。
火花提交：./spark-submit --master spark://server:7077 --class Benchmark --部署模式客户端 --total-executor-cores 90 --executor-memory 4g --num-executors 90 .../Benchmark.jar pathToData
最佳群集大小和配置因数据和作业性质而异。在这种情况下，我认为您的直觉是正确的，由于给定集群大小(核心和执行器)的开销，这项工作似乎需要不成比例的时间才能在较小的数据集上完成。
请注意，将数据量增加两个数量级只会使处理时间增加 5 倍。您正在将数据增加到群集设置的最佳大小。
Spark 是处理大量数据的好工具，但如果数据适合，它就无法与在单台机器上运行单个进程竞争。但是，它可能比其他基于磁盘的分布式处理工具快得多，在这些工具中，数据不适合一台机器。
几年前我在一次演讲中，演讲者打了个比方，Spark 就像一辆机车在比赛自行车：- 如果负载轻，自行车会赢，加速更快，更灵活，但负载较重时，机车可能需要一段时间才能跟上速度， 但最终会更快。(恐怕我忘记了演讲者的名字，但那是在伦敦的卡桑德拉聚会上，演讲者来自能源领域的一家公司)。
我同意@ImDarrenG的评估，通常也同意机车/自行车的类比。
对于如此少量的数据，我强烈建议
A) 缓存整个数据集和
B)将数据集广播到每个节点(特别是如果您需要执行诸如300M行表连接到小数据集之类的操作)
要考虑的另一件事是文件的 #(如果您尚未缓存)，因为如果您正在读取单个不可拆分的文件，则只有 1 个内核能够读取该文件。但是，一旦缓存数据集(根据需要合并或重新分区)，性能将不再受磁盘/序列化行的约束。