EMR环境下Spark写入Parquet任务无法结束问题求助

听起来你碰到了个挺挠头的问题——所有内部任务都跑完了，Parquet文件也生成了，但Spark应用就是卡在那儿不肯结束。结合你的环境（EMR-5.13.0、Spark 2.3.0、Scala 2.11）和代码逻辑，我给你梳理几个可能的原因和对应的解决办法：

1. 排查FileOutputCommitter版本的兼容性问题 #

你用到了mapreduce.fileoutputcommitter.algorithm.version=2，这个版本的Committer在旧版EMR+Spark的组合里（尤其是Spark 2.3.x搭配EMR-5.x），在Append模式下偶尔会出现线程挂起的bug。Version 2采用了异步提交逻辑，但老版本的Hadoop/EMR对这种异步处理的支持不够稳定，导致Driver一直等待Committer的线程完成，实际上这些线程已经卡住了。

解决办法：
把Committer版本换回1试试，或者直接去掉这个配置用默认值：

newDf.coalesce(partitions)
  .write
  .partitionBy("key1", "key2")
  .mode(SaveMode.Append)
  .parquet(destination)

或者显式指定version=1：

newDf.coalesce(partitions)
  .write
  .option("mapreduce.fileoutputcommitter.algorithm.version", "1")
  .partitionBy("key1", "key2")
  .mode(SaveMode.Append)
  .parquet(destination)

2. 避免coalesce和partitionBy混用的隐患 #

你先做了coalesce(partitions)紧接着又用partitionBy("key1", "key2")——这里有个隐性问题：coalesce是窄依赖操作，不会重新shuffle数据，但partitionBy会强制触发一次shuffle来重新分区。这种组合可能导致数据分布不均，或者在Commit阶段因为分区文件的合并逻辑出现异常，让Driver误以为还有任务在运行。

优化方案：
如果必须控制最终的文件数量，建议先按分区键处理，再用repartition（而非coalesce）控制文件数，或者直接把分区字段加到repartition里，一次性完成分区和文件数量控制：

// 同时按分区键和目标文件数分区
newDf.repartition($"key1", $"key2", partitions)
  .write
  .mode(SaveMode.Append)
  .parquet(destination)

这样可以避免不必要的窄依赖操作带来的后续问题。

3. 检查YARN资源配置是否充足 #

在EMR的YARN环境下，如果Application Master（AM）或Driver的内存不足，在Parquet写入的最后阶段（比如合并元数据文件_metadata、_SUCCESS）可能会因为资源不足导致线程阻塞，看起来任务都完成了，但AM/Driver一直在等待资源释放。

建议调整的参数：
提交Spark任务时，可以增加以下配置（数值根据集群规模调整）：

--conf spark.driver.memory=8g \
--conf spark.yarn.am.memory=4g \
--conf spark.executor.memoryOverhead=2g

核心是给Driver和AM足够的资源处理最后阶段的元数据操作。

4. 查看Driver日志定位卡住的线程 #

如果上面的方案都没解决问题，建议去EMR控制台下载Driver的日志，重点看任务完成后的日志内容，找有没有类似"Waiting for committer"或者线程阻塞的堆栈信息。通常这种卡住的情况，日志里会有明确线索——比如某个线程在等待文件锁，或者元数据写入超时。

比如，你可能会看到某个线程卡在org.apache.hadoop.fs.FileSystem的某个方法上，这大概率就是Committer的问题，换回Version 1就能解决。

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