【YARN 权威指南】4. YARN 安装与配置

yarn

发布日期: 2025-01-15

文章字数: 7.4k

阅读时长: 28 分

阅读次数:

安装 YARN 不能只理解成“把 ResourceManager 和 NodeManager 启起来”。YARN 仍然依赖 HDFS 提供存储入口，依赖 MapReduce 配置验证计算链路，依赖 JobHistoryServer 和日志聚合保留任务运行证据。真正需要整理清楚的是：哪些配置决定服务能互相找到，哪些目录承载运行时数据，哪些验证能证明这个环境确实可以提交任务。

这次使用一台单节点测试服务器，把 HDFS、YARN、MapReduce 这条链路完整跑通。单机伪分布式的好处是变量少，适合把组件关系看清楚；缺点是无法充分暴露多节点环境里的网络、DNS、磁盘、权限、一致性和高可用问题。所以这篇文章只把它当成一个可以复现验证过程和截图的基础环境，而不是生产部署模板。环境基线如下：

项目	配置
Hadoop	Apache Hadoop 3.4.1
Java	OpenJDK 11
部署方式	单机伪分布式
安装目录	/opt/hadoop-3.4.1，软链 /opt/hadoop
数据目录	/data/hadoop
HDFS RPC	hdfs://localhost:9000
ResourceManager Web	0.0.0.0:8088
NameNode Web	9870
JobHistoryServer Web	19888

这不是生产部署方案。生产环境还需要独立用户、Kerberos、HA、TLS、监控告警和更完整的磁盘规划。

1. 安装边界与验证链路

1.1 安装 YARN 通常依赖 Hadoop 集群环境

YARN 不是孤立存在的。要运行 YARN，通常要先有一个 Hadoop 集群环境。HDFS 和 YARN 构成了 Hadoop 2 以后最核心的两条运行链路：

HDFS 负责分布式存储。
YARN 负责资源管理和任务调度。
MapReduce 作为 YARN 上的一种应用框架运行。

严格说，Hadoop 还包含 Hadoop Common、MapReduce 以及周边生态组件。这里把 HDFS 和 YARN 放在最前面，是因为安装验证时它们分别承担存储基础和资源调度基础。

这一点依然成立。更具体地看，Hadoop 集群可以按 Master、Worker 和 Auxiliary Service 三类角色拆开：

角色	主要服务	作用
Master 节点	NameNode、ResourceManager	负责 HDFS 元数据和 YARN 全局资源管理
Worker 节点	DataNode、NodeManager	负责存储数据块和运行 Container
Auxiliary Service	JobHistoryServer、WebAppProxy 等	负责历史任务、代理访问和辅助管理

在生产环境中，NameNode 和 ResourceManager 通常不会和普通 Worker 混在一起。集群部署时通常会把 NameNode 和 ResourceManager 作为 master 角色单独规划，剩余机器同时承担 DataNode 和 NodeManager 的职责。

从这个角度看，安装 YARN 的核心不是把程序包解压到机器上，而是把这些角色和机器关系定义清楚。

单机伪分布式环境只是把这些角色放到了一台机器上：

进程	单机环境中的角色
NameNode	管理 HDFS 命名空间
DataNode	存储 HDFS 数据块
SecondaryNameNode	辅助合并 NameNode 的 fsimage 和 edits
ResourceManager	管理 YARN 集群资源和应用生命周期
NodeManager	在本机启动和管理 Container
JobHistoryServer	展示 MapReduce 历史任务

因此，单机环境不是“只有一个 YARN 进程”，而是把 Hadoop 的关键服务全部跑在本机。理解这一点之后，后面的配置文件就比较容易对应到具体进程。

1.2 安装流程可以抽象成一条验证链路

Hadoop 2.x 时代的命令和发行版不适合直接照搬，但安装背后的顺序仍然有效。放到这次测试环境里，可以压缩成下面这条主线：

