AWS EMR步骤呈RUNNING状态但Spark作业已完成的问题排查

排查原因 #

• 检查Spark应用的收尾进程

  • 执行yarn application -status <你的Spark应用ID>查看应用状态，确认ApplicationMaster是否仍在运行、是否存在未释放的容器或阻塞任务。
  • 查看主节点的YARN ResourceManager日志（/var/log/hadoop-yarn/yarn-yarn-resourcemanager-*.log）和Spark Driver日志（/var/log/spark/spark-history-server-*.log），定位是否有未处理的异常、线程阻塞或资源清理延迟。

• 排查元数据同步延迟

  • 由于启用了spark.sql.sources.partitionOverwriteMode=dynamic，Spark写完数据后可能在同步Hive Metastore的分区信息，尤其是分区数量较多时，元数据更新可能耗时较久。
  • 查看Hive Metastore日志（/var/log/hive/hive-metastore-*.log），检查是否存在元数据更新超时、锁等待或错误。

• 检查存储系统的一致性与延迟

  • 如果写入目标是S3，其最终一致性特性可能导致_SUCCESS文件生成后，Spark仍在重复扫描分区目录验证写入结果，引发延迟。
  • 查看Spark Driver日志中关于S3操作的片段，确认是否有S3请求超时、重试或目录扫描的循环逻辑。

• 检查EMR步骤的收尾脚本

  • EMR步骤自带的日志上传、状态通知等收尾脚本可能执行异常，导致步骤一直处于RUNNING状态。
  • 查看步骤专属日志目录（/var/log/hadoop/steps/step-<你的步骤ID>/）下的日志文件，排查脚本执行是否卡住或报错。

最佳实践 #

• 优化元数据操作配置

  • 启用spark.sql.hive.metastorePartitionPruning=true和spark.sql.hive.convertMetastoreParquet=true，加速Hive元数据的查询与同步效率。
  • 如果无需同步Hive元数据，可调整spark.sql.hive.metastore.sharedPrefixes，移除不必要的元数据交互逻辑，减少收尾阶段的耗时。

• 优化S3写入相关配置（若目标存储为S3）

  • 配置spark.hadoop.fs.s3a.impl=org.apache.hadoop.fs.s3a.S3AFileSystem，使用更高效的S3客户端。
  • 开启spark.hadoop.fs.s3a.fast.upload=true，启用并行上传机制，降低文件写入后的验证时间。
  • 设置spark.hadoop.fs.s3a.directory.marker.retention=keep，避免删除目录标记时的额外IO操作。

• 优化Spark作业的收尾逻辑

  • 在作业代码末尾显式调用spark.stop()，确保SparkSession及相关资源被及时释放。
  • 避免在作业完成后执行大量本地文件操作或外部命令，此类操作易阻塞步骤进程。
  • 若分区数量过大，可拆分作业分批写入，降低单次元数据同步的压力。

• 调整EMR步骤配置

  • 提交步骤时设置合理的超时参数（如--timeout 3600），避免步骤无限期等待。
  • 确保步骤的日志采集配置正常，避免因日志上传失败导致步骤挂起。

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