Hadoop YARN 任务失败排查指南：从定位到解决

任务类型：MapReduce、Spark、Hive on MR、Spark‑SQL；运行在 YARN 上。

核心思路：先看任务状态 → 看 YARN 日志 → 看具体异常栈 → 区分资源问题 / 代码逻辑 / 集群底层问题。

一、第一步：YARN WebUI 初步定位（最优先）

访问 ResourceManager WebUI，查看失败任务（Failed 状态）。

1. 查看Application ID，记录application_xxxx。
2. 查看最终状态：
   • FINISHED：正常结束。
   • FAILED：任务自身代码异常。
   • KILLED：被人为杀死，或资源抢占、超时、内存超了被 NM 杀掉。
   • SUBMITTED：还没分配资源。
   • ACCEPTED：已经接收，等待资源。
3. 查看失败原因摘要：UI 上会展示简单 message。

区分：

• Application 失败：整个作业挂掉。
• Application 成功，但部分 Task 失败：map task / reduce task / spark task 失败，任务会重试，重试耗尽后作业失败。

二、区分是 Application 被 KILL，还是 FAILED

1）状态为 KILLED

常见原因：

1. 人为执行yarn application -kill appId。
2. AM（ApplicationMaster）内存溢出 OOM，NodeManager 把容器杀掉。
3. 资源抢占：队列资源不足，YARN 抢占容器。
4. AM 超时失联：AM 长时间没有向 RM 心跳，超时被 kill。
5. 磁盘超出阈值：NodeManager 本地磁盘使用率过高，杀掉容器。

2）状态为 FAILED

业务代码、数据、逻辑、Shuffle 异常，看日志里的 Exception 堆栈。

三、获取日志（关键操作）

方式 1：命令行抓取日志（生产最常用）

# 获取整个 application 全部日志 yarn logs -applicationId application_xxxxxx > app.log 只看 AM 日志（优先看 AM，AM 是作业管理者） yarn logs -applicationId application_xxxxxx -am > am.log

AM 日志：作业的入口，能看到作业的整体报错、配置、初始化异常。如果只是个别 task 失败，需要看具体 Container 日志。

方式 2：WebUI 点击 logs 链接，直接浏览器查看容器日志

注意：容器完成后，日志聚合开启才可以看；没有开启日志聚合，容器销毁日志就丢失。配置：yarn.log‑aggregation‑enable=true

四、分层排查，按顺序

第一层：AM 日志（ApplicationMaster）

先看 AM，判断是作业初始化失败，还是 task 运行阶段失败。

• 如果 AM 直接报错退出：作业还没开始跑 task 就失败。常见：jar 包缺失、类冲突、参数错误、权限、队列不存在。
• AM 正常运行，是部分 Container Task 失败：需要看对应 Container 日志。

第二层：Container（Map/Reduce/Spark Task）日志

一个 Container 对应一个 task，stdout、stderr 日志。重点看stderr，异常堆栈打印在这里。

常见异常分类：

① 内存相关（最高频）

1. Container is running beyond memory limits

Container 超出分配的内存上限，被 NodeManager 直接杀死。

• 两种内存：物理内存、虚拟内存。
• 常见原因：数据倾斜导致单个 task 处理的数据量过大；内存参数设置过小；代码中存在大对象。
• 处理方式：调大 map/reduce/spark executor 内存；排查数据倾斜；优化代码。

2. java.lang.OutOfMemoryError：OOM 堆内存溢出，需要区分是 AM OOM 还是 task OOM。

AM OOM是 ApplicationMaster 进程内存溢出。AM 是整个作业的调度进程，一个 job 只有一个 AM，一旦发生 OOM，整个 job 会直接失败。这种情况大多是 task 数量过多，AM 需要维护大量任务元数据，最终撑爆堆内存。

处理：调大 AM 容器内存与 JVM 堆；优先合并小文件以减少 task 总数，不能只单纯加大内存。

yarn.app.mapreduce.am.resource.mb=4096 yarn.app.mapreduce.am.java.opts=-Xmx3072m

Task OOM是 Map 或 Reduce 计算任务发生 OOM，负责实际的数据计算。一般是个别 task 报错，会自动重试，多次失败后才会导致 job 失败。常见原因是单任务数据量大、数据倾斜。

处理：调大对应 map/reduce 内存；检查是否存在数据倾斜，增加 reduce 并行度、对热点 key 打散，合并小文件。

详解：Map Task OOM、Reduce Task OOM

1）Map Task OOM

原因：单个分片数据过大，读取数据时加载了大量对象；小文件合并不到位。

处理：

• 调大 map 内存：mapreduce.map.memory.mb，同时调大-Xmx。
• 合并小文件，控制每个 map 处理的数据量，避免单个 map 处理超大文件。