准备操作系统和用户
  -> 安装 Java 和 Hadoop
  -> 配置 HDFS/YARN/MapReduce
  -> 格式化 NameNode
  -> 启动 HDFS
  -> 启动 YARN
  -> 运行示例任务验证

这条链路仍然成立。变化的是版本选择、配置项、权限模型和生产要求。实际部署时，要确认 Java 版本、操作系统、Hadoop 包来源、Kerberos、HA、日志聚合和容量规划。

我把这条链路拆成三类检查：

版本检查	version check	Java 和 Hadoop 是否可用	java -version、hadoop version
服务检查	service check	HDFS/YARN 进程、节点注册和指标接口是否正常	jps、hdfs dfsadmin -report、yarn node -list、curl …/metrics
任务检查	job check	MapReduce 是否能通过 YARN 跑完	hadoop jar … pi、yarn application -list

只有第三类检查通过，才说明安装不是“进程启动了”，而是“最小计算链路跑通了”。它仍然不等于生产可用，只代表客户端、HDFS、YARN、Container、Shuffle、日志和历史服务之间的基础链路成立。

这三类检查也对应三类常见失败：version check 失败通常是 Java 或 Hadoop 环境变量不一致；service check 失败通常是进程没启动、目录权限不对或节点没有注册；job check 失败通常是资源不足、Shuffle 未启用、日志目录不可写或 JobHistory 配置不完整。

2. 核心配置文件

2.1 配置文件才是安装的重点

安装时最值得抓住的内容，是几个核心配置文件之间的关系：

core-site.xml
hdfs-site.xml
mapred-site.xml
yarn-site.xml

这些文件仍然是集群配置的主线。官方文档也把默认配置和站点配置分开：默认配置来自 core-default.xml、hdfs-default.xml、yarn-default.xml、mapred-default.xml，而用户自己的集群配置写在 etc/hadoop/core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml 中。

可以把它们理解成下面这样：

配置文件	管理对象	典型配置
core-site.xml	Hadoop 通用配置	fs.defaultFS、I/O 缓冲区、代理用户等
hdfs-site.xml	HDFS 服务	NameNode 元数据目录、DataNode 数据目录、副本数、块大小等
yarn-site.xml	YARN 服务	ResourceManager 地址、NodeManager 资源、日志聚合、Shuffle 服务等
mapred-site.xml	MapReduce on YARN	mapreduce.framework.name、Map/Reduce 内存、JobHistoryServer 等

可以把这几个配置文件之间的关系画成下面这样：

配置文件关系

这四个文件之间有一个简单的依赖顺序：

core-site.xml 先告诉客户端默认文件系统在哪里。
hdfs-site.xml 决定 NameNode 和 DataNode 如何存储数据。
yarn-site.xml 决定 ResourceManager、NodeManager 和 Container 如何工作。
mapred-site.xml 决定 MapReduce 是否把任务提交给 YARN。

如果只改 yarn-site.xml 而 HDFS 没有准备好，应用日志、任务输入输出、JobHistory 中间文件都会出问题。如果只改 mapred-site.xml 而没有启用 NodeManager 的 Shuffle 服务，MapReduce 任务也可能提交成功但运行失败。

2.2 core-site.xml：先确定 HDFS 入口

core-site.xml 中最关键的是 fs.defaultFS。它告诉 Hadoop 客户端默认访问哪个文件系统。

单节点或测试环境里，通常会看到类似这样的配置：

<property>
  <name>fs.defaultFS</name>
  <value>hdfs://localhost:9000</value>
</property>

这意味着当我们执行：

hdfs dfs -ls /

客户端会默认访问 hdfs://localhost:9000/。

这个配置看起来简单，但它决定了后续 HDFS、YARN 和 MapReduce 命令默认访问的文件系统入口。很多初学者会把 HDFS 命令、YARN 命令、MapReduce 命令混在一起，但实际执行链路里，所有计算任务都离不开文件系统入口。MapReduce 示例 jar、任务输入、任务输出、JobHistory 中间目录，最终都需要落到 HDFS 上。

