Spark作业运行时长大幅波动且耗时陡增，求排查方案

问题回顾 #

• 遗留Spark代码初始运行时长约5小时，近期仅做无性能影响的小幅改动，但近1个月运行时长攀升至20小时，且时段波动极大：早间4分钟、午间40分钟、晚间7分钟
• 原始版本虽有波动（4/8/12分钟），但幅度远小于改动后版本
• Spark UI显示某阶段存在显著长尾：75分位耗时约4秒，最大值达2-3分钟，且该问题与数据量无关（相同数据量下Executor耗时仅为改动后版本的一半）
• 当前Spark配置：[请补充具体配置参数]

核心排查方向与实操方案 #

1. 隐性数据倾斜排查 #

即使总数据量无变化，小幅改动也可能改变数据分布，触发长尾：

• 查看Spark UI的Stage页面，对比每个Task的输入数据量，确认是否存在个别Task处理数据量远超均值的情况
• 若存在热点Key，直接对热点Key做加盐打散：在Key后拼接1_{N的随机后缀，打散后完成聚合，再按原Key合并结果；同时调整`spark.sql.shuffle.partitions`（建议设为集群CPU核心数的2}3倍），优化Shuffle分区粒度
• 对比改动前后的SQL执行计划（用explain extended），确认Join/分组逻辑是否发生隐性变化，比如原本的Broadcast Join被改成了Shuffle Join

2. 集群资源竞争排查 #

午间耗时暴增大概率是集群资源被抢占：

• 拉取不同时段的集群监控数据，检查CPU、内存、磁盘IO的负载曲线，确认午间是否有其他大任务占用资源
• 查看Spark UI的Executor页面，统计GC时间占比：若GC占比超过20%，调整spark.executor.memoryOverhead（建议设为Executor内存的10%~20%），同时切换G1GC垃圾收集器，配置spark.executor.extraJavaOptions="-XX:+UseG1GC -XX:MaxGCPauseMillis=200"
• 排查集群节点状态：若个别节点磁盘IO延迟高、CPU使用率异常，将其加入Spark黑名单（配置spark.blacklist.enabled=true），避免Task分配到故障节点

3. 代码改动的隐性影响复盘 #

所谓“无性能影响的改动”可能存在隐藏开销：

• 检查过滤条件改动：若过滤后剩余数据的Key分布更集中，会直接加剧Shuffle阶段的长尾
• 检查UDF或自定义算子改动：若引入了不必要的序列化/反序列化（比如使用了不可序列化的对象），会大幅增加Task耗时；可改用Spark内置函数替代自定义UDF
• 检查是否新增了宽依赖操作：比如将原本的Map操作改成了需要Shuffle的ReduceByKey，额外增加了数据传输开销

4. 存储层优化 #

输入数据源的状态也会影响Task耗时：

• 若输入为HDFS小文件，执行repartition()合并小文件，减少Task读取时的IO开销
• 检查数据源存储节点的负载：午间若存储节点读写压力大，会导致数据读取延迟，可考虑将数据迁移到负载更低的存储节点

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