Spark作业运行缓慢 单表写入耗时大幅波动异常排查

问题复现 #

作业提交参数如下：

spark-submit --conf spark.sql.shuffle.partitions=100 --master yarn --deploy-mode cluster --conf spark.dynamicAllocation.enabled=true --conf spark.dynamicAllocation.minExecutors=2 --conf spark.dynamicAllocation.maxExecutors=30 --num-executors 5 --executor-cores 5 --executor-memory 17g --conf Spark.Dynamic.executors=true 

作业逻辑为增量写入14张表，正常全流程耗时5分钟，异常场景下会卡在单表写入环节，该环节耗时波动极大，从数秒到3小时不等。对比正常与异常作业DAG可见，异常时写入阶段存在极个别task长时间运行，其余task均快速完成的特征。

根因定位 #

• 资源配置存在冲突与无效项
  提交参数中存在拼写错误的无效配置Spark.Dynamic.executors=true（首字母大写、配置路径错误，不会被Spark识别生效）；同时开启动态资源分配又硬编码--num-executors 5，会导致作业初始启动时仅申请5个executor，动态扩容需要等待task积压触发，存在分钟级延迟，资源供给跟不上计算需求时就会卡顿。此外配置的spark.dynamicAllocation.minExecutors=2冗余度过低，作业空闲释放资源后剩余算力不足以支撑突发的数据计算需求。
• Shuffle分区配置僵化，无法适配增量数据波动
  固定设置spark.sql.shuffle.partitions=100，增量作业每日数据量不固定：当异常天该表增量数据量突增时，单分区承载数据量可达数GB，对应task会出现长时间GC、磁盘spill，运行时长飙升；当增量数据量极小时又会产生大量空task，增加调度开销。
• 存在偶发数据倾斜
  耗时波动极大（数秒到3小时）是数据倾斜的典型特征：当写入该表前的join、group by逻辑碰到热点key（比如null值集中、某类业务id当日数据量突增、脏数据key）时，超量数据会被分配到单个task上，其余task数秒跑完后需要等待该倾斜task数小时才能完成stage；如果当日增量数据无热点key，整个写入流程就会数秒完成。

优化方案 #

• 清理冲突配置，优化动态资源规则
  删除无效的Spark.Dynamic.executors=true配置，移除硬编码的--num-executors 5参数避免和动态分配逻辑冲突；调整动态分配参数：设置spark.dynamicAllocation.initialExecutors=10、spark.dynamicAllocation.minExecutors=5，保留maxExecutors=30的配置，同时添加spark.dynamicAllocation.schedulerBacklogTimeout=1s、spark.dynamicAllocation.sustainedSchedulerBacklogTimeout=3s，缩短task积压时的资源扩容触发延迟。额外配置spark.executor.memoryOverhead=4g，避免shuffle、spill场景下堆外内存不足导致的重试与卡顿。
• 开启动态分区自适应调整
  开启Spark AQE能力，配置spark.sql.adaptive.enabled=true、spark.sql.adaptive.shuffle.targetPostShuffleInputSize=128m，不再使用固定的100个shuffle分区，由框架根据实际shuffle数据量自动合并、拆分分区，保证单分区数据量维持在合理区间，避免单task数据量过大或小task过多的问题。
• 自动处理数据倾斜
  开启AQE倾斜join优化：配置spark.sql.adaptive.skewJoin.enabled=true，框架会自动识别倾斜的分区，将大分区拆分为多个小分区并行处理，无需修改业务代码即可覆盖90%以上的倾斜场景。同时检查写入前的计算逻辑，提前过滤无意义的null key，对确认的永久热点key添加随机前缀打散，避免单task承载超量数据。
• 增加作业前置校验
  在写入该表前增加增量数据量校验逻辑，如果当日增量数据量超过历史均值3倍，可主动触发分区数调整，避免极端数据量下的性能问题。

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