一、YARN 体系 架构
YARN（Yet Another Resource Negotiator，另一种资源协调者） 是 Hadoop 2.0 中的资源管理系统，它的基本设计思想是将 MRv1 中的 JobTracker拆分成了两个独立的服务 ：一个全局的资源管理器 ResourceManager 和每个应用程序特有的ApplicationMaster 。其中 ResourceManager 负责整个系统的资源管理和分配，而 ApplicationMaster负责单个应用程序的管理。
1.1 核心交互流程
- MR作业状态汇报 Container（Map|Reduce Task）-->Container（MrAppMaster）
- MR作业提交 Client-->RM
- 节点的状态汇报 NM-->RM
- 资 源的申请 MrAppMaster-->RM
二、YARN 组件及功能
YARN 总体上仍然是 Master/Slave 结构（主从结构） ，在整个资源管理框架中， ResourceManager 为Master， NodeManager 为 Slave ，ResourceManager 负责对各个 NodeManager 上的资源进行统一管理和调度。 当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向 ResourceManager 申请资源，并要求 NodeManger 启动可以占用一定资源的任务。由于不同的 ApplicationMaster 被分布到不同的节点上，因此它们之间不会相互影响。
上图描述了 YARN 的基本组成结构， YARN 主要由 ResourceManager、 NodeManager、ApplicationMaster（图中给出了 MapReduce 和 MPI 两种计算框架的 ApplicationMaster，分别为 MR AppMstr 和 MPI AppMstr）和 Container 等几个组件构成。
|-------------------|----------------------------------------------------------------------------------------------------|------------|
| 进程 | 描述 | 级别 |
| ResourceManager | 使用Scheduler（ResourceScheduler类）和ApplicationManager（RMAppManager类）分配群集资源。 | 守护进程 |
| ApplicationMaster | 通过指示NodeManager创建或销毁Application的Container来管理Application的生命周期。一个Application只有一个ApplicationMaster进程。 | 用户进程 |
| NodeManager | 通过在群集节点中创建和销毁容器来管理特定节点中的作业或工作流。 | 守护进程 |
| Container | Container是Yarn对计算资源的抽象，它其实是一组CPU和内存资源，所有的应用都会运行在Container中。 | 用户进程 |
2.1 ResourceManager
RM（ResourceManager） 是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager， ASM）。
- 调度器（Scheduler） ：根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
- 需要注意的是，该调度器是一个"纯调度器"，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的 ApplicationMaster 完成。
- 调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念"资源容器"（Resource Container，简称 Container）表示， Container 是一个动态资源分配单位，它将内存、 CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
- 此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器， YARN 提供了多种直接可用的调度器，比如 FairScheduler 和 Capacity Scheduler 等。
- 应用程序管理器（Applications Manager）：负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。
2.2 ApplicationMaster
用户提交的每个应用程序均包含一个 AM，主要功能包括：
- 与 RM 调度器协商以获取资源（用 Container 表示）；
- 将得到的任务进一步分配给内部的任务；
- 与 NM 通信以启动 / 停止任务；
- 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
当前YARN自带了两个AM实现，一个是用于演示AM编写方法的例程序distributedshell，它可以申请一定数目的 Container 以并行运行一个 Shell 命令或者 Shell 脚本 ；另一个是运行 MapReduce 应用程序的 AM---MRAppMaster，此外，一些其他的计算框架对应的 AM 正在开发中，比如 Spark、Flink 等。
2.3 NodeManager
NM（NodeManager） 是每个节点上的资源和任务管理器，一方面，它会定时地向 RM 汇报本节点上的资源使用情况和各个 Container 的运行状态；另一方面，它接收并处理来自 AM 的 Container启动 / 停止等各种请求。
2.4 Container
Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当 AM 向 RM 申请资源时， RM 为 AM 返回的资源便是用 Container表示的。 YARN 会为每个任务分配一个 Container，且该任务只能使用该 Container 中描述的资源。需要注意的是， Container 不同于 MRv1 中的 slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。当下， YARN 仅支持 CPU 和内存两种资源，且使用了轻量级资源隔离机制 Cgroups 进行资源隔离 。
YARN支持各种数据处理引擎对HDFS中的数据进行批处理、交互式和流处理。在不同的场景中使用不同的框架，常见的包括MapReduce、Spark、Storm和Flink等Application。这种架构可以更好、更优雅地进行扩展。因此从一开始就内置了高可用性、安全性和多租户支持更多用户在大型集群上使用，新架构还将提高创新性，敏捷性和硬件利用率。
此外，YARN提供以下功能：
- 多租户：可以使用多个开放源代码和专有数据访问引擎来批量、交互式和实时访问同一数据集。多租户数据处理可提高企业在Hadoop投资上的回报。
- Docker容器化：可以使用Docker容器化来并行运行同一应用程序的多个版本。
- 集群利用率：可以动态分配群集资源以提高资源利用率。
- 多种资源类型：可以使用多种资源类型，例如CPU和内存。
- 可扩展性：提高了数据中心的处理能力。YARN的ResourceManager仅专注于调度，并在集群扩展到管理数PB数据的数千个节点时保持同步。
- 兼容性：Hadoop 1.x的MapReduce应用程序可在YARN上运行，而不会破坏现有流程。YARN与Hadoop的先前稳定版本保持API兼容性。
三、YARN通信协议
RPC 协议是连接各个组件的"大动脉"，了解不同组件之间的 RPC 协议有助于更深入地理解学习 YARN 框架。在 YARN 中，任何两个需相互通信的组件之间仅有一个 RPC 协议，而对于任何一个 RPC 协议，通信双方有一端是 Client，另一端为 Server，且 Client 总是主动连接 Server 的，因此， YARN 实际上采用的是拉式（pull-based）通信模型 。
如上图所示，箭头指向的组件是 RPC Server，而箭头尾部的组件是 RPC Client， YARN 主要由以下几个 RPC 协议组成 ：
- JobClient（作业提交客户端 ）与 RM 之间的协议 ---ApplicationClientProtocol：JobClient 通过该 RPC 协议提交应用程序、查询应用程序状态等。
- Admin（管理员）与 RM 之间的通信协议---ResourceManagerAdministrationProtocol：Admin 通过该 RPC 协议更新系统配置文件，比如节点黑白名单、用户队列权限等。
- AM 与 RM 之间的协议---ApplicationMasterProtocol ： AM 通过该 RPC 协议向 RM注册和撤销自己，并为各个任务申请资源。
- AM 与 NM 之 间 的 协 议 ---ContainerManagementProtocol： AM 通 过 该 RPC 要 求NM 启动或者停止 Container，获取各个 Container 的使用状态等信息。
- NM 与 RM 之间的协议---ResourceTracker ： NM 通过该 RPC 协议向 RM 注册，并定时发送心跳信息汇报当前节点的资源使用情况和 Container 运行情况。
为了提高 Hadoop 的向后兼容性和不同版本之间的兼容性，YARN 中的序列化框架采用
了 Google 开源的 Protocol Buffers。
四、YARN 工作流程
运行在Hadoop YARN 上的应用程序主要分为两类 ：短应用程序和长应用程序。
- 短应用程序： 指一定时间内 （可能是秒级、分钟级或小时级，尽管天级别或者更长时间的也存在，但非常少）可运行完成并正常退出的应用程序，比如 MapReduce 作业、 Spark 作业等；
- 长应用程序 ：指不出意外，永不终止运行的应用程序，通常是一些服务，比如 Storm Service（主要包括 Nimbus 和 Supervisor 两类服务）， **Flink（包括 JobManager和 TaskManager两类服务）**等，而它们本身作为一个框架提供了编程接口供用户使用。
尽管这两类应用程序作用不同，一类直接运行数据处理程序，一类用于部署服务（服务之上再运行数据处理程序），但运行在 YARN 上的流程是相同的。
当用户向 YARN 中提交一个应用程序后， YARN 将分两个阶段运行该应用程序 ：第一
个阶段是启动 ApplicationMaster ；第二个阶段是由 ApplicationMaster 创建应用程序，为它
申请资源，并监控它的整个运行过程，直到运行完成。 
如上图所示， YARN 的工作流程分为以下几个步骤：
- 第1步、用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster 的命令、用户程序等。
- 第2步、ResourceManager 为该应用程序分配第一个Container，并与对应的 NodeManager通信，要求它在这个 Container 中启动应用程序的 ApplicationMaster。
- 第3步、ApplicationMaster 首先向 ResourceManager 注册，这样用户可以直接通过ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤 4~7。
- 第4步 、ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和领取资源。
- 第5步、一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求它启动任务。
- 第6步、NodeManager 为任务设置好运行环境（包括环境变量、 JAR 包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
- 第7步 、各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当前运行状态。
- 第8步、应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己。
YARN 正是一个资源管理系统，它的出现弱化了计算框架之争，引入 YARN 这一层后，各种计算框架可各自发挥自己的优势，并由 YARN 进行统一管理，进而运行在一个大集群上。截至本书出版时，各种开源系统都在开发 YARN 版本，包括 MapReduce、Spark、 Storm、 Flink等。