2）Reduce Task OOM（尤其数据倾斜）

最常见的是数据倾斜：某一个 reduce key 的数据量巨大，全部加载进内存聚合，直接导致 OOM。

处理步骤：

1. 调大 reduce 容器内存和堆

   mapreduce.reduce.memory.mb=8192 mapreduce.reduce.java.opts=-Xmx6144m

2. 排查数据倾斜：查看 Counter（计数器），观察每个 reduce 处理的数据量，定位热点 key。
3. 解决方案：
   • 开启 MapReduce 数据倾斜优化；
   • 对热点 key 加盐打散，进行二次聚合；
   • 调大 reduce 并行度，增加 reduce 数量以分摊数据。
4. shuffle 阶段溢写参数优化：调大溢写阈值，减少内存压力。

Task OOM 应优先排查数据倾斜，不要一上来就无脑堆内存。

② 数据 / 业务逻辑异常

• NullPointerException：NPE 空指针，属于业务代码 bug。
• ArrayIndexOutOfBounds：数组越界。
• 数据格式异常：Hive 读取脏数据、类型转换异常、字符串转数字失败。
• 序列化异常：序列化 / 反序列化报错。

③ Shuffle 相关失败（MR、Spark）

• 拉取 shuffle 数据失败：Failed to fetch map output。原因：DataNode 挂掉、网络抖动、磁盘 IO 过高、shuffle 数据磁盘满。
• Shuffle 文件损坏。
• 大量 fetch 失败，任务重试达到上限，作业失败。

④ HDFS 读写异常

• FileNotFound：文件不存在，输入路径被删除，路径写错。
• 权限异常：Permission denied，用户没有读 / 写 HDFS 目录权限。
• HDFS 集群异常：DN 宕机，块损坏，磁盘满。

⑤ 本地磁盘（NodeManager 本地目录）问题

YARN 容器会写本地磁盘（nm‑local‑dirs），shuffle 中间数据写这里！报错：No space left on device，NodeManager 本地磁盘满，task 写 shuffle 失败。

注意：不是 HDFS 磁盘！是 YARN 节点机器本地磁盘。

⑥ 资源队列问题

• 队列容量已满，拿不到资源，任务一直 ACCEPTED，最后超时失败。
• 用户没有该队列提交权限。
• 最大并发任务数限制。

五、辅助排查命令

# 查看 yarn 队列资源 yarn queue -status 队列名 # 查看集群节点状态，是否有节点 UNHEALTHY 不健康 yarn node -list -all # 查看 HDFS 状态，是否有损坏块 hdfs fsck / # 查看 NodeManager 健康状态：UNHEALTHY 代表本地磁盘满/故障，该节点不再分配容器 yarn node -list -all

NodeManager 状态变成unhealthy：本机多块本地磁盘故障 / 磁盘满，该节点不接收新容器。

六、高频现象总结

1. 任务一直 ACCEPTED，不运行：队列资源耗尽，没有可用资源；NodeManager 全部不健康；标签资源不匹配。
2. 部分 task 失败，大部分 task 成功，重试几次后作业失败：优先怀疑数据倾斜、单 task 数据量过大 OOM、脏数据、shuffle 读取失败。
3. 一提交直接失败，没有任何 map/reduce task 运行：看 AM 日志，检查 jar 包、类不存在、参数错误、路径错误、权限。
4. Container killed by NodeManager：绝大多数是内存超限；其次是 NM 本地磁盘满，节点不健康。

七、精简版

YARN 上任务失败排查步骤：

1. 访问 RM WebUI，拿到 applicationId，观察作业状态是 FAILED 还是 KILLED。
2. 优先查看 AM 日志，判断是作业初始化阶段失败，还是 Task 运行阶段失败。
3. 如果是 Task 失败，查看对应 Container stderr 日志，抓取异常堆栈。
4. 归类问题：
   • 容器被 KILL：内存超限制 OOM、NM 本地磁盘满、资源抢占、AM 心跳超时。
   • FAILED：业务代码 bug、脏数据、序列化异常。
   • Shuffle 报错：网络、磁盘 IO、节点故障。
   • HDFS 报错：路径、权限、块损坏、磁盘满。
5. 辅助检查 YARN 节点健康状态、队列资源、HDFS 集群状态。

补充踩坑点

1. 日志聚合没开启，容器销毁后日志丢失，无法排查；生产必须开启日志聚合。
2. 区分两套磁盘：
   • HDFS 磁盘：DataNode 存储业务数据。
   • YARN‑NM 本地磁盘：存放容器临时文件、shuffle 中间结果。NM 本地磁盘满会直接导致 task 失败，和 HDFS 磁盘无关！
3. 任务会自动重试，个别 task 失败会重试，重试次数耗尽，整个作业才标记失败。