Databricks Spark写入S3生成_committed/_start文件的原因及解决咨询

1. _committed和_start文件的生成原因与作用 #

这些文件是Spark分布式写入操作的事务日志标记文件，核心是为了在S3这类最终一致性的对象存储上保证写入的原子性与可靠性：

• _start文件：在写入任务启动时创建，用于标记一个写入事务的开始，防止同一路径下的重复写入操作冲突。
• _committed文件：当所有写入任务成功完成后创建，标记事务提交成功。Spark通过检查该文件来确认写入是否完整，避免读取到部分写入的不完整数据。
  因为S3不支持本地文件系统的强一致性语义，Spark需要这类文件来弥补分布式场景下的一致性校验能力。

2. 是否与Databricks Runtime/DBFS特性相关 #

不是Databricks专属特性，这是Apache Spark本身的分布式写入机制，但Databricks Runtime在适配S3存储时，默认保留了这一行为——因为S3的最终一致性特性，这类文件是保证写入可靠性的必要手段。DBFS作为S3的挂载层，只是传递了Spark的写入逻辑，并非触发这类文件的根源。你的环境中Spark 3.1.2本身就内置了这个机制。

3. 避免或清理这类文件的方法 #

完全禁止生成这类文件会牺牲写入的一致性可靠性，不建议在生产环境中这么做，但可以通过以下方式处理：

• 关闭事务标记（风险较高）：设置Spark配置spark.hadoop.mapreduce.fileoutputcommitter.marksuccessfuljobs=false，这会阻止生成_committed和_start文件，但可能导致无法校验写入完整性，仅适合对一致性要求极低的场景。
• 写入后清理文件：在确认写入完全成功后，用Databricks工具或Spark API删除这类文件，比如执行：

  dbutils.fs.rm("s3://your-output-path/*_committed*", recurse=True)
  dbutils.fs.rm("s3://your-output-path/*_start*", recurse=True)
  

• 升级Spark版本（如果可行）：Spark 3.2及以上版本对对象存储的写入逻辑做了优化，减少了这类文件的生成，但需要对应升级Databricks Runtime版本（比如DR 10.4+）。

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