YARN介绍与实战

源图客2026-10-14 22:34

YARN 原理与实验讲义

课程信息

项目 内容
实验环境 Hadoop 3.5.0 完全分布式集群（1 主多从）
前置知识 HDFS 基本操作（hadoop fs 命令）、Linux 常用命令

学习目标

知识目标

  1. 能说出 YARN 的定位与作用，理解 Hadoop 1.0 与 2.0 在体系结构上的区别；

  2. 能准确描述 YARN 四大核心组件（RM、NM、AM、Container）的职责及协作关系；

  3. 能区分三种资源调度器（FIFO、Capacity、Fair）的工作原理与适用场景；

  4. 能说出 yarn-site.xml 中常用配置参数的含义与默认值。

技能目标

  1. 会启动、关闭 YARN 集群，并通过 jps 命令验证进程状态；

  2. 会通过 Web UI（8088/19888）监控集群与作业；

  3. 会使用 yarn application 系列命令查询、筛选、终止作业；

  4. 能独立完成"单词计数"实验：准备数据 → 上传 HDFS → 提交作业 → 查看结果。

目录

  • [第一节 YARN 概述](#第一节 YARN 概述)

  • [第二节 YARN 体系架构](#第二节 YARN 体系架构)

  • [第三节 YARN 调度器](#第三节 YARN 调度器)

  • [第四节 YARN 常见配置（yarn-site.xml）](#第四节 YARN 常见配置（yarn-site.xml）)

  • [第五节 YARN 常用命令](#第五节 YARN 常用命令)

  • [第六节 实验案例：单词计数](#第六节 实验案例：单词计数)

  • [附录A 常见问题排查](#附录A 常见问题排查)

  • [附录B 术语表](#附录B 术语表)

第一节 YARN 概述

1.1 YARN 是什么

Apache Hadoop YARN（Yet Another Resource Negotiator，另一种资源协调者）是 Hadoop 集群当中的资源管理系统 模块。从 Hadoop 2.x 开始引入 YARN，用来管理集群当中的资源（主要是服务器的各种硬件资源，包括 CPU、内存），以及运行在 YARN 上面的各种任务。

总结成一句话：YARN 主要就是为了资源管理、任务调度。

在 Hadoop 1.0 时代，MapReduce 既负责"数据处理"，又负责"集群资源管理"，两个职能耦合在一起，其他计算框架无法共用集群资源。Hadoop 2.0 把资源管理职能从 MapReduce 中剥离出来交给 YARN：MapReduce（以及 Spark 等其他框架）只负责数据处理，全部运行在 YARN 之上。

【本节知识点】

  • YARN 全称 Yet Another Resource Negotiator，是 Hadoop 的资源管理系统模块；

  • YARN 从 Hadoop 2.x 开始引入，管理的资源主要是 CPU 和内存；

  • YARN 的两大核心职能：资源管理 + 任务调度；

  • 引入 YARN 后，MapReduce 只负责数据处理，多种计算框架可共享集群资源。

1.2 YARN 的启动与关闭

YARN 的启停脚本位于 Hadoop 安装目录的 sbin 目录下。通常在 HDFS 已启动（start-dfs.sh）的基础上，在主节点执行以下命令：

复制代码 
# 1. 定位到 hadoop 安装目录（以实际安装路径为准）
cd /usr/local/hadoop-3.5.0
​
# 2. 启动 YARN（在主节点执行，会远程拉起各从节点的 NodeManager）
./sbin/start-yarn.sh
​
# 3. 关闭 YARN
./sbin/stop-yarn.sh
​
# 4. 启动历史日志服务（查看已完成作业的日志）
./sbin/mr-jobhistory-daemon.sh start historyserver
​
# 5. 启动 timeline 服务
./sbin/yarn-daemon.sh start timelineserver

启动完成后，用 jps 命令验证进程。正常情况下应能看到 ResourceManager （主节点）和 NodeManager（各从节点）两个进程：

复制代码 
jps

【操作要点】

  • start-yarn.sh 只需在主节点执行一次，无需到每台从节点上分别启动；

  • jps 看不到 NodeManager 时，先检查从节点的 yarn-site.xml 配置与 SSH 免密登录；

  • JobHistoryServer 与 TimelineServer 是辅助服务，不启动不影响作业提交，但会影响历史日志查看。

1.3 YARN 常用访问地址

服务 地址（示例，IP 以实际集群为准） 用途
YARN 集群监控管理界面 http://192.168.1.11:8088/cluster 查看集群资源、节点、所有应用程序
JobHistoryServer 查看界面 http://192.168.1.11:19888/jobhistory 查看已完成作业的详细历史日志

在浏览器中打开 8088 端口的集群监控界面，可以看到集群整体资源（内存、CPU 核数）、活跃节点数，以及所有应用程序的列表与状态：

【本节知识点】

  • 8088：ResourceManager Web UI，作业运行期间和结束后都可访问；

  • 19888 ：JobHistoryServer Web UI，专门查询已完成作业的历史日志；

  • 两个端口的前提：对应服务已启动，且服务器防火墙已放行端口。

1.4 YARN 帮助文档

养成查官方文档的习惯：调度器配置、参数含义等进阶内容，都以官方文档为准。

【上机操作 1】启动 YARN 并访问 Web UI（约 10 分钟）

前置条件

复制代码 
cd /usr/local/soft/hadoop-3.5.0/

  1. 在主节点执行 ./sbin/start-yarn.sh 启动 YARN；

  2. 执行 jps，确认出现 ResourceManager 进程；到任一从节点执行 jps，确认出现 NodeManager 进程；

  3. 在浏览器打开 http://主节点IP:8088/cluster，记录页面上的 Mem Total 与 VCoers Total（即集群可用内存与虚拟核数）；

  4. 执行 ./sbin/mr-jobhistory-daemon.sh start historyserver，刷新 19888 端口页面确认可访问；

  5. 实验结束后如需释放资源，执行 ./sbin/stop-yarn.sh 关闭集群。

第二节 YARN 体系架构

2.1 总体架构

YARN 的架构由 ResourceManager（RM） 和 NodeManager（NM） 组成：RM 是全局的资源仲裁者，NM 是各工作节点上的资源代理，应用程序则以 Container 为资源单位运行在 NM 之上，由 ApplicationMaster 负责协调。

各组件职责一览：

组件 所属层面 核心职责
ResourceManager 全局，主节点 负责 Job 之间资源的协调和仲裁；内含 Scheduler 与 ApplicationsManager
NodeManager 单节点，从节点 负责 Container 的管理和主机资源的监控（cpu、mem、disk、network），并把 Container 和监控状态报告给 ResourceManager
ApplicationMaster 每个应用一个 用户提交的 job，负责向 RM 申请资源，与 NM 交互，执行和监控 job
Container 运行实例 资源的分配单位，封装任务运行所需的节点、内存、CPU 等资源

【本节知识点】

  • RM 又包括两个内部组件：

    • Scheduler（调度器） ：负责资源的管理和 JOB 的运行监控，常用有 FairScheduler 和 CapacityScheduler；

    • ApplicationsManager：负责接收用户提交的 JOB；协调启动第 1 个 AM 的 Container；提供 AM 失败重启；

  • 一个应用程序 = 1 个 ApplicationMaster + N 个 Container。

2.2 ResourceManager（资源管理器）

ResourceManager 是 YARN 的"大脑"，运行在主节点上，负责 Job 之间资源的协调和仲裁。它主要承担四项职责：

  1. 处理客户端请求；

  2. 启动 / 监控 ApplicationMaster；

  3. 监控 NodeManager；

  4. 资源分配与调度。

注意区分：RM 负责"整体资源的分配调度"，但不负责单个应用程序内部的任务执行------那是由每个应用自己的 ApplicationMaster 负责的。

2.3 NodeManager（节点管理器）

NodeManager 运行在每个从节点上，负责单个节点上的资源管理和任务管理。主要职责包括：

  1. 接收并处理来自 ResourceManager 的命令；

  2. 接收并处理来自 ApplicationMaster 的命令；

  3. 管理抽象容器 Container；

  4. 定时向 RM 汇报本节点资源使用情况和各个 Container 的运行状态。

2.4 ApplicationMaster（应用程序管理者）

当有新的任务提交到 ResourceManager 的时候，ResourceManager 会在某个从节点 NodeManager 上面启动一个 ApplicationMaster 进程。

ApplicationMaster 的主要作用：

  1. 为应用程序申请资源；

  2. 任务执行的资源分配；

  3. 任务的生命周期监控。

每个应用程序都有自己专属的 AM：MapReduce 作业有 MRAppMaster，Spark 作业有 Spark 的 AM。AM 与 RM 之间是"申请---分配"关系，与 NM 之间是"启动---运行 Container"关系。

2.5 Container（容器）

Container 是 YARN 的资源分配单位。ApplicationMaster 启动之后，与 ResourceManager 进行通信，向 ResourceManager 提出资源申请的请求；然后 ResourceManager 将资源分配给 ApplicationMaster------这些资源的表示，就是一个个的 Container。

Container 的主要作用：

  1. 封装任务运行资源（节点、内存、CPU）；

  2. 是对任务运行环境的抽象。

【本节知识点】

  • Container = 一定量资源（内存 + CPU 核数）+ 在某个节点上运行任务的环境抽象；

  • AM 自己也运行在第一个 Container 中（由 ApplicationsManager 协调启动）；

  • 任务（MapTask / ReduceTask）都运行在 Container 里。

2.6 JobHistoryServer（作业历史服务）

这是 YARN 提供的一个查看已经完成的任务的历史日志记录的服务。启动 JobHistoryServer 后，可以观察已经完成的任务的所有详细日志信息。

访问界面：http://服务器地址:19888/jobhistory

2.7 TimelineServer（时间线服务）

背景 ：在 hadoop 2.4 版本之前，对任务执行的监控只开发了针对 MR 的 Job History Server，它可以提供给用户查询已经运行完成的作业的信息。但是后来，随着在 YARN 上面集成的计算框架越来越多（比如 Spark、Tez），有必要为基于这些计算引擎的技术开发相应的作业任务监控工具。所以 hadoop 的开发人员就考虑开发一款更加通用的 Job History Server，即 YARN Timeline，用来监控所有运行在 yarn 平台上面的所有任务（例如 MR、Storm、Spark、HBase 等等）。

主要职责：收集并检索应用程序或者框架的相关信息。应用程序开发者可以在 AppMaster 端或者应用程序 containers 中通过 TimelineClient 将这些信息发送给 Timeline Server。这些信息都可以通过 REST APIs 在具体 App 或者执行框架的 UI 界面查询到。

【本节知识点】

  • JobHistoryServer 面向 MapReduce 作业；TimelineServer 是更通用的历史信息服务，可覆盖多种计算框架；

  • 两者互补而非替代：查 MR 历史日志用 19888，跨框架的运行信息收集与检索用 TimelineServer。

【本节思考题】

  1. 客户端提交作业后，RM、NM、AM、Container 分别发生了什么？请按时间顺序描述一遍。

  2. RM 内部的 Scheduler 和 ApplicationsManager 各自负责什么？

  3. JobHistoryServer 与 TimelineServer 的区别是什么？为什么 2.4 版本之后要开发 TimelineServer？

第三节 YARN 调度器

3.1 为什么需要调度器

在 YARN 框架中，调度器是一块很重要的内容。有了合适的调度规则，就可以保证多个应用在同一时间有条不紊地工作。

最原始的调度规则就是 FIFO，即按照用户提交任务的时间来决定哪个任务先执行。但这样很可能出现两个问题：

  • 大任务独占资源：一个大任务先提交，占满集群，其他任务只能不断等待；

  • 饥饿（starvation）：一堆小任务持续提交占满资源，大任务一直无法得到适当的资源。

所以 FIFO 虽然很简单，但是并不能满足我们的需求。YARN 默认提供了另外两种常用的调度规则：Capacity Scheduler 与 Fair Scheduler。

3.2 FIFO Scheduler（队列调度器）

FIFO Scheduler 把应用按提交的顺序排成一个队列，这是一个先进先出队列。在进行资源分配的时候，先给队列中最头上的应用分配资源，待最头上的应用需求满足后，再给下一个分配，以此类推。

FIFO Scheduler 是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群 ------大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在集群中更适合采用 Capacity Scheduler 或 Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。

3.3 Capacity Scheduler（容量调度器）

Capacity Scheduler 是 Apache 版本 Hadoop 默认使用的调度器。

Capacity 调度器允许多租户共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列 ，再为每个队列分配一定的集群资源，整个集群就可以通过设置多个队列的方式给多个租户提供服务。除此之外，队列内部又可以垂直划分 ，这样一个组织内部的多个成员就可以共享这个队列资源了。在一个队列内部，资源的调度采用的是**先进先出（FIFO）**策略。

启用 Capacity Scheduler （在 yarn-site.xml 中配置）：

复制代码 
<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>

更多配置请参考官方文档：Apache Hadoop 3.5.0 -- Hadoop: Capacity Scheduler

3.4 Fair Scheduler（公平调度器）

Fair Scheduler 是 CDH 版本的 Hadoop 默认使用的调度器 ，其设计目标是为所有的应用分配公平的资源（对"公平"的定义可以通过参数来设置）。公平调度也可以在多个队列间工作。

举例：假设有两个用户 A 和 B，他们分别拥有一个队列------

  1. 当 A 启动一个 job 而 B 没有任务时，A 会获得全部集群资源；

  2. 当 B 启动一个 job 后，A 的 job 会继续运行，不过一会儿之后，两个任务会各自获得一半的集群资源；

  3. 如果此时 B 再启动第二个 job，则它会和 B 的第一个 job 共享 B 这个队列的资源------也就是 B 的两个 job 会分别使用四分之一 的集群资源，而 A 的 job 仍然占用集群一半 的资源。结果就是：资源最终在两个用户之间平等地共享。

设计思想 ：把资源（CPU、MEM 等）平均地分配到每个 application，是一种基于时间的等额资源分配策略 ，缺省是以 MEM 作为资源平均分配的策略。调度器把资源分隔为一个一个的 queue（队列），资源在这些 queue 中平均分配。一般来讲，一个 application 只能归属到其中一个 queue：当只有一个 application 运行时，它会尽可能使用该 queue 的所有资源；当有新的 application 提交时，空闲出来的资源会分配给新的 application。这样，每一个 application 都可以得到合理的资源。YARN 提供了一个缺省的 queue，名字为 default。

启用 Fair Scheduler （在 yarn-site.xml 中配置）：

复制代码 
<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

更多配置请参考官方文档：Apache Hadoop 3.5.0 -- Hadoop: Fair Scheduler

3.5 三种调度器对比

对比维度 FIFO Capacity Scheduler Fair Scheduler
资源分配方式 按提交顺序，先满足队头 按队列划分，队列预留容量 按公平份额动态均衡
适用场景 单用户、简单批处理 多组织多租户，需要资源隔离 多用户共享，强调公平与快速响应
是否需要配置 不需要 需要配置队列与容量 需要配置队列与公平策略
队列内部策略 ------ FIFO 公平共享
默认发行版 ------ Apache Hadoop 默认 CDH Hadoop 默认

【本节知识点】

  • FIFO 的两大缺陷：大任务独占资源阻塞他人、小任务挤压大任务造成饥饿；

  • Capacity：队列隔离、容量预留，队列内部 FIFO，Apache 默认；

  • Fair：空闲资源即借即还、按份额均衡，缺省按内存均衡，CDH 默认；

  • 三者都通过 yarn.resourcemanager.scheduler.class 参数启用，配置后需重启 RM 生效。

第四节 YARN 常见配置（yarn-site.xml）

YARN 的核心配置文件是 yarn-site.xml（位于 $HADOOP_HOME/etc/hadoop/ 目录）。常用参数如下：

参数 默认值 说明
yarn.scheduler.minimum-allocation-mb 1024 给应用程序 container 分配的最小内存（MB）
yarn.scheduler.maximum-allocation-mb 8192 给应用程序 container 分配的最大内存（MB）
yarn.scheduler.minimum-allocation-vcores 1 每个 container 默认给分配的最小虚拟内核个数
yarn.scheduler.maximum-allocation-vcores 4 每个 container 可以分配的最大虚拟内核个数
yarn.nodemanager.resource.memory-mb 8192 NodeManager 可以分配的最大内存大小（MB）
mapreduce.framework.name local（需改为 yarn） 指定 MR 运行在 yarn 上
yarn.nodemanager.aux-services ------ 配置为 mapreduce_shuffle，指定节点可以运行 MapReduce 程序
yarn.resourcemanager.hostname ------ 指定 YARN 的 ResourceManager 的地址
yarn.log-aggregation-enable false 日志聚集功能：应用运行完成以后，将日志信息上传到 HDFS 系统上
yarn.log-aggregation.retain-seconds 604800（7 天） 日志保留时间，默认 7 天

常用配置示例（片段，按集群实际情况修改）：

复制代码 
<configuration>
  <!-- 指定 ResourceManager 所在主机 -->
  <property>
    <name>yarn.resourcemanager.hostname</name>
    <value>node11</value>
  </property>
​
  <!-- 指定 MR 运行在 yarn 上 -->
  <property>
    <name>mapreduce.framework.name</name>
    <value>yarn</value>
  </property>
​
  <!-- 指定节点可以运行 mapreduce 程序（shuffle 服务） -->
  <property>
    <name>yarn.nodemanager.aux-services</name>
    <value>mapreduce_shuffle</value>
  </property>
​
  <!-- 开启日志聚集 -->
  <property>
    <name>yarn.log-aggregation-enable</name>
    <value>true</value>
  </property>
</configuration>

【本节知识点】

  • minimum/maximum-allocation-* 四个参数决定了单个 Container 能申请到的资源上下限；

  • yarn.nodemanager.resource.memory-mb 决定每个节点能贡献给 YARN 的总内存；

  • mapreduce.framework.name=yarn 与 aux-services=mapreduce_shuffle 两项不配，MR 作业无法在 YARN 上运行；

  • 修改配置后需要重启 YARN 才能生效；集群所有节点的配置应保持一致。

第五节 YARN 常用命令

YARN 对外提供 yarn application 子命令来管理应用程序，基本语法：

复制代码 
yarn application [-options]
功能 命令 说明
列出所有应用 yarn application -list 列出所有 application 信息
按状态筛选 yarn application -list -appStates RUNNING 与 -list 一起使用，筛选不同状态的 application，多个用 , 分隔
按类型筛选 yarn application -list -appTypes MAPREDUCE 与 -list 一起使用，筛选不同类型的 application，多个用 , 分隔
杀死应用 yarn application -kill <Application ID> 杀死一个 application，需指定 Application ID
查看应用状态 yarn application -status <Application ID> 列出某个 application 的状态

所有状态 ：ALL, NEW, NEW_SAVING, SUBMITTED, ACCEPTED, RUNNING, FINISHED, FAILED, KILLED

命令示例：

复制代码 
# 1. 列出所有 application
yarn application -list
​
# 2. 只看正在运行的任务
yarn application -list -appStates RUNNING
​
# 3. 只看 MAPREDUCE 类型的任务
yarn application -list -appTypes MAPREDUCE
​
# 4. 杀死一个 application（Application ID 从 -list 结果中获取）
yarn application -kill application_1526100291229_206393
​
# 5. 查看某个 application 的状态
yarn application -status application_1526100291229_206393

【上机操作 2】application 常用命令练习（约 10 分钟）

  1. 执行 yarn application -list，观察当前集群的应用列表（没有作业时列表为空属正常）；

  2. 执行 yarn application -list -appStates FINISHED，观察已完成应用（需先完成第六节实验再回来验证）；

  3. 任选一个 Application ID，执行 yarn application -status <ID>，抄录其 State 与 FinalStatus 字段；

  4. （选做）提交一个运行时间较长的作业，用 -kill 将其终止，再到 8088 页面确认其状态变为 KILLED。

第六节 实验案例：单词计数

6.1 实验目的

  1. 掌握向 YARN 提交 MapReduce 作业的完整流程；

  2. 观察 YARN 为作业分配资源、运行 Container 的过程；

  3. 学会通过命令行和 Web UI 两种方式查看作业运行状态与结果。

6.2 实验环境

  • Hadoop 3.5.0 完全分布式集群，YARN 已启动（start-yarn.sh），HDFS 已启动（start-dfs.sh）；

  • 示例程序使用 Hadoop 自带的 hadoop-mapreduce-examples-3.5.0.jar 中的 wordcount；

  • 准备一个纯文本数据文件（如 nalan.txt）。

6.3 实验原理

wordcount（单词计数）是 MapReduce 的经典入门程序：Map 阶段把文本切分成单词并标记 1，Reduce 阶段按单词汇总出现次数。作业提交到 YARN 后，由 ResourceManager 协调启动 ApplicationMaster，再由 AM 向 RM 申请 Container 运行 MapTask 与 ReduceTask------这正是第二节所学的组件协作过程。

6.4 实验步骤

Step 1：将 Linux 本地文件上传到 HDFS

复制代码 
hadoop fs -put /usr/local/data/nalan.txt /nalan

上传后可用 hadoop fs -ls /nalan 确认文件已存在。

Step 2：执行单词计数作业

复制代码 
cd /usr/local/soft/hadoop-3.5.0/
bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /nalan /usr

命令含义：运行 examples 包中的 wordcount 程序，输入目录为 HDFS 上的 /nalan，输出目录为 /usr。

注意

  • 输出目录不能事先存在 ，否则作业直接报错退出（可换一个新目录，或用 hadoop fs -rm -r 删除旧目录）；

  • 输入输出路径可按实际环境调整，课程配套案例文件中使用的是 wordcount /data/log /result。

Step 3：观察作业运行过程

提交后终端会持续打印作业进度（Running job、map/reduce 进度百分比），运行结束后输出计数器（Counters）信息，重点关注以下字段：

从计数器可以看到本次作业：Launched map tasks=1、Launched reduce tasks=1，Map input records=1551、Reduce output records=836 等，即 1551 行输入最终归并出 836 个单词。

6.5 结果查看

方式一：YARN Web UI（8088）

打开 http://主节点IP:8088/cluster，在 All Applications 列表中可以看到本次 word count 应用：Application Type 为 MAPREDUCE ，State 为 FINISHED ，FinalStatus 为 SUCCEEDED：

点击 Application ID 进入应用详情页，可查看启动时间、耗时、队列、AM 容器等信息：

方式二：命令行查看 HDFS 输出结果

复制代码 
# 查看输出目录
hadoop fs -ls /usr

# 查看统计结果（part-r-00000 为 reduce 输出文件）
hadoop fs -cat /usr/part-r-00000

每一行即"单词 \t 出现次数"。已开启日志聚集（见第四节 yarn.log-aggregation-enable 参数）时，还可在 19888 JobHistory 页面点击 Logs 查看完整任务日志。

6.6 实验验收与拓展练习

验收标准（全部满足为通过）：

  1. yarn application -list 中可见本次 wordcount 作业，状态 FINISHED / SUCCEEDED；

  2. Web UI 8088 页面能看到该应用记录；

  3. hadoop fs -cat /usr/part-r-00000 能输出正确的单词统计结果；

  4. 能口头说出作业提交后 RM、AM、NM、Container 之间的协作过程。

拓展练习：

  1. 换一个更大的文本文件重新运行，对比两次作业的 Map/Reduce 计数器差异；

  2. 用 yarn application -list -appTypes MAPREDUCE 和 -appStates 组合筛选作业；

  3. 修改 yarn.scheduler.maximum-allocation-mb 后重启 YARN，观察提交同一作业时 Container 分配资源的变化（实验后记得改回）；

  4. 将输出目录改为队列指定的路径（如 /result），再完整跑一遍流程。

附录A 常见问题排查

现象 可能原因 解决方法
执行 start-yarn.sh 后 8088 页面打不开 ResourceManager 未启动成功；防火墙未放行端口 jps 确认 RM 进程；查看 logs/yarn-*-resourcemanager-*.log；放行 8088 端口
主节点有 RM，但从节点 jps 看不到 NodeManager workers 文件配置有误；SSH 免密不通；从节点配置不一致 检查 workers（slaves）文件；逐台验证免密登录；比对各节点 yarn-site.xml
作业一直处于 ACCEPTED 状态不运行 集群可用资源不足，无法满足 Container 最低申请量 确认 NM 已注册（8088 Nodes 页面）；检查 yarn.nodemanager.resource.memory-mb 与 minimum-allocation 参数是否匹配
提交即报错：输出目录已存在 上一次运行的输出目录残留 hadoop fs -rm -r /usr 删除后重试，或更换输出目录
作业 FINISHED，但 19888 页面查不到记录 JobHistoryServer 未启动；未开启日志聚集 启动 mr-jobhistory-daemon.sh start historyserver；在 yarn-site.xml 开启 yarn.log-aggregation-enable
-kill 后作业状态仍是 RUNNING kill 请求已提交但 RM 尚未处理完成 稍等数秒后用 -status 复查，状态应变为 KILLED

以上排查以教师提供的集群环境为准，路径与端口请结合实际情况调整。

附录B 术语表

术语 含义
YARN Yet Another Resource Negotiator，Hadoop 的资源管理与任务调度系统
ResourceManager (RM) 全局资源管理器，负责 Job 之间资源的协调和仲裁
NodeManager (NM) 单个节点上的资源与任务管理代理
ApplicationMaster (AM) 每个应用专属的"管家"，负责申请资源、分配任务、监控生命周期
Container YARN 的资源分配单位，封装节点、内存、CPU 等任务运行资源
Scheduler RM 内部的调度器组件，常见有 CapacityScheduler 与 FairScheduler
FIFO 先进先出调度，按提交顺序分配资源
Capacity Scheduler 容量调度器，按队列划分集群容量，Apache 版默认
Fair Scheduler 公平调度器，按公平份额动态分配资源，CDH 版默认
JobHistoryServer 查看已完成 MR 作业历史日志的服务（19888 端口）
TimelineServer 通用的应用运行信息收集与检索服务，支持多种计算框架
wordcount MapReduce 经典示例程序，统计文本中每个单词出现的次数
相关推荐
buligbulig10 小时前
Hadoop正在失败？不，它正在壮大
大数据·hadoop·分布式
Sayai2 天前
Hadoop 集群安全加固实战：YARN 未授权访问漏洞修复，firewalld 白名单 + Nginx 反向代理 Basic Auth 全流程
运维·hadoop·nginx·安全·网络安全
IT小小猪2 天前
# Hadoop 3.3.6 完全分布式集群部署知识库
hadoop·分布式·eclipse
泡干脆面就番茄2 天前
Hive入门：架构解析与安装部署实录
大数据·数据仓库·hive·hadoop·架构
yyk333242 天前
Hive架构
hive·hadoop·架构
计算机编程指导师2 天前
计算机毕设选题：基于Spark+Django的水质多指标关联分析与可视化系统源码 毕业设计 选题推荐 数据分析 机器学习
大数据·hadoop·python·spark·毕业设计·课程设计·水质
计算机编程指导师2 天前
【大数据毕设】Hadoop+Spark台北市住宅价格数据可视化分析系统源码 毕业设计 选题推荐 毕设选题 数据分析 机器学习
大数据·hadoop·python·spark·毕业设计·课程设计·住宅价格
计算机编程指导师2 天前
【计算机毕设推荐】基于Hadoop+Spark的公共交通运营数据分析与可视化系统源码 毕业设计 选题推荐 毕设选题 数据分析 机器学习
大数据·hadoop·python·计算机·数据分析·spark·交通
计算机编程指导师2 天前
【计算机毕设选题推荐】基于Hadoop的宫颈癌变进程光谱数据分析系统源码 毕业设计 选题推荐 毕设选题 数据分析 机器学习
大数据·hadoop·python·数据分析·spark·毕业设计·宫颈癌变
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03GitHub 镜像站点04「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会05Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07Telegram APK 下载安装完整指南 — 2026年最新08微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新09几个好用的ip纯净度检测网站10轻量化AI渗透武器库｜ARTEX自主攻防系统、资产梳理、漏洞挖掘、链路分析全流程智能化落地