增加Spark Worker与Cassandra节点后任务耗时上升的原因排查

针对你遇到的3节点Spark-Cassandra集群性能反而低于2节点的情况，结合配置和测试细节，核心原因大概率和Cassandra复制因子带来的读写开销、Spark任务本地性下降或资源竞争有关，以下是具体分析和排查步骤：

核心可能原因 #

1. Cassandra复制因子（RF=3）的读写开销 #

• 写入阶段：RF=3时，每个写入操作需要同步到3个节点（默认若用QUORUM一致性级别，需2个节点确认），相比RF=1的单点写入，多了跨节点网络交互和数据同步耗时，小型集群节点间的网络延迟会被放大。
• 读取阶段：若使用QUORUM级别，需要从2个节点拉取数据校验，而RF=1时仅需读取本地节点，额外的网络IO会显著增加读取延迟，拖慢Spark任务。

2. Spark任务本地性恶化 #

虽然每个节点同时部署Spark Worker和Cassandra，但RF=3时数据会分布在所有3个节点的token范围内，Spark任务调度可能无法匹配到数据所在的本地节点，导致大量任务以RACK_LOCAL或ANY级别运行（可从Spark UI的Stages Tab查看Locality Level统计），跨节点拉取数据的网络开销会大幅增加任务耗时。

3. 集群资源竞争加剧 #

3节点场景下，Cassandra因RF=3需要处理更多数据复制、后台压缩等任务，会和Spark Executor抢占CPU、内存和磁盘IO资源；而RF=1时Cassandra负载更低，Spark能获得更多资源，任务运行更顺畅。

4. Shuffle分区调整未命中核心问题 #

你调整spark.sql.shuffle.partitions从96到18，但该参数主要影响shuffle阶段并行度，而你的性能瓶颈大概率出现在Cassandra读写阶段，因此调整后无明显改善。合理的shuffle分区数应接近集群总CPU核心数（比如3节点×2 Executors×每个Executor核心数，假设为4，建议设为24-32），但这不是当前问题的核心。

排查与优化步骤 #

• 检查Cassandra一致性级别：确认Spark连接Cassandra的读写一致性级别，RF=3时建议使用LOCAL_QUORUM（读写），而非QUORUM或ALL；对比2节点场景使用的ONE级别，过高的一致性级别会带来额外开销。相关配置参数：

  spark.cassandra.read.consistency.level=LOCAL_QUORUM
  spark.cassandra.write.consistency.level=LOCAL_QUORUM
  

• 验证Spark任务本地性：在Spark UI的Stages页面查看每个阶段的Locality Level分布，如果PROCESS_LOCAL/NODE_LOCAL占比低于80%，说明本地性不足。可调整spark.locality.wait参数（比如从默认3s改为5s），给调度器更多时间等待本地任务分配；同时确保Cassandra的token范围和Spark Executor的节点分布匹配。
• 监控Cassandra性能：使用nodetool tpstats查看读写请求的排队和延迟，nodetool cfstats查看表的读写延迟，对比RF=1和RF=3场景下的指标差异，确认是否因跨节点同步导致延迟飙升。
• 检查节点资源使用：查看每个节点的CPU、内存、磁盘IO使用率，确认是否存在Cassandra占用过多内存导致Spark Executor内存不足，或磁盘IO饱和的情况。可调整Cassandra的堆内存大小，避免和Spark资源冲突。

内容的提问来源于stack exchange，提问作者ktzan