Spark 3.4升级后出现授权提交者失败及数据重复风险问题求助

核心原因 #

Spark 3.4对**S3提交器（committer）**的容错逻辑做了针对性调整，尤其适配Spot实例这类可能被强制回收的场景时，出现了和3.3版本的核心差异：

• 3.3版本中，Executor被意外终止时，Spark会默认重试提交逻辑，对提交器的状态校验相对宽松
• 3.4强化了Authorized Committer的一致性校验，当Executor被Spot实例回收（标记为"用户或框架删除"）时，提交器无法确认最终写入状态，直接触发失败告警——即使实际任务逻辑已经完成写入

关键配置差异 #

以下是Spark 3.3与3.4在S3提交器相关配置上的核心变化，也是触发问题的直接原因：

• spark.sql.s3.committer.magic.enabled：3.4默认开启该特性，严格校验Executor存活状态，一旦Executor被回收直接判定提交失败；3.3默认关闭，允许一定程度的状态模糊
• spark.sql.s3.committer.abortOnFailure：3.4默认设为true，要求提交器在Executor异常时必须终止并告警；3.3默认false，会尝试自动恢复
• spark.executor.instances/spark.executor.cores：3.4对Executor资源调度更严格，若配置的实例数/核心数超过Spot资源池上限，会频繁触发Executor回收

解决方案 #

1. 调整提交器容错配置 #

修改Spark配置，放宽3.4的严格校验，适配Spot实例的不稳定特性：

# 关闭magic committer的严格校验
spark.sql.s3.committer.magic.enabled=false
# 允许提交器在Executor异常时自动恢复，不强制失败
spark.sql.s3.committer.abortOnFailure=false
# 启用旧版本的S3提交器，完全兼容3.3行为
spark.sql.s3.committer.class=org.apache.spark.sql.execution.datasources.s3.S3SQLCommitter

2. 优化Spot实例资源配置 #

• 降低spark.executor.instances的数值，避免超出Spot实例池的可用资源，减少Executor被回收的概率
• 开启spark.dynamicAllocation.enabled=true，配合spark.dynamicAllocation.minExecutors/spark.dynamicAllocation.maxExecutors，让Spark根据任务负载自动调整Executor数量，减少不必要的资源占用

3. 数据去重兜底方案 #

针对报错提示的"可能出现数据重复"，建议在任务逻辑中增加兜底机制：

• 写入S3前，为数据添加唯一主键（如业务ID+时间戳）
• 读取数据时，通过DROP DUPLICATES或分组聚合的方式去重，避免重复数据影响下游业务

验证步骤 #

1. 先应用提交器配置调整，运行测试任务观察是否还出现相同报错
2. 若仍有Executor回收问题，再调整动态资源配置
3. 最后验证数据是否存在重复，确保兜底方案生效

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