Spark Streaming作业运行数小时后因FileNotFoundException异常退出求助

我之前在EMR上跑Spark Streaming写入S3 Parquet时也碰到过类似的问题，结合你的环境（Spark 2.2.1 + EMR 5.1.1 + Java 8），给你几个实用的排查和解决方向：

1. 优先排查S3的最终一致性问题 #

S3是最终一致性存储，当你在Spark Streaming批次里写入Parquet后，后续的元数据读取、临时文件清理等操作可能因为S3的同步延迟找不到文件——这是这类问题最常见的诱因。

• 修复思路：
  • 切换到s3a协议并启用强一致性：在Spark配置中添加spark.hadoop.fs.s3a.consistent=true，强制S3的读写操作使用强一致性模式
  • 改用时间戳分区目录写入：每个批次将结果写入独立的路径，比如s3://your-bucket/output/yyyyMMddHHmmss/，避免同一路径下频繁写入/覆盖带来的一致性冲突

2. 检查Spark临时文件的清理机制 #

Spark Streaming处理批次时会生成大量临时文件（比如带_temporary前缀的路径），默认的清理策略在S3环境下容易出问题：

• 调试点：查看报错日志里的文件路径，确认是不是临时文件
• 修复思路：
  • 延长临时文件清理延迟：添加配置spark.streaming.driver.cleanupDelay=300000（单位毫秒，比如5分钟），给S3足够的元数据同步时间
  • 临时关闭自动清理验证问题：配置spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=1（注意这个会降低写入性能，仅用来排查问题）
  • 优先使用SaveMode.Append：避免用Overwrite模式覆盖已有文件，减少覆盖过程中文件被删除导致的读取失败

3. 排查Parquet写入的并发与元数据同步问题 #

SqlContext写入Parquet依赖的FileOutputCommitter组件，在EMR+S3环境下的行为和HDFS有差异：

• 调试点：查看EMR每个Executor的YARN日志，确认是不是某个Executor提交文件时失败，导致Driver端找不到目标文件
• 修复思路：
  • 忽略清理失败的情况：添加配置spark.hadoop.mapreduce.fileoutputcommitter.cleanup-failures.ignored=true，避免因临时文件清理失败导致整个批次崩溃
  • 指定S3A文件系统实现：在Spark配置中添加spark.hadoop.fs.s3a.impl=org.apache.hadoop.fs.s3a.S3AFileSystem，确保用最新的S3客户端实现
  • 避免同批次重复写入同一路径：确保每个批次的输出路径唯一，减少并发写入冲突

4. 检查EMR集群的资源与权限配置 #

集群资源不足或权限异常也可能间接导致文件写入失败：

• 调试点：查看EMR Master节点的日志、YARN ResourceManager日志，排查是否有Executor OOM、节点失联的情况；同时确认EMR的IAM角色是否有完整的S3读写权限
• 修复思路：
  • 增加Executor资源：适当调高spark.executor.memory和spark.executor.cores，避免因资源不足导致写入任务中断
  • 配置集群自动扩缩容：确保集群有足够的节点处理高峰期的批次任务
  • 验证S3权限：手动用集群节点的身份访问报错路径，确认是否有权限读写

5. 精细化日志排查 #

最后，通过日志精准定位问题是关键：

• 打开相关包的DEBUG日志，添加以下Spark配置：

  spark.driver.logLevel=DEBUG
  spark.executor.logLevel=DEBUG
  spark.log4j.logger.org.apache.hadoop.fs.s3a=DEBUG
  spark.log4j.logger.org.apache.spark.sql.execution.datasources=DEBUG
  

• 找到FileNotFoundException的完整栈跟踪，确认是写入时找不到临时文件，还是后续读取元数据时找不到文件——这会帮你快速锁定问题根源

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