所以安装 YARN 时，第一件事不是启动 ResourceManager，而是先让 Hadoop 客户端知道 HDFS 在哪里。

这次测试环境里的 core-site.xml 还配置了 hadoop.tmp.dir：

<property>
  <name>hadoop.tmp.dir</name>
  <value>/data/hadoop/tmp</value>
</property>

这个目录会被多个组件使用。单机环境里把它放到 /data/hadoop/tmp，可以避免临时数据散落在系统默认临时目录中。生产环境里还要继续拆分 NameNode、DataNode、NodeManager 本地目录，不能把所有数据都堆到一个路径里。

core-site.xml 还有一个容易被忽略的作用：它不只被服务端读取，也会被 Hadoop 客户端读取。客户端提交任务时，会加载本机的 Hadoop 配置，再决定把输入、输出、临时文件和任务信息写到哪里。也就是说，服务端配置正确但客户端配置不一致，仍然可能出现任务提交失败、输出目录写错、日志目录找不到的问题。单机环境里客户端和服务端在一台机器上，这个问题不明显；多节点或运维机提交任务时，客户端配置一致性就会变成必须检查的内容。

安装完成后，我通常会用两个命令确认 core-site.xml 没有跑偏：

hdfs getconf -confKey fs.defaultFS
hdfs dfs -ls /

前一个命令检查配置解析结果，后一个命令检查客户端是否真的能连上 HDFS。只看 XML 文件内容不够，因为 Hadoop 最终读取的是合并后的配置，环境变量、配置目录和启动用户都可能影响实际结果。

2.3 hdfs-site.xml：定义 NameNode 和 DataNode 如何存储数据

hdfs-site.xml 负责 HDFS 自身配置，重点是 NameNode 和 DataNode 的本地目录。

至少要关注：

配置项	作用
dfs.namenode.name.dir	NameNode 存储元数据和 edit log 的本地目录
dfs.datanode.data.dir	DataNode 存储数据块的本地目录
dfs.replication	HDFS 默认副本数
dfs.blocksize	HDFS 文件块大小

这里最容易踩坑的是目录规划。NameNode 的元数据目录最好有冗余，DataNode 的数据目录通常应该分布到多块独立磁盘上，而不是全部写到系统盘。

单机环境里使用了下面这组最小配置：

<property>
  <name>dfs.replication</name>
  <value>1</value>
</property>
<property>
  <name>dfs.namenode.name.dir</name>
  <value>file:///data/hadoop/namenode</value>
</property>
<property>
  <name>dfs.datanode.data.dir</name>
  <value>file:///data/hadoop/datanode</value>
</property>

dfs.replication=1 只适合单机环境。因为只有一个 DataNode，如果仍然使用默认副本数 3，HDFS 会一直有欠副本块。生产环境里副本数应该根据节点数量、磁盘容量和容灾要求设置。

dfs.namenode.name.dir 和 dfs.datanode.data.dir 都使用 file:// 前缀，表示这些目录是本地文件系统路径。NameNode 目录保存的是元数据，不是业务数据块；DataNode 目录保存的是实际 block。两者混在一起会增加排查难度。

安装脚本可以帮我们创建目录，但生产环境不能只依赖脚本默认值。安装之前就应该明确：

哪些目录用于 NameNode 元数据。
哪些目录用于 DataNode 数据块。
目录权限属于哪个用户。
磁盘满了以后是否会影响系统盘。

这一层没有处理好，后面 YARN 能正常启动，也只是表面正常。

首次启动 HDFS 前还需要格式化 NameNode：

hdfs namenode -format

这一步只应该在初始化集群时执行。已经有数据的集群不能随手格式化，否则会破坏 NameNode 元数据。单机环境里可以重建，但生产环境必须把它当成高风险操作。

