关于AWS Glue作业使用Spark持久化Parquet数据的机制疑问

1. Glue作业Parquet数据持久化的执行逻辑 #

你使用的matched.write.mode("overwrite").parquet(output)是Spark原生的写入API，Glue托管Spark环境下，结合S3对象存储的特性，完整写入流程分为三步：

• 执行write语句后，Spark首先会在你指定的output路径下创建临时目录（通常命名为_temporary），所有计算节点生成的Parquet分片文件会先写入该临时目录，不会直接覆盖目标路径原有文件，此时写入的文件对外不可见
• 所有计算节点的写入任务全部完成后，Driver节点会执行提交操作：将临时目录下的完整Parquet文件移动到output路径的对应位置，同时删除overwrite模式下需要覆盖的旧文件，最后写入_SUCCESS标记文件，到这一步数据才是对外可访问的
• 只要作业运行过程中出现未捕获的异常，无论异常出现在写入的哪个阶段，Spark和Glue都会自动清理未提交的临时文件，避免产生脏数据

你提到的job.commit()确实仅用于Glue书签元数据的更新，和S3上的文件持久化逻辑完全无关。

2. 「只有Glue作业正常执行结束，数据才会持久化为Parquet」的结论是否正确 #

该结论基本正确，仅存在一个边界例外：如果异常发生在write语句的内部提交逻辑已经执行完成（即_SUCCESS标记已生成）之后，那么数据已经完成持久化，不会被回滚。
你遇到的写入后抛异常、数据不可见的情况，是因为异常触发在write的提交逻辑完成前，Spark会自动清理所有未提交的临时文件，因此你看不到最终的Parquet文件，Athena自然也无法读取。

3. 是否遗漏了相关机制 #

你之前的认知确实遗漏了Spark写入对象存储的两阶段提交机制，以及overwrite模式的原子性保障设计：
Spark为了避免写入中途失败导致旧数据被破坏、或者产出不完整的脏数据，所有写入操作默认都是先写临时目录，全部写入任务成功后才会将文件移动到目标路径，只要提交动作没完成，外部就看不到本次写入的文件。Glue的托管Spark环境完全遵循该逻辑，作业异常终止时还会额外清理残留的临时文件，进一步保证数据一致性。

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