我有一个包含1B记录的大型数据集，并希望使用Apache spark运行分析，因为它提供了扩展，但我在这里看到了反模式 . 我添加到spark集群的节点越多，完成时间就越长 . 数据存储是Cassandra，查询由Zeppelin运行 . 我尝试了很多不同的查询，但即使是 dataframe.count() 的简单查询也是这样的 .
这是zeppelin笔记本，临时表有18M记录
val df = sqlContext
.read
.format("org.apache.spark.sql.cassandra")
.options(Map( "table" -> "temp", "keyspace" -> "mykeyspace"))
.load().cache()
df.registerTempTable("table")
%sql
SELECT first(devid),date,count(1) FROM table group by date,rtu order by date
当针对不同的没有测试时 . 这些是火花 Worker 节点的结果
+-------------+---------------+
| Spark Nodes | Time |
+-------------+---------------+
| 1 node | 17 min 59 sec |
| 2 nodes | 12 min 51 sec |
| 3 nodes | 15 min 49 sec |
| 4 nodes | 22 min 58 sec |
+-------------+---------------+
增加号码 . 节点会降低性能 . 这不应该发生，因为它违背了使用Spark的目的 .
如果您希望我运行任何查询或有关设置的更多信息，请询问 . 关于为什么会发生这种情况的任何暗示都会非常有帮助，现在已经坚持了两天 . 感谢您的时间 .
versions
Zeppelin：0.7.1，Spark：2.1.0，Cassandra：2.2.9，连接器：datastax：spark-cassandra-connector：2.0.1-s_2.11
Spark cluster specs
6个vCPU，32 GB内存= 1个节点
Cassandra + Zeppelin server specs
8个vCPU，52 GB内存
1 回答
需要考虑的一件事是，在某个时刻，您可能会对请求压倒Cassandra集群 . 如果C *最终花费太多时间拒绝请求，那么在没有缩放Cassandra方程式的情况下，您可以很容易地看到收益递减 .
这基本上是人月谬误 . 仅仅因为你可以在一个问题上投入更多的 Worker 并不一定意味着可以更快地完成项目 .
分别对查询的不同部分进行基准测试非常有用 . 目前正如您所设置的那样，整个数据集是读取缓存，如果您对单个请求进行基准测试，则会增加额外的缓慢 .
你应该孤立地进行基准测试
从C *读取而不进行缓存（只需直接从C *算起）
缓存成本（缓存后计数）
正在运行的shuffle查询的开销（来自缓存运行查询）
然后你可以找出你的瓶颈在哪里并适当缩放 .