这里还要补一个安装阶段非常实际的检查：HDFS 是否已经退出 safemode。NameNode 刚启动时会进入 safemode，等待 DataNode 上报 block 状态。单机环境里这个过程通常很快，但如果 DataNode 没有启动、数据目录权限不对、磁盘不可写，NameNode 页面可能能打开，HDFS 写入却不能正常进行。

hdfs dfsadmin -safemode get
hdfs dfsadmin -report

dfsadmin -report 比 Web 页面更适合放进安装脚本的验证流程里。它能直接看到 Live DataNode 数量、磁盘容量、DFS Used、Non DFS Used、Configured Capacity 等信息。对单机环境来说，Live DataNode 至少要是 1；对多节点环境来说，这个数字应该和规划的 DataNode 数量一致。否则后面启动 YARN 没有意义，因为计算任务即使能申请到 Container，也没有可靠的 HDFS 输入输出基础。

2.4 yarn-site.xml：YARN 的核心配置入口

yarn-site.xml 是安装 YARN 时最关键的配置文件。

ResourceManager 地址、NodeManager 地址、Shuffle 服务这些配置仍然是基础项，只是生产配置项更多。

最基本的 YARN 配置可以分为几类：

配置类别	典型配置	说明
ResourceManager 地址	yarn.resourcemanager.hostname、yarn.resourcemanager.address	客户端、AM、NM 都要知道 RM 在哪里
调度器配置	yarn.resourcemanager.scheduler.class	指定 FIFO、Capacity、Fair 等调度器
NodeManager 资源	yarn.nodemanager.resource.memory-mb、yarn.nodemanager.resource.cpu-vcores	声明单个节点可提供给 Container 的资源
本地目录	yarn.nodemanager.local-dirs、yarn.nodemanager.log-dirs	存放中间文件和本地日志
日志聚合	yarn.log-aggregation-enable、yarn.nodemanager.remote-app-log-dir	决定应用结束后日志是否从 NodeManager 本地汇总到 HDFS
MapReduce Shuffle	yarn.nodemanager.aux-services	运行 MapReduce 时需要启用 mapreduce_shuffle aux-service

从安装角度看，最小配置只要能把 ResourceManager 和 NodeManager 拉起来。但从生产角度看，更应该先确认下面几个问题：

ResourceManager 是否需要 HA。
NodeManager 能给 Container 分配多少内存和 CPU。
本地目录是否放在独立数据盘。
是否启用日志聚合。
是否需要 Node Labels、GPU、自定义资源等 Hadoop 3.x 能力。

这些能力不是安装阶段都要展开，但在规划集群时需要提前知道它们的存在。

这次测试环境里的关键配置如下：

<property>
  <name>yarn.resourcemanager.hostname</name>
  <value>localhost</value>
</property>
<property>
  <name>yarn.nodemanager.aux-services</name>
  <value>mapreduce_shuffle</value>
</property>
<property>
  <name>yarn.nodemanager.resource.memory-mb</name>
  <value>12288</value>
</property>
<property>
  <name>yarn.nodemanager.resource.cpu-vcores</name>
  <value>4</value>
</property>

yarn.resourcemanager.hostname=localhost 是单机环境的写法。多节点环境不能这么配，否则其它节点会把 ResourceManager 理解成自己本机。

mapreduce_shuffle 对 MapReduce 很关键。它是 NodeManager 的 aux-service，不是一个独立守护进程。Map 阶段输出的数据需要被 Reduce 阶段拉取，如果 NodeManager 没有启用这个辅助服务，很多 MapReduce 作业会在 Shuffle 阶段失败。

yarn.nodemanager.resource.memory-mb 和 yarn.nodemanager.resource.cpu-vcores 表示这个 NodeManager 愿意提供给 YARN Container 的资源上限。测试服务器是 4 核、15 GiB 内存，所以这里给 YARN 12 GiB 和 4 个 vCore，给系统和 Hadoop 守护进程留出一部分空间。

