Spark写Delta表触发FileFormatWriter$.write报错的解决方案咨询

报错核心是ShuffleMapStage重试4次全部失败触发作业终止，直接原因是Shuffle拉取阶段无法连接到对应Executor节点，通常由节点资源过载、网络抖动、Shuffle数据量过大三类原因导致。

• 核查失败节点的监控指标：定位报错信息中10.179开头的Worker节点，拉取作业运行时段的CPU使用率、内存使用率、磁盘IO、网络出入带宽指标，确认是否出现资源被打满、节点进程被OOM kill的情况
• 核查Shuffle阶段数据特征：打开Spark UI查看失败的Stage 13的Shuffle读写总量、单Task处理数据量，确认是否存在数据倾斜（部分Task处理数据量是均值的5倍以上）
• 核查Executor资源配比合理性：当前3台E64_v3规格Worker节点，配置了12个Executor实例，单Executor分配16核54G内存，总核数12*16=192完全占满3台E64_v3的所有可用vCore，无冗余资源留给系统进程、Shuffle服务，高负载下会直接导致网络请求无响应
• 核查目标Delta表状态：确认目标表是否存在分区数过多、历史版本累积量大的情况，Delta快照加载和一致性校验阶段会占用大量Executor资源，进一步加剧节点负载

• 调整Executor资源预留：修改Spark配置，将spark.executor.instances下调至9，spark.executor.cores下调至14，每台Worker节点预留2个核心供系统和Shuffle服务使用，避免CPU完全打满导致网络超时
• 优化Shuffle重试机制：新增配置spark.shuffle.io.maxRetries=10、spark.shuffle.io.retryWait=30s，提高Shuffle拉取的重试次数和间隔，降低偶发网络抖动的影响
• 调整并行度配置：如果本次作业Shuffle总数据量超过2TB，将spark.sql.shuffle.partitions和spark.default.parallelism从576上调至1152，降低单Task处理的数据量，分散节点负载
• 优化Delta写入逻辑：写入前对DataFrame执行repartition操作打散倾斜数据，如果是分区表覆写且可保证写入数据符合分区约束，可开启配置spark.databricks.delta.replaceWhere.constraintCheck.enabled=false，降低Delta一致性校验的资源开销
• 临时扩容集群：若确认是数据量超过当前集群承载能力，临时将Worker节点从3台扩容至5台，分散Shuffle压力

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