我目前正在评估一个小型集群上的Spark 2.1.0（3个具有32个CPU和128 GB Ram的节点），并具有线性回归基准（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
2 回答
最佳的簇大小和配置根据数据和作业的性质而变化 . 在这种情况下，我认为你的直觉是正确的，因为在给定集群大小（核心和执行程序）的额外开销的情况下，在较小的数据集上完成工作似乎需要不成比例的时间 .
请注意，将数据量增加两个数量级，处理时间仅增加了5倍 . 您正在将数据增加到群集设置的最佳大小 .
Spark是处理大量数据的绝佳工具，但如果数据适合，则在单台机器上运行单个进程并不具有竞争力 . 但是，它可以比基于磁盘的其他分布式处理工具快得多，其中数据不适合单个机器 .
几年前我在谈话时，发言人给出了一个类比，Spark就像一辆骑自行车的机车： - 如果负载很轻，自行车会赢，加速更快，更灵活，但负载很重机车可能需要一段时间来加快速度，但最终会更快 . （我担心我会忘记发言人的名字，但这是在伦敦举行的Cassandra聚会，发言人来自能源部门的一家公司） .
我同意@ ImDarrenG的评估，一般也同意机车/自行车类比 .
有了这么少的数据，我强烈推荐
A）缓存整个数据集和
B）将数据集广播到每个节点（特别是如果你需要像300M行表那样加入小数据集）
另一件需要考虑的事情是文件数量（如果你还没有被缓存），因为如果你正在读取一个不可分割的文件，那么只有一个核心能够读取该文件 . 但是一旦你缓存了数据集（在适当的情况下合并或重新分区），性能将不再受磁盘/序列化行的约束 .