为了能在任务结束后查看日志，还启用了日志聚合：

<property>
  <name>yarn.log-aggregation-enable</name>
  <value>true</value>
</property>
<property>
  <name>yarn.nodemanager.remote-app-log-dir</name>
  <value>/tmp/logs</value>
</property>

日志聚合启用后，应用结束时 NodeManager 会把本地日志汇总到 HDFS，而不是只保留在 NodeManager 本地。后面用 yarn logs -applicationId … 查看日志时，就依赖这条链路。

NodeManager 的资源配置也不能照搬物理机参数。yarn.nodemanager.resource.memory-mb 表示 YARN 可以拿来分给 Container 的内存，不是服务器总内存。NameNode、DataNode、ResourceManager、NodeManager、JobHistoryServer、系统进程都要消耗内存。如果把 15 GiB 机器直接配置成 15 GiB 都交给 YARN，小任务可能看不出问题，稍微多跑几个 Container 就会挤压守护进程和系统缓存。

Container 资源还要和 MapReduce 配置匹配。例如 mapreduce.map.memory.mb=1024、mapreduce.reduce.memory.mb=1024 时，12 GiB 的 NodeManager 资源可以同时承载多个小任务；如果任务把 Map 或 Reduce 内存调到 8 GiB，单节点环境就只能同时运行很少的 Container。安装阶段至少要确认两件事：YARN 声明的节点资源符合机器实际能力，MapReduce 默认任务资源不会超过 YARN 的最小和最大分配限制。否则任务提交阶段看起来正常，真正调度时会一直 Pending 或直接失败。

2.5 mapred-site.xml：让 MapReduce 跑在 YARN 上

YARN 是资源管理系统，不等于 MapReduce。MapReduce 要跑在 YARN 上，需要在 mapred-site.xml 中指定运行框架：

<property>
  <name>mapreduce.framework.name</name>
  <value>yarn</value>
</property>

这个配置非常关键。它说明 MapReduce 作业不再由 Hadoop 1 时代的 JobTracker/TaskTracker 管理，而是提交给 YARN，由 ResourceManager 分配资源，由 NodeManager 启动 Container。

如果要运行 MapReduce 示例，还需要关注：

配置项	说明
mapreduce.map.memory.mb	Map Task 申请的 Container 内存
mapreduce.map.java.opts	Map Task JVM 参数
mapreduce.reduce.memory.mb	Reduce Task 申请的 Container 内存
mapreduce.reduce.java.opts	Reduce Task JVM 参数
mapreduce.jobhistory.address	JobHistoryServer RPC 地址
mapreduce.jobhistory.webapp.address	JobHistoryServer Web 地址

这也是为什么安装验证常用 pi、terasort 这类 MapReduce 示例。它们不仅验证 MapReduce，更是在验证 HDFS、YARN、NodeManager Shuffle、JobHistory 这些链路是否能串起来。

这次测试环境里还配置了 JobHistoryServer：

<property>
  <name>mapreduce.jobhistory.address</name>
  <value>localhost:10020</value>
</property>
<property>
  <name>mapreduce.jobhistory.webapp.address</name>
  <value>0.0.0.0:19888</value>
</property>

mapreduce.jobhistory.address 是客户端和服务之间的 RPC 地址，mapreduce.jobhistory.webapp.address 是浏览器访问的 Web 地址。两者不是同一个端口。

Hadoop 3.x 的 MapReduce 示例在某些环境里还需要显式传递 HADOOP_MAPRED_HOME，否则可能出现 MRAppMaster 找不到的错误。测试环境里通过下面三个配置让 ApplicationMaster、Map Task、Reduce Task 都能拿到正确路径：

<property>
  <name>yarn.app.mapreduce.am.env</name>
  <value>HADOOP_MAPRED_HOME=/opt/hadoop</value>
