1. Yarn 产生背景
1.1 MRv1 的局限性
- 扩展性差：在MRV1中，jobtracker同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了hadoop集群扩展性。
- 资源利用率低：MRV1采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源
- 无法支持多种计算框架：随着互联网高速发展，mapreduce这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、流式计算框架和迭代式计算框架等，而MRV1不能支持多种计算框架并存。
2. Yarn基本设计思想
2.1 基本框架对比
在Hadoop1.0中，JobTracker由资源管理器（由TaskScheduler模块实现）和作业控制（由JobTracker中多个模块共同实现而成）两部分组成。
- Hadoop MapReduce存在的问题：MRV1之所以存在可扩展性、资源利用率和多框架等支持方面不足的问题，正是由于Hadoop中JobTracker中赋予的功能过多导致负载过重。
JobTracker的两个主要功能，即资源管理和作业控制（包括作业监控和容错），分拆成两个独立的进程。
- 资源管理进程与具体应用程序无关，它负责整个集群的资源管理（内存、CPU、磁盘等）管理
- 作业控制进程则是直接与应用程序相关的模块，且每个作业控制进程只负责管理一个作业。
2.2 编程模型对比
MRv1主要由编程模型、数据处理引擎和运行环境三部分组成
为了保证编程模型的兼容性，MRv2重用了其编程模型和数据处理引擎，但运行环境被完成重写
- 编程模型与数据处理引擎：MRv2重用了MRv1的编程模型和数据处理引擎。为了能够让用户应用程序平滑迁移到Hadoop2.0中，MRv2应尽可能保证编程接口的向后兼容性。
- 运行时环境：MRv1的运行时候环境主要有两类组成。分别是JobTracker和TaskTracker。其中，JobTracker复制资源管理和任务的管理和调度。TaskTracker负责每个节点的资源管理和任务执行。而MRv2则通过将资源管理和应用程序管理分离开来，分别由Yarn和ApplicationMaster负责，其中，Yarn负责资源管理和调度，而ApplicationMaster负责与具体应用程序相关的任务切分、调度和容错。
3 Yarn基本架构
Yarn 的基本思想：将MRv1中的JobTracker拆分成两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序独有的ApplicationMaster。其中ResourceMangager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。
3.1 Yarn基本组成结构
YARN总体上仍然是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。
ResourceManager（RM）
ResourceManager 是一个全局的资源管理器，负责整个集群的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Master，ASM）。
- 调度器：该调度器是一个 “纯调度器”，不再参与任何与具体应用程序逻辑相关的工作，而仅根据各个应用程序的资源需求进行分配，资源分配的单位用一个资源抽象概念 “Container” 来表示。Container 封装了内存和 CPU。此外，调度器是一个可插拔的组件，用户可根据自己的需求设计新的调度器，YARN 自身提供了 Fair Scheduler 和 Capacity Scheduler。
- 应用程序管理器：应用程序管理器负责管理整个系统中所有应用程序，包括应用程序的提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。
ApplicationMaster
用户提交的每个 Application 都要包含一个 ApplicatioNMaster，主要功能包括：
- 向 RM 调度器申请资源（用 Container 表示）
- 将从 RM 分配的资源分配给 Applcation 内部的任务
- 与 NM 通信请求 启动/停止 任务
- 监控所有任务的运行状态，并在失败时重新为任务申请资源以重启任务
NodeManager
NM 是每个节点上的资源和任务管理器，一方面，它会定时地向 RM 汇报本节点上的资源使用情况和各个 Container 的运行状态；另一方面，它接收并处理来自 AM 的 Container 启动/停止 等各种命令。
Container
Container 是 YARN 中资源抽象，它封装了某个节点上的内存和 CPU、磁盘、网络等，当 AM 向 RM 申请资源时，RM 为 AM 返回的资源便是用 Container 表示的。YARN 是使用轻量级资源隔离机制 Cgroups 进行资源隔离的。
3.2 YARN 通信协议
在 YARN 中，任何两个需要相互通信的组件之间仅有一个 RPC 协议，而对于任何一个 RPC 协议，通信双方有一端是 Client，另一端是 Server，且 Client 总是主动连接 Server。YARN 中有以下几个主要的 RPC 协议：
- JobClient 与 RM 之间的协议：ApplicationClientProtocol，JobClient 通过该 RPC 协议提交应用程序、查询应用程序状态等
- Admin（管理员）与 RM 之间的协议：ResourceManagerAdministrationProtocol，Admin 通过该 RPC 协议更新系统配置文件，比如节点黑白名单、用户队列权限等
- AM 与 RM 之间的协议：ApplicationMasterProtocol，AM 通过该 RPC 协议向 RM 注册并撤销自己，并为各个人物申请资源
- NM 与 RM 之间的协议：ResourceTracker，NM 通过该协议向 RM 注册，并定时发送心跳信息汇报当前节点的资源使用情况和 Container 运行情况，并接收来自 AM 的命令
- AM 与 NM 之间的协议：ContainerManagermentProtocol，AM 通过该 RPC 协议要求 NM 启动或者停止 Container
3.3 YARN 工作流程
YARN 的工作流程如上所示：
- Client 向 YARN 提交应用程序，其中包括 ApplicationMaster 程序及启动 ApplicationMaster 的命令
- ResourceManager 为该 ApplicationMaster 分配第一个 Container，并与对应的 NodeManager 通信，要求它在这个 Container 中启动应用程序的 ApplicationMaster
- ApplicationMaster 首先向 ResourceManager 注册, 这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它们的运行状态，直到运行结束，即重复4~7
- ApplicationMaster 为 Application 的任务申请并领取资源
- 领取到资源后，要求对应的 NodeManager 在 Container 中启动任务
- NodeManager 收到 ApplicationMaster 的请求后，为任务设置好运行环境（包括环境变量、JAR 包、二进制程序等），将任务启动脚本写到一个脚本中，并通过运行该脚本启动任务
- 各个任务通过 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在失败时重启任务
应用程序完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己
。
4. 理解YARN
4.1 并行编程
将YARN看做是一个云操作系统，它负责应用程序启动ApplicationMaster（相当于主进程），然后由ApplicationMaster进行数据切分、任务分配、启动和监控等工作，而由ApplicationMaster启动的各个Task(相当于子线程)仅仅负责自己的计算任务。
4.2 资源管理系统
资源管理系统地主要功能是对集群中各类资源进行抽象，并根据各种应用程序或者服务的要求，按照一定的调度策略，将资源分配给它们使用，同时采用一定的资源隔离机制防止应用程序或者服务之间因资源抢夺而相互干扰。