作业跑到一半Task失败了——YARN的容错和推测执行机制

分布式系统最大的特点就是'一定会有节点出问题'。在某知名出海硬件品牌用EMR时，100+个Spark作业每天跑，几乎每天都有个别Task因为节点故障、网络超时或磁盘错误而失败。但大部分时候作业不需要人工干预就能自动恢复——这就是YARN的容错机制在起作用。面试官问容错，考的是你对分布式系统可靠性设计的理解。

Task级别容错——失败自动重试

# MapReduce的Task重试配置
mapreduce.map.maxattempts = 4     # Map Task最多重试4次
mapreduce.reduce.maxattempts = 4  # Reduce Task最多重试4次
 
# Spark的Task重试配置
spark.task.maxFailures = 4        # 单个Task最多重试4次
 
# Task失败重试的流程：
# 1. Task在某个Container上执行失败（OOM/异常/网络超时）
# 2. AM收到失败通知
# 3. AM向RM申请新的Container（可能在不同的NM上）
# 4. 在新Container上重新执行该Task
# 5. 如果4次都失败，该Task标记为永久失败
# 6. 整个Stage/Job因此失败
 
# 什么情况下Task会失败？
# - Executor OOM（最常见）
# - 数据读取超时（HDFS/S3网络问题）
# - 节点磁盘错误
# - 代码Bug导致异常

ApplicationMaster级别容错——AM挂了自动重启

# AM重试配置
yarn.resourcemanager.am.max-attempts = 2  # AM最多重启2次
 
# AM重启的场景：
# 1. AM所在的NM节点崩溃
# 2. AM进程OOM（Driver内存不够）
# 3. AM和RM之间心跳超时
 
# AM重启后会发生什么？
# - MapReduce：AM重启后，已完成的Map Task不需要重跑
#   （输出在DataNode的本地磁盘上）
#   只需要重跑正在运行的Task
#
# - Spark：取决于配置
#   开启External Shuffle Service：已完成的Stage不重跑
#   没开启：所有已完成的Stage可能需要重跑
#   建议生产环境开启External Shuffle Service

NodeManager级别容错——节点挂了怎么办？

当一个NM节点挂了（硬件故障、网络断开等），上面运行的所有Container都会丢失：

① RM检测到NM心跳超时（默认10分钟），把该NM标记为Dead。

② 该NM上的所有Container被标记为失败，AM收到通知。

③ AM向RM申请新的Container，在其他存活的NM上重新执行失败的Task。

④ 如果AM本身就在那个NM上，RM会在另一个NM上重启AM，然后AM恢复作业状态。

推测执行（Speculative Execution）——处理慢Task

有时候Task没有失败，但跑得特别慢（比如某个节点磁盘IO高或CPU被其他进程占用）。推测执行会在另一个节点上启动同一个Task的副本，谁先完成就用谁的结果：

# MapReduce推测执行
mapreduce.map.speculative = true     # Map端推测执行
mapreduce.reduce.speculative = true  # Reduce端推测执行
 
# Spark推测执行
spark.speculation = true
spark.speculation.interval = 100ms   # 检查间隔
spark.speculation.multiplier = 1.5   # 比中位数慢1.5倍触发
spark.speculation.quantile = 0.75    # 75%的Task完成后才检查
 
# 推测执行的工作原理：
# 1. 等75%的Task完成后开始检查
# 2. 找到比中位数慢1.5倍以上的Task
# 3. 在另一个NM上启动该Task的副本
# 4. 两个副本谁先完成就用谁的结果
# 5. 另一个副本被kill
 
# 注意：推测执行会消耗额外资源（多启动一个Task）
# 如果集群资源紧张，推测执行可能适得其反