YARN
YARN（Yet Another Resource Negotiator）是 Hadoop 的集群资源管理与作业调度系统。它的职责可以用一句话概括：管理集群里所有机器的 CPU 和内存，决定哪个任务在什么时候拿到多少资源、在哪台机器上跑。
一、它是为了解决什么问题出现的
Hadoop 1.x 时代没有 YARN，资源管理和作业调度全压在一个 JobTracker 上。这个设计有两个致命问题：
- 单点瓶颈：JobTracker 既要管集群资源，又要跟踪每个任务的执行状态，集群规模一大就扛不住，也是单点故障。
- 只能跑 MapReduce：整个调度逻辑和 MapReduce 强绑定，别的计算框架用不了这个集群。
YARN 的解法是把「管资源」和「管作业」拆开：资源统一由 ResourceManager 管，每个作业的执行细节交给该作业自己的 ApplicationMaster。这一拆的意义极大——集群从此不再是 MapReduce 专用，Spark、Flink、Tez 都能跑在同一个 YARN 集群上共享资源。
二、四个核心组件
- ResourceManager（RM）——集群级别的全局资源管理者，整个集群一个（生产上配 HA 双节点）。它只做两件事：接收各个 NodeManager 汇报的资源情况，以及按调度策略把资源分配给各个应用。它不关心你的作业内部在干什么。
- NodeManager（NM）——每台工作节点上一个。负责管理本机的资源，向 RM 汇报心跳和资源使用情况，并按 RM 的指令启动和监控 Container。
- ApplicationMaster（AM）——每个应用（作业）一个，作业结束就销毁。它负责这个作业的全部执行细节：向 RM 申请资源、把任务分配到各个 Container、监控任务状态、失败重试。这是 YARN 设计的精髓——把作业管理的压力从中心节点分散到了每个作业自己身上，RM 因此得以保持轻量。
- Container——资源的抽象封装，代表某台机器上的一份资源（多少 CPU、多少内存）。所有任务都在 Container 里执行，包括 AM 自己。
三、一次作业提交的完整流程
text
| 1 | 1. 客户端向 RM 提交应用 |
| 2 | 2. RM 分配第一个 Container，在其中启动这个作业的 AM |
| 3 | 3. AM 向 RM 注册，然后按需申请运行任务所需的资源 |
| 4 | 4. RM 返回可用 Container，AM 联系对应的 NM 启动任务 |
| 5 | 5. 各任务向 AM 汇报进度，AM 全程监控、失败则重试 |
| 6 | 6. 作业完成，AM 向 RM 注销并释放所有资源 |
注意资源是 AM 主动「要」来的，不是 RM 推过来的，而且是分批申请、用完释放。
四、三种调度器
RM 按什么策略分配资源，取决于配置的调度器：
| 调度器 | 特点 | 问题 |
|---|---|---|
| FIFO | 单队列，先提交先执行 | 大作业会把小作业堵死，生产不用 |
| Capacity（容量） | 多队列，每队列预留固定容量比例，队列内 FIFO | 资源可能闲置浪费，是 Apache Hadoop 默认 |
| Fair（公平） | 多队列，队列内所有作业动态均分资源 | 需要抢占机制配合，是 CDH 默认 |
生产环境基本都用 Capacity 或 Fair，并按业务线划分队列做资源隔离——这样某个业务写了个跑飞的任务，也不会把整个集群拖垮。数仓开发申请「队列权限」，申请的就是在某个 YARN 队列上提交任务的资格。
登录后可以选中正文添加批注（仅自己可见）。
评论 (0)
登录后参与评论。
还没有评论，来做第一个。