</property>
<property>
  <name>mapreduce.map.env</name>
  <value>HADOOP_MAPRED_HOME=/opt/hadoop</value>
</property>
<property>
  <name>mapreduce.reduce.env</name>
  <value>HADOOP_MAPRED_HOME=/opt/hadoop</value>
</property>

这个问题很适合作为安装验证的一部分：如果 Pi 示例提交后很快失败，不要只看 ResourceManager 页面上的 FAILED，应该继续看 ApplicationMaster 日志和 yarn logs 输出。

MapReduce 配置还有一个细节：ApplicationMaster 本身也是一个 YARN Container。它不是 ResourceManager 的内部线程，也不是 NodeManager 的固定进程。客户端提交作业后，ResourceManager 会先为 ApplicationMaster 分配 Container，然后 ApplicationMaster 再向 ResourceManager 申请 Map 和 Reduce 任务所需的 Container。理解这一点后，mapred-site.xml 中关于 AM、Map、Reduce 的配置就不会混成一团。

安装验证时如果出现任务长时间处于 ACCEPTED，一般要看队列和资源；如果进入 RUNNING 后失败，一般要看 ApplicationMaster 和任务日志；如果任务完成但 JobHistory 页面看不到，一般要看 JobHistoryServer 配置和历史目录。也就是说，同样是“Pi 示例没跑好”，背后可能是三类完全不同的问题，不能只用重启服务解决。

3. 启动和安装验证

3.1 启动顺序：先 HDFS，再 YARN

按组件关系看，启动顺序应该是：

# 1. 首次启动前格式化 NameNode
hdfs namenode -format

# 2. 启动 HDFS
start-dfs.sh

# 3. 启动 YARN
start-yarn.sh

# 4. 如果需要运行 MapReduce，启动 JobHistoryServer
mapred --daemon start historyserver

实际生产环境中可能会使用 systemd、发行版管理工具、Kubernetes、CM 或其他集群管理平台来托管这些进程。命令入口会变，但依赖顺序不变。

启动后最直接的进程检查是 jps。单机环境正常时至少应该看到：

NameNode
DataNode
SecondaryNameNode
ResourceManager
NodeManager
JobHistoryServer

只看 jps 还不够，但它可以快速判断服务有没有启动错层。例如只有 ResourceManager 没有 NodeManager，YARN 页面可能能打开，但没有节点可以运行 Container；只有 NameNode 没有 DataNode，HDFS 也不能真正存储数据。

这里有一个判断标准：如果 HDFS 没有正常运行，YARN 即使能启动，很多任务也跑不完整。因为应用 jar、输入输出路径、日志聚合目录、JobHistory 目录都可能依赖 HDFS。

启动顺序背后的原则是依赖关系，而不是命令习惯。HDFS 先起来，是因为后续应用需要文件系统；YARN 再起来，是因为 NodeManager 注册时要向 ResourceManager 汇报节点资源；JobHistoryServer 最后启动，是因为它只负责已完成作业的历史信息。单机环境里几个服务都在一台机器上，启动失败时容易直接看日志；多节点环境里更应该把启动检查拆成脚本化的步骤，每一步只判断一个对象。

我会把启动后的第一轮检查固定成下面几项：

检查项	目标
jps	快速确认本机进程是否存在
hdfs dfsadmin -report	确认 DataNode 是否注册
yarn node -list	确认 NodeManager 是否注册
curl http://localhost:8088/ws/v1/cluster/metrics	确认 RM 指标接口可用
mapred –daemon status historyserver	确认历史服务状态

这些检查分别覆盖进程、HDFS 节点、YARN 节点、指标接口和历史服务。jps 只能作为快速检查，更可靠的验收还要结合 Web UI、REST API、节点注册状态和一次真实作业结果。比起只看某个 Web 页面，这组检查更容易发现链路里的具体断点。

