【Hadoop】Hadoop核心基础——YARN 框架架构与运行机制（Hadoop 集群的 “资源管家”）
目录
一、先搞懂：为什么需要 YARN？Hadoop 1.x 的痛点
1. 单点瓶颈
2. 资源利用率低
3. 生态封闭
二、YARN 的核心架构：4 大组件各司其职
1. 核心组件 1：ResourceManager（RM）—— 集群的 “大管家”
2. 核心组件 2：NodeManager（NM）—— 单个节点的 “管理员”
3. 核心组件 3：ApplicationMaster（AM）—— 单个应用的 “指挥官”
4. 核心组件 4：Container—— 资源分配的 “最小单位”
三、YARN 运行全流程：一个 MapReduce 任务如何在 YARN 上运行？
步骤 1：客户端提交应用
步骤 2：ResourceManager 启动 ApplicationMaster
步骤 3：ApplicationMaster 注册并申请资源
步骤 4：ResourceManager 调度资源并分配 Container
步骤 5：ApplicationMaster 启动任务 Container
步骤 6：任务执行并汇报进度
步骤 7：应用完成，释放资源
步骤 8：ResourceManager 清理并反馈结果
四、YARN 与 Hadoop 1.x 的核心差异：从 “封闭” 到 “开放”
五、YARN 的核心优势与典型应用场景
1. 核心优势
2. 典型应用场景
六、总结与下期预告
上一期我们拆解了 MapReduce 的分布式计算逻辑，而支撑 MapReduce（以及 Spark、Flink 等计算框架）稳定运行的核心，正是 Hadoop 2.0 引入的 YARN 框架。如果说 HDFS 是 Hadoop 的 “存储基石”，MapReduce 是 “计算引擎”，那 YARN 就是 “资源调度中枢”—— 它解决了 Hadoop 1.x 的核心痛点，让集群资源实现高效、灵活的统一管理。这篇文章就带大家搞懂 YARN 的设计初衷、核心架构和运行流程，明白它为什么能成为 Hadoop 生态的 “资源管家”。
一、先搞懂：为什么需要 YARN？Hadoop 1.x 的痛点
在 Hadoop 1.x 中，并没有 YARN 框架 ——MapReduce 的 “资源管理” 和 “任务调度” 全由一个叫 “JobTracker” 的组件负责。这种架构在小规模集群（几十台节点）中没问题，但随着集群规模扩大到几百、几千台，就会暴露三个致命痛点：
1. 单点瓶颈
JobTracker 既要管理集群的 CPU、内存等资源，又要监控成千上万的 Map/Reduce 任务、处理任务失败重试 —— 相当于 “一个人又当管理员又当执行者”。当集群节点增多、任务量增大时，JobTracker 的内存、CPU 会成为瓶颈，导致整个集群性能下降甚至崩溃。
2. 资源利用率低
Hadoop 1.x 的资源分配是 “静态分区”—— 集群资源被划分为固定数量的 “Slot（槽位）”，Map 任务和 Reduce 任务各占一部分 Slot。如果当前只有 Map 任务需要运行，Reduce Slot 会闲置；反之亦然，资源无法动态调配，造成大量浪费。
3. 生态封闭
Hadoop 1.x 的资源管理和 MapReduce 深度绑定，只能运行 MapReduce 任务。而随着大数据技术发展，Spark、Flink 等更高效的计算框架出现，但这些框架无法复用 Hadoop 1.x 的集群资源，导致企业需要维护多套集群，增加了运维成本。
为了解决这些问题，Hadoop 2.0 引入了 YARN 框架 —— 它的核心思路是 “解耦”：把 JobTracker 的 “资源管理” 和 “任务调度” 拆分成两个独立服务，同时支持多计算框架共享集群资源。这一改造让 Hadoop 从 “单一计算框架” 升级为 “分布式计算平台”。
二、YARN 的核心架构：4 大组件各司其职
YARN 采用 “Master/Slave” 主从架构，核心由 1 个全局资源管理器（ResourceManager）、多个节点资源管理器（NodeManager）、每个任务对应的应用管理器（ApplicationMaster），以及资源分配单位（Container）组成。这四个组件协同工作，实现 “资源统一管理、任务分布式执行”。
1. 核心组件 1：ResourceManager（RM）—— 集群的 “大管家”
ResourceManager 是 YARN 的 “全局主节点”，运行在集群的某一台服务器上（通常与 HDFS 的 NameNode 部署在不同节点，避免单点故障），核心职责是 “管全局资源、做调度决策”，不参与具体任务的执行和监控。
它包含两个关键子组件：
- 调度器（Scheduler）：纯资源调度组件，根据集群资源策略（如容量、公平），将 CPU、内存等资源分配给各个应用（如 MapReduce 任务、Spark 任务）。调度器只负责 “分配资源”，不关心任务的执行状态（如任务是否失败、是否需要重试）。
- 常见调度策略：YARN 默认提供 “容量调度器（Capacity Scheduler）” 和 “公平调度器（Fair Scheduler）”—— 前者适合多团队共享集群（按比例分配资源），后者适合单团队（资源公平分配给所有任务）。
- 应用程序管理器（Applications Manager）：负责管理整个集群的应用生命周期 —— 接收客户端提交的应用、为应用启动第一个 Container 来运行 ApplicationMaster、监控 ApplicationMaster 的状态（如果 AM 失败，会重新启动）、接收应用完成的通知并清理资源。
2. 核心组件 2：NodeManager（NM）—— 单个节点的 “管理员”
NodeManager 是 YARN 的 “从节点组件”，运行在集群的每一台服务器上（与 HDFS 的 DataNode 部署在同一节点），核心职责是 “管理本节点资源、执行具体任务”。
它的核心工作：
- 资源管理：监控本节点的 CPU、内存、磁盘、网络等资源使用情况，定期（每秒）向 ResourceManager 汇报 “心跳”，告知当前节点的资源剩余和任务运行状态。
- 容器管理：根据 ApplicationMaster 的请求，在本节点启动 / 停止 “Container（容器）”——Container 是 YARN 的资源分配单位，封装了 CPU 核心数、内存大小等资源，任务只能在 Container 中运行，避免资源抢占。
- 任务监控：监控 Container 的运行状态，若 Container 失败或超时，会向 ApplicationMaster 和 ResourceManager 汇报，以便进行故障处理。
3. 核心组件 3：ApplicationMaster（AM）—— 单个应用的 “指挥官”
ApplicationMaster 是 “每个应用独有的任务管理器”—— 用户提交的每个应用（如一个 MapReduce 任务、一个 Spark 作业），都会对应一个 ApplicationMaster。它运行在集群的某个 Container 中，核心职责是 “为当前应用申请资源、调度任务执行、监控任务状态”。
以 MapReduce 应用为例，其 ApplicationMaster 称为 “MRAppMaster”，具体工作包括：
- 资源申请：根据应用的任务需求（如需要多少个 Map/Reduce 任务），向 ResourceManager 的调度器申请 Container 资源。
- 任务调度：将申请到的 Container 分配给具体任务（如 Map 任务分配到数据所在的节点），并向 NodeManager 发送指令，启动任务。
- 任务监控：实时监控所有任务的运行状态，若某个任务失败，会重新申请资源并重启任务；若 ApplicationMaster 自身失败，ResourceManager 会重启它。
- 结果汇总：当所有任务执行完成后，向 ResourceManager 汇报应用完成状态，释放资源并退出。
4. 核心组件 4：Container—— 资源分配的 “最小单位”
Container 是 YARN 中 “资源的抽象封装”，也是任务运行的 “隔离环境”—— 它不是一个进程，而是一组资源的集合（CPU、内存、磁盘 I/O、网络带宽等），并通过 Linux 的 Cgroups 等技术实现资源隔离，确保不同任务之间不会抢占资源。
Container 的核心特点：
- 动态分配：资源按需分配，没有固定的 Map/Reduce Slot 划分，某个任务需要多少资源就申请多少，用完释放，提高资源利用率。
- 多维度资源：支持 CPU、内存、磁盘、网络等多维度资源限制，满足不同任务的资源需求（如 CPU 密集型的机器学习任务、内存密集型的数据处理任务）。
- 生命周期绑定：Container 的生命周期与任务绑定 —— 任务启动时创建 Container，任务结束后 Container 释放资源，资源可被其他任务复用。
三、YARN 运行全流程：一个 MapReduce 任务如何在 YARN 上运行？
为了让大家更直观理解 YARN 的工作机制，我们以 “运行一个 WordCount MapReduce 任务” 为例，拆解从应用提交到任务完成的完整流程（共 8 步）：
步骤 1：客户端提交应用
用户通过hadoop jar命令提交 WordCount 任务（应用），并指定应用的相关信息：应用名称、Map/Reduce 任务数量、ApplicationMaster 的启动脚本、应用所需的资源总量等。客户端会将这些信息发送给 YARN 的 ResourceManager。
步骤 2：ResourceManager 启动 ApplicationMaster
ResourceManager 的应用程序管理器（Applications Manager）收到请求后，会先检查集群资源是否充足。若充足，会向某个 NodeManager 发送指令，启动一个 “启动型 Container”—— 这个 Container 专门用于运行 WordCount 应用的 MRAppMaster（ApplicationMaster）。
步骤 3：ApplicationMaster 注册并申请资源
MRAppMaster 启动后，会先向 ResourceManager 注册自己的身份信息（如应用 ID、自身所在的节点地址），之后 ResourceManager 就会通过 MRAppMaster 监控整个应用的运行状态。
接着，MRAppMaster 会分析 WordCount 任务的需求：需要 10 个 Map 任务、2 个 Reduce 任务，并根据 HDFS 中数据的分布情况（数据本地化原则），向 ResourceManager 的调度器申请 12 个 Container 资源（10 个用于 Map 任务，2 个用于 Reduce 任务）。
步骤 4：ResourceManager 调度资源并分配 Container
调度器根据集群的资源策略（如容量调度），结合各 NodeManager 汇报的资源剩余情况，为 MRAppMaster 分配 12 个 Container—— 优先将 Map 任务的 Container 分配到数据所在的 DataNode 节点（减少网络传输）。调度器会返回每个 Container 的具体信息：所在节点的 IP、端口、资源大小等。
步骤 5：ApplicationMaster 启动任务 Container
MRAppMaster 收到 Container 分配结果后，会向对应的 NodeManager 发送指令：在指定 Container 中启动 Map/Reduce 任务。NodeManager 收到指令后，会根据 Container 的资源配置，创建隔离的运行环境，加载 Map/Reduce 任务的代码和依赖，启动任务。
步骤 6：任务执行并汇报进度
Map/Reduce 任务在 Container 中运行，实时向 MRAppMaster 汇报进度（如 Map 任务处理了多少数据、Reduce 任务聚合了多少结果）。若某个任务执行失败，MRAppMaster 会向 ResourceManager 申请新的 Container，在其他节点重启任务。
同时，各 NodeManager 会持续向 ResourceManager 汇报本节点的资源使用情况和 Container 状态，确保 ResourceManager 掌握全局状态。
步骤 7：应用完成，释放资源
当所有 Map/Reduce 任务执行完成后，MRAppMaster 会向 ResourceManager 汇报 “应用完成”，并释放所有已分配的 Container 资源。
步骤 8：ResourceManager 清理并反馈结果
ResourceManager 收到应用完成的通知后，会清理该应用的相关元数据，然后向客户端返回 “任务完成” 的反馈。客户端可以通过 HDFS 查看 WordCount 的最终输出结果，整个流程结束。
四、YARN 与 Hadoop 1.x 的核心差异：从 “封闭” 到 “开放”
通过前面的架构和流程拆解，我们能清晰看到 YARN 相比 Hadoop 1.x 的革命性变化。下面通过表格总结核心差异，帮大家快速梳理：
| 对比维度 | Hadoop 1.x（无 YARN） | Hadoop 2.x（有 YARN） |
|---|---|---|
| 资源管理组件 | JobTracker（集资源 + 任务管理于一体） | ResourceManager（全局资源管理）+ NodeManager（节点资源管理） |
| 任务调度组件 | JobTracker 直接调度 Map/Reduce 任务 | ApplicationMaster（每个应用独立调度） |
| 资源分配单位 | 固定 Slot（Map Slot/Reduce Slot） | 动态 Container（按需分配 CPU / 内存） |
| 资源利用率 | 低（静态分区，Slot 易闲置） | 高（动态调配，资源按需复用） |
| 支持的计算框架 | 仅 MapReduce | MapReduce、Spark、Flink、Storm 等 |
| 集群扩展性 | 差（JobTracker 单点瓶颈） | 好（ResourceManager 轻量，支持上万节点） |
| 任务容错 | JobTracker 统一处理 | ApplicationMaster 自主处理，ResourceManager 监控 AM |
核心总结：YARN 的本质是 “通用资源管理平台”—— 它剥离了 MapReduce 的资源管理功能，让 MapReduce 从 “全栈框架” 降级为 “运行在 YARN 上的计算引擎”，同时开放接口支持其他计算框架，让 Hadoop 集群成为 “多框架共享的资源池”。
五、YARN 的核心优势与典型应用场景
1. 核心优势
- 统一资源管理：集群的 CPU、内存、磁盘等资源由 YARN 统一调度，避免多框架重复部署集群，降低运维成本；
- 动态资源调配：资源按需分配、动态回收，解决了静态 Slot 的资源浪费问题，集群资源利用率提升 30% 以上；
- 高扩展性：ResourceManager 仅负责资源调度，不参与任务监控，支持上万节点的大规模集群；
- 生态开放：支持 MapReduce、Spark、Flink 等主流计算框架，企业可根据场景选择合适的框架，复用 Hadoop 的存储和资源；
- 高容错性：任何组件失败都有兜底机制（如 AM 失败重启、任务失败重试），确保集群稳定运行。
2. 典型应用场景
- 多框架共享集群：企业用一套 Hadoop 集群，同时运行 MapReduce（离线批处理）、Spark（交互式分析）、Flink（实时流处理），资源按需分配；
- 大规模批处理：支撑 MapReduce 处理 PB 级数据，YARN 通过动态资源调配，让批处理任务高效利用集群资源；
- 交互式查询：Spark SQL、Hive 等交互式查询框架运行在 YARN 上，YARN 的资源隔离机制确保查询任务不会影响其他任务；
- 实时流处理：Flink、Storm 等流处理框架通过 YARN 获取资源，实现低延迟的实时数据处理（如实时日志分析、实时推荐）。
六、总结与下期预告
这一期我们拆解了 YARN 的核心架构和运行机制 —— 它的核心价值在于 “解耦” 和 “开放”：解耦了资源管理与任务调度，解决了 Hadoop 1.x 的单点瓶颈；开放了资源接口，让 Hadoop 从 “单一计算框架” 升级为 “分布式计算平台”。
有了 YARN 的支撑，Hadoop 生态才能容纳 MapReduce、Spark、Flink 等多样化的计算框架，成为大数据领域的 “基础设施”。下一期，我们将进入实战环节 —— 手把手教大家搭建 Hadoop 2.0 集群，从环境准备、配置文件修改到集群启动验证，让你亲手打造属于自己的 Hadoop 集群，为后续的生态工具学习打下基础。
思考题：如果集群中同时运行 “离线批处理任务”（MapReduce）和 “实时流处理任务”（Flink），你会选择 YARN 的哪种调度策略（容量调度 / 公平调度）？为什么？欢迎在评论区分享你的思路！