5.2 YARN 架构

5.2 YARN 架构

本节摘要：YARN 把 v1 的 JobTracker 拆成三角色：ResourceManager 做全局资源仲裁、NodeManager 管单节点资源、ApplicationMaster 每作业一个负责自己的任务编排。资源计量从互不通用的槽位变成按内存与 CPU 申请的容器。本节拆解三角色分工与一次 MapReduce 作业在 YARN 上的完整生命周期。

拆的是什么

v1 的病根是"资源管理"与"作业管理"长在同一个进程里。YARN 的手术只有一刀：把两者分开。

• ResourceManager：集群唯一的资源仲裁者。不知道什么是 Map 任务、什么是 Reduce 任务，只回答一个问题——"谁想申请多少内存多少核，批不批、批在哪"；
• NodeManager：每节点一个，向 ResourceManager 汇报本节点资源，负责启动与监控容器（container，资源分配的基本单位，规定了内存与 CPU 上限）；
• ApplicationMaster：每个作业启动时先在某个容器里拉起一个"作业管家"，由它向 ResourceManager 要容器、把任务安排进容器、监控任务、失败重试。MapReduce 作业的 ApplicationMaster 里住着的，正是 v1 时代 JobTracker 的"作业管理"那一半。

资源计量随之换代：槽位换成容器，按需申请"多少 MB 内存加多少个核"。Map 任务可以申请 2GB 容器，Reduce 任务申请 4GB 容器，错峰的资源不再按类型闲置——谁要谁拿，按量计价。

图 5.2-1 MapReduce 作业在 YARN 上的执行视图

几个关键机制细节

本地性延续。 ApplicationMaster 申请容器时可以附上偏好节点（分片数据所在机器），ResourceManager 的调度器在批资源时尽量满足，满足不了就降级——第 2.2 节的三级本地性与延迟调度思想在 YARN 上原样复活，只是决策者从 JobTracker 换成了两边协作。

ApplicationMaster 的可扩展性。 每作业一个管家，管家的状态压力正比于单作业任务数而非全集群总量。ResourceManager 只管"批容器"，面对几千节点也只维护容器账本，两边的规模瓶颈同时解除。作业级容错也随之自然：ApplicationMaster 挂了，ResourceManager 只需重拉这个作业的管家，其他作业毫发无伤——v1 时代 JobTracker 一崩全集群停摆的场面不复存在。

调度器可插拔。 ResourceManager 内部的分配策略是可替换组件：容量调度器按队列划分并给保障，公平调度器在用户间均分资源。多租户集群因此能同时承载报表批作业与临时分析作业，互相隔离又互不饿死。这一层与 MapReduce 无关，属于"集群操作系统"的通用能力——也是 YARN 这名字（另一种资源协商者）的本意。

对 MapReduce 用户的变化。 写程序几乎无感：YARN 之上官方提供 MRv2 运行时，ApplicationMaster 的逻辑被封装，作业参数、Shuffle 机制、编程接口全部延续。体感差异主要是集群层面的：同一个 YARN 集群上，Spark 作业与 MapReduce 作业排队共享资源，这在 v1 时代需要两套独立集群。

YARN 的历史位置

把镜头拉远：YARN 之后，Hadoop 集群第一次成为通用计算平台——存储归 HDFS、调度归 YARN、计算引擎可插拔。Spark、Flink 以及各种批流图计算框架都是作为"另一种 ApplicationMaster"接入，Hive 的执行也从 MapReduce 逐步切到新引擎，而集群纹丝不动。可以说，v1 到 YARN 的这次架构手术，让"换计算引擎"从集群级大事变成了应用级小事，为第 7 章要讲的引擎迭代铺平了道路。

本节要点回顾

• 一刀拆分：JobTracker 拆成 ResourceManager（资源仲裁）与 ApplicationMaster（每作业的作业管理）。
• 容器经济：槽位换成按内存与核申请的容器，错峰资源不再闲置。
• 九步生命周期：提交、拉管家、注册、算分片、要容器、启任务、报进度、注销、取结果。
• 规模与容错：单点压力随管家数摊薄，管家之死只影响一个作业。
• 通用舞台：调度器可插拔、多框架共存，换引擎不换集群。

舞台搭好了还缺安全网——下一节讲容错与推测执行，看三幕剧中途翻车时系统如何自救。