下面是单机伪分布式环境里的 NameNode 页面。这里能看到 Hadoop 版本是 3.4.1，NameNode 处于 active 状态，HDFS 容量、Live Nodes 和 Safemode 状态都可以从这个页面确认。

NameNode Overview 页面，NameNode 处于 active 状态

3.2 验证安装：不要只看进程

安装验证不能只看 jps 里有没有进程。至少要验证 HDFS、YARN 和 MapReduce 示例任务都能跑通。

最小验证可以分成三层：

# 1. 看 HDFS 是否可用
hdfs dfs -ls /

# 2. 看 YARN 是否可用
yarn node -list
yarn application -list

# 3. 提交一个 MapReduce 示例任务
hadoop jar \
  $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \
  pi 16 10000

如果示例任务能成功完成，至少说明最小可运行链路成立：

客户端能访问 HDFS。
ResourceManager 能接收应用。
NodeManager 能启动 Container。
MapReduce Shuffle 服务可用。
应用日志和历史信息可以被追踪。

这次测试环境里，yarn node -list 的结果显示只有一个运行中的 NodeManager：

Total Nodes:1
Node-State: RUNNING
Node-Http-Address: lavm-bzoq5mwl1h:8042

hdfs dfsadmin -report 则显示一个 Live DataNode，容量约 99.89 GB。对单机伪分布式环境来说，这两个结果就能证明 HDFS 和 YARN 的最小节点链路已经成立。

yarn node -list 里最值得关注的是节点状态。常见状态包括 NEW、RUNNING、UNHEALTHY、DECOMMISSIONED 和 LOST。安装验证阶段至少要看到目标 NodeManager 进入 RUNNING；如果是 UNHEALTHY，通常要继续检查磁盘目录、健康检查脚本和 NodeManager 日志。

然后运行 Pi 示例：

hadoop jar \
  $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.4.1.jar \
  pi 4 1000

任务完成后，YARN 应用列表里可以看到：

application_1736923000325_0001
QuasiMonteCarlo
MAPREDUCE
FINISHED
SUCCEEDED

这里最重要的不是 Pi 结果本身，而是 FINISHED / SUCCEEDED 这两个状态。它说明 ResourceManager 接收了应用，NodeManager 启动了 Container，MapReduce ApplicationMaster 正常完成了作业，JobHistoryServer 也能追踪历史记录。不过它只能证明基础链路成立，不能代表队列隔离、HA、安全、容量规划和长期稳定性都已经满足生产要求。

一次正常提交大致会经历下面的状态流转：

NEW -> ACCEPTED -> RUNNING -> FINISHED

ACCEPTED 表示应用已提交并等待资源；RUNNING 表示 ApplicationMaster 或任务 Container 已经开始运行；FINISHED 表示应用完成。最终是否成功，还要结合 SUCCEEDED、FAILED 或 KILLED 这类最终状态一起看。

在 ResourceManager 页面里，最直观的验证点是应用列表和集群指标。下面这张图来自单机伪分布式环境，QuasiMonteCarlo 是通过 pi 示例提交的 MapReduce 作业，状态是 FINISHED / SUCCEEDED。

ResourceManager 应用列表页面，展示 MapReduce 示例任务状态

如果启动了 JobHistoryServer，还可以在历史页面里继续查看已完成作业。这个页面比 ResourceManager 当前应用列表更适合放在文章里做验证截图，因为它直接展示 Submit Time、Start Time、Finish Time、Job ID、用户、队列和任务状态。

JobHistory 作业列表页面，展示 MapReduce 示例任务记录

验证阶段最容易犯的错误，是把某一个点的成功当成整体成功。NameNode 页面正常，只能说明 HDFS 管理入口可访问；ResourceManager 页面正常，只能说明 RM 进程可访问；yarn application -list 有记录，只能说明应用被提交过。一个可用的 YARN 环境至少要同时满足下面几个条件：

