Spark Streaming（YARN）重启时WAL未恢复数据的原因及条件咨询

这问题我之前帮团队排查过类似的坑，结合Spark Streaming的核心机制，给你拆解下为什么会出现“有时能恢复、有时不能”的情况，以及Spark决定是否从WAL恢复的核心条件：

一、Spark触发WAL恢复的核心条件 #

Spark重启时是否读取WAL，完全依赖Checkpoint元数据和应用一致性，满足以下所有条件才会触发恢复：

• Checkpoint元数据完整且可读取：Spark首先会加载Checkpoint目录下的元数据文件（比如metadata、checkpoint-xx系列文件），只有当元数据里明确记录了WAL的存储路径、已写入的偏移量范围，并且元数据本身没有损坏，才会触发WAL恢复流程。
• 应用配置与代码完全一致：
  • 不能修改WAL相关配置（比如spark.streaming.receiver.writeAheadLog.enable必须保持true）；
  • Checkpoint路径必须和之前完全相同；
  • DStream的拓扑结构不能变（比如不能新增/删除算子、不能修改Receiver类型）；
  • Spark版本、依赖包版本必须和之前一致——哪怕是微小的代码改动，都会让Spark判定为“新应用”，直接跳过旧Checkpoint和WAL。
• WAL文件可访问且完整：HDFS上的WAL文件必须能被YARN运行用户正常读取，且文件本身没有损坏（比如写入时节点故障导致副本未同步完成）。

二、为什么会出现“有时忽略WAL”的情况 #

结合你的场景，大概率是以下几种非确定性因素导致的：

1. Checkpoint元数据写入不完整：
   Spark是周期性写入Checkpoint的（默认间隔是批处理间隔的倍数），如果在Checkpoint写入过程中强制杀死应用（比如yarn application -kill），会生成损坏的元数据文件。下次重启时，Spark读取到不完整的元数据，会直接判定为“首次启动”，忽略WAL；而如果是在Checkpoint写入完成后杀死应用，元数据完整，就能正常恢复。
2. YARN或HDFS的隐性干扰：
   • 部分YARN集群会配置容器临时文件自动清理，如果你的Checkpoint元数据不小心存在本地磁盘（而非HDFS），重启后元数据会被清理，自然无法触发WAL恢复；
   • HDFS的权限变更：如果重启时YARN的运行用户和之前不同，可能会没有WAL文件的读取权限，Spark会跳过WAL直接从JMS消费。
3. Receiver与ApplicationMaster的重启差异：
   如果只是单个Receiver节点挂了，Spark会重启Receiver并自动从WAL恢复；但如果是整个ApplicationMaster挂了，重启后的AM会重新初始化StreamingContext，此时若Checkpoint元数据有任何异常，就会直接忽略WAL。

三、排查与解决建议 #

• 每次重启前，先检查Checkpoint目录的元数据：用hdfs dfs -cat <checkpoint-path>/metadata查看，确认里面包含walDirectory字段，且偏移量记录正常；
• 严格保证重启时的代码、配置、Spark版本完全一致，哪怕是注释改动都尽量避免；
• 用hdfs fsck <wal-path>检查WAL文件的完整性，同时确认YARN运行用户对WAL和Checkpoint目录有读写权限；
• 尽量使用优雅停止方式：比如调用StreamingContext.stop(true, true)，或者用spark-submit的--stop参数，让Spark完成最后一次Checkpoint后再退出，避免强制杀死导致的元数据损坏。

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