Hadoop YARN（Yet Another Resource Negotiator）是 Hadoop 2.0 引入的核心组件，被称为“大数据的操作系统”。它的主要作用是将“资源管理”和“任务调度”分离开来，使得同一个集群可以同时运行 MapReduce、Spark、Flink 等多种计算框架。

为了让你通俗易懂地理解，我们将从整体架构组件和基本运行机制（工作流程）两个方面来详细讲解，并辅以一个“公司项目外包”的通俗比喻。

---

一、 YARN 的整体架构图及核心组件

YARN 采用的是经典的 Master/Slave（主从）架构。

(你可以按这个结构在脑海中构建一张图：最上面是 Client（客户端），中间是全局唯一的 Master（ResourceManager），下面是分布在各个机器上的 Slave（NodeManager），而每个应用程序都有自己的项目经理（ApplicationMaster）)

1. 核心组件详解

• ResourceManager (RM - 资源管理器)
  • 角色定位：集群的“大总管”（Master），全局唯一（生产环境中会有高可用 HA 备用节点）。
  • 主要职责：负责整个集群资源的统一管理和分配。它包含两个核心组件：
    • 调度器 (Scheduler)：纯粹的资源分配器，不关心应用程序的具体工作，只根据容量、队列等策略将资源分配给各个应用。
    • 应用程序管理器 (ApplicationsManager)：负责接收客户端请求，为应用分配第一个 Container 用来启动 ApplicationMaster，并监控其运行状态。
• NodeManager (NM - 节点管理器)
  • 角色定位：单台服务器的“部门经理”（Slave），每个节点一个。
  • 主要职责：
    • 定时向 RM 汇报本节点的资源使用情况和各个 Container 的运行状态。
    • 接收并处理来自 ApplicationMaster 的启动/停止 Container 的请求。
    • 监控 Container 的资源（CPU、内存）使用，一旦超标就将其杀死（Kill）。
• ApplicationMaster (AM - 应用主控)
  • 角色定位：单个任务的“项目经理”。每个提交到 YARN 的应用程序（如一个 MapReduce 作业或一个 Spark 任务）都会生成一个独占的 AM。
  • 主要职责：
    • 负责应用程序的管理。
    • 向 RM 申请资源（要多少 CPU 和内存）。
    • 拿到资源后，跟 NM 通信，要求在对应的节点上启动任务。
    • 监控任务的执行状态和进度，任务失败时负责重启任务。
• Container (容器)
  • 角色定位：资源的抽象单位（类似于“工位”或“办公室”）。
  • 说明：它是 YARN 中资源分配的基本单位，封装了内存、CPU、磁盘、网络等资源。所有的任务（包括 AM 本身）都是在 Container 中运行的。

---

二、 YARN 的基本运行机制（工作流程）

当用户向 YARN 提交一个计算任务时，整个过程经历了以下几个步骤。

💡 通俗比喻前提：

• RM = 公司总部的资源调配局（管所有工位和设备）。
• NM = 各个分公司的行政主管（管本分公司的工位）。
• AM = 具体的项目经理。
• Container = 包含电脑和办公桌的“工位”。

完整运行流程（7 个步骤）：

1. 作业提交 (Submit Application)
   • 客户端（Client）向 ResourceManager（RM）提交应用程序（比如一个 MapReduce 程序），其中包括程序代码、启动 AM 的命令等。
   • 比喻：客户带着项目来到总部，要求立项。
2. 启动应用主控 (Start ApplicationMaster)
   • RM 接收到请求后，在其内部的“应用程序管理器”中注册该应用。
   • RM 找一台相对空闲的 NodeManager（NM），分配第一个 Container，并指令该 NM 在这个 Container 中启动该任务的 ApplicationMaster（AM）。
   • 比喻：总部批准立项，在某个分公司划出一个工位，任命并入驻了这个项目的“项目经理”。
3. AM 注册 (Register)
   • AM 启动后，第一件事就是向 RM 注册自己。这样客户端就可以直接通过 RM 查询到 AM 的位置，从而查看任务运行状态。
   • 比喻：项目经理向总部打卡报到，留下联系方式。
4. 申请资源 (Negotiate Resources)
   • AM 根据任务的需求（比如需要 10 个 Map 任务，5 个 Reduce 任务），通过心跳机制向 RM 的“调度器”申请所需批量的 Container 资源。
   • 比喻：项目经理评估后发现需要 15 个程序员，于是向总部的资源调配局提交《资源申请单》。
5. 分配资源并启动任务 (Launch Task)
   • RM 根据集群资源情况，将 Container 分配给 AM（告诉 AM：节点 A 有 3 个工位，节点 B 有 5 个工位...）。
   • AM 拿到资源列表后，直接与对应的 NodeManager 通信，要求 NM 启动 Container 并执行具体的计算任务。
   • 比喻：总部批复了工位。项目经理直接跑到对应的分公司，让行政主管（NM）安排程序员在分配好的工位上开始干活。
6. 任务监控与执行 (Monitor & Execute)
   • 各个 Container 中运行着具体的任务。在运行期间，这些任务会通过 RPC 协议向自己的 AM 汇报进度和状态。如果某个任务失败，AM 会向 RM 重新申请资源重启该任务。
   • （注意：此时 NM 只是在监控 Container 是否使用了过多的内存/CPU，并向 RM 汇报节点健康状况，NM 不关心任务具体的业务逻辑）。
   • 比喻：程序员向项目经理汇报工作进度；分公司行政主管只盯着程序员是不是用了太多的公司电费，如果违规就拔电源。
7. 作业完成与资源回收 (Finish & Unregister)
   • 当所有任务执行完毕，AM 向 RM 报告任务完成，并注销自己。
   • RM 收到通知后，回收 AM 占用的 Container，整个应用程序运行结束。
   • 比喻：项目做完了，项目经理向总部汇报结项，交还所有工位，团队解散。

三、 总结：为什么 YARN 这么设计？

1. 高并发与减轻主节点压力：以前的 Hadoop 1.x 中，JobTracker 既要管资源又要管每个任务的进度，很容易崩溃。YARN 引入了 ApplicationMaster，把任务监控的压力分散到了各个节点上。RM 现在只管“批地（分配资源）”，不管“盖楼（任务执行）”。
2. 多框架支持：YARN 是一套纯粹的资源管理系统，只要符合 YARN 规范，MapReduce、Spark、Flink 等框架都可以作为不同的 ApplicationMaster 运行在 YARN 上，实现了“一个集群，多种计算”，极大地提高了集群资源的利用率。