我目前正在一个小型集群（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提交： ./ spark-submit --master spark：// server：7077 --class Benchmark --deploy-mode client --total-executor-cores 90 --executor-memory 4g --num-executors 90 .. ./Benchmark.jar pathToData
答案 0 :(得分：1)
最佳的群集大小和配置因数据和作业的性质而异。在这种情况下，我认为你的直觉是正确的，在较小的数据集上完成工作似乎需要不成比例的时间，因为在给定集群大小（核心和执行程序）的情况下会产生过多的开销。
请注意，将数据量增加两个数量级会使处理时间增加5倍。您正在将数据增加到群集设置的最佳大小。
Spark是处理大量数据的绝佳工具，但如果数据合适，它在单台机器上运行单个进程并不具有竞争力。但是，它可以比基于磁盘的其他分布式处理工具快得多，其中数据不适合单个机器。
几年前我正在接受演讲，演讲者给出了一个类比，Spark就像一个骑自行车的机车： - 如果负载很轻，自行车会赢，加速更快，更敏捷，但是机车可能需要一段时间才能加速，但最终它会更快。 （我担心我会忘记发言者的名字，但这是在伦敦举行的Cassandra聚会，发言人来自能源部门的公司）。
答案 1 :(得分：0)
我同意@ ImDarrenG的评估，一般也是机车/自行车类比。
如果有这么少的数据，我强烈推荐
A）缓存整个数据集和
B）将数据集广播到每个节点（特别是如果你需要像300M行表那样加入小数据集）
要考虑的另一件事是文件数量（如果你还没有被缓存），因为如果你正在读取一个不可分割的文件，只有一个核心能够读取该文件。但是一旦你缓存数据集（适当时合并或重新分区），性能将不再受磁盘/序列化行的限制。