我有一个包含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
对不同的号码进行测试时。火花工人节点这些是结果
+-------------+---------------+
| 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的目的。
如果您希望我运行任何查询或有关设置的更多信息,请询问。 关于为什么会发生这种情况的任何暗示都会非常有帮助,现在已经坚持了两天。谢谢你的时间。
版本
Zeppelin:0.7.1,Spark:2.1.0,Cassandra:2.2.9,连接器:datastax:spark-cassandra-connector:2.0.1-s_2.11
Spark群集规范
6个vCPU,32 GB内存= 1个节点
Cassandra + Zeppelin服务器规格
8个vCPU,52 GB内存
答案 0 :(得分:1)
要考虑的一件事是,在某个时刻,您可能会对请求压倒Cassandra集群。如果C *最终花费太多时间拒绝请求,那么在没有扩展Cassandra方面的情况下你很容易看到收益递减。
这基本上是人月谬误。仅仅因为你可以让更多的工人解决问题并不一定意味着项目可以更快完成。
分别对查询的不同部分进行基准测试非常有用。目前正如您所设置的那样,整个数据集是读取缓存,如果您对单个请求进行基准测试,则会增加额外的缓慢。
你应该孤立地进行基准测试
然后你可以弄清楚你的瓶颈在哪里并适当缩放。