HDFS 能写入和读取文件。
NodeManager 在 ResourceManager 中处于 RUNNING。
YARN 能分配 Container。
MapReduce ApplicationMaster 能启动。
Shuffle 服务能支撑 Reduce 阶段。
应用结束后日志可以通过 yarn logs 读取。
JobHistoryServer 能展示已完成作业。

这也是为什么我更愿意用 MapReduce 示例作为安装验收，而不是只提交一个空任务。Pi 示例规模很小，但它会经过提交、调度、AM 启动、Map/Reduce 执行、Shuffle、日志聚合和历史记录这些环节。只要其中一个环节配置错误，通常都会暴露出来。但它仍然只是最小验证任务，不代表生产负载、并发压力和长时间运行都没有问题。

4. 安装工具和实践判断

4.1 图形化安装工具留下的启发

Ambari/HDP 这条安装链路不适合作为这次测试环境的默认选择，但它提醒我一件事：图形化安装工具真正做的不是“点下一步”，而是把一组容易出错的集群操作标准化。

检查机器环境。
分发安装包。
生成 Hadoop 配置文件。
分配 NameNode、ResourceManager、DataNode、NodeManager 等角色。
启动服务并检查健康状态。
提供指标、日志和告警入口。

换句话说，工具会变，但它封装的这些动作仍然是安装和运维 Hadoop/YARN 时必须处理的问题。部署工具会迭代，配置模型的稳定性通常高于具体工具。

ResourceManager 除了 Web 页面，也提供 REST API。安装验证阶段可以直接查看 /ws/v1/cluster/metrics，它会返回应用数量、节点数量、Container、内存、vCore 等关键指标。更完整的监控还应该把 YARN 自带 Web UI、REST API、Timeline Service、日志聚合，以及外部监控系统结合起来看，而不是依赖某一个旧版管理平台。

4.2 这次安装给我的几个判断

围绕这次安装，可以得出几个判断。

第一，安装步骤会变化，但组件关系相对稳定。

具体安装命令和安装平台会变化，但 HDFS、YARN、MapReduce 三者之间的关系仍然是理解 Hadoop 集群的基础。

第二，配置文件比安装工具更重要。

无论是脚本安装、包管理安装，还是图形化平台安装，最终都要落到 core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml 这些配置上。只要理解这些文件分别控制什么，换一种安装方式也不会迷路。

第三，生产安装不能只追求“能启动”。

学习环境可以先追求跑通链路，生产环境还要考虑：

Kerberos 安全认证。
NameNode HA 和 ResourceManager HA。
日志聚合和日志保留。
队列与多租户权限。
NodeManager 健康检查。
监控、告警和容量规划。
GPU、节点标签、自定义资源等 Hadoop 3.x 能力。

这些内容不应该塞进安装过程全部讲完，但安装时必须提前规划。

第四，单机配置不能直接复制到多节点。

单机伪分布式常见的 localhost、单目录、单副本、root 用户运行，都是为了降低验证成本。多节点环境里至少要调整主机名、RPC 地址、Web 地址、HDFS 副本数、DataNode 数据目录、NodeManager 本地目录和服务用户。尤其是 localhost，它在单机环境里非常方便，在多节点环境里却是典型故障源。

第五，安装文档应该保留验证证据。

只记录命令不够，最好同时记录版本、配置、端口、进程、Web 页面和一次成功任务的 ID。后面排查问题时，这些信息可以作为基线。比如这次环境里的 application_1736923000325_0001 和 job_1736923000325_0001，就能把 ResourceManager、JobHistoryServer、日志聚合和截图串到同一个验证对象上。

第六，YARN 配置要和机器资源一起看。

调大 yarn.nodemanager.resource.memory-mb 并不会凭空增加服务器内存；调高 MapReduce 任务内存也不会自动提升性能。资源配置的作用是告诉调度器如何分配，而不是替代容量规划。安装阶段应该先用保守值跑通链路，再根据任务类型、并发量和机器资源逐步调整。