目录

一、YARN简介

二、YARN的由来

三、YARN的基本设计思想

四、YARN 的基本架构

4.1 基本架构图

 4.2 基本组件介绍

4.2.1 ResourceManager

 4.2.1.1 任务调度器(Resource Scheduler)

4.2.1.2 应用程序管理器（Applications Manager）

4.2.1.3 其他

4.2.2 NodeManager（NM）

4.2.2.1 ApplicationMaster（AM）

4.2.2.2 Container

五、YARN的工作原理

 5.1 工作流程图

 5.2 工作流程步骤描述

 5.2.1 步骤1

 5.2.2 步骤2

 5.2.3 步骤3

5.2.4 步骤4

5.2.5 步骤5

5.2.6 步骤6

 5.2.7 步骤7

5.2.8 步骤8

 六、YARN通讯协议

6.1 RPC通信图

 6.2 组件通讯协议描述

 6.2.1 ApplicationClientProtocol

 6.2.2 ResourceManagerAdministrationProtocol

 6.2.3 ApplicationMasterProtocol

 6.2.4 ContainerManagementProtocol

 6.2.5 ResourceTracker

 七、资源调度器分类

 7.1 FIFO Scheduler

7.2 Capacity Scheduler

7.3 Fair Scheduler

---

一、YARN简介

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

二、YARN的由来

在YARN出来之前，其实在Hadoop体系里面，负责资源管理和作业控制的是MRv1（Hadoop 1.0）体系中的JobTracker在承担，但是MRv1体系其实有其缺点，如下：

1）扩展性差

在MRv1中，JobTracker是个重量级组件，集中了资源管理分配、作业控制两大核心功能，随着集群规模的增大，JobTracker处理各种RPC请求负载过重，这也是系统的最大瓶颈，严重制约了Hadoop集群的扩展性。

2）可靠性差。

MRv1 采用了 master/slave 结构，其中，master 存在单点故障问题，一旦它出现故障将导致整个集群不可用。

3）资源利用率低。

MRv1 采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源 划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空 闲资源。此外，Hadoop 将槽位分为 Map Slot 和 Reduce Slot 两种，且不允许它们之 间共享，常常会导致一种槽位资源紧张而另外一种闲置(比如一个作业刚刚提交时， 只会运行 Map Task，此时 Reduce Slot 闲置)。

4）无法支持多种计算框架。

随着互联网高速发展，MapReduce 这种基于磁盘的离线计 算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、 流式计算框架和迭代式计算框架等，而 MRv1 不能支持多种计算框架并存。

为了克服以上几个缺点，Apache 开始尝试对 Hadoop 进行升级改造，进而诞生了更加 先进的下一代 MapReduce 计算框架 MRv2。正是由于 MRv2 将资源管理功能抽象成了一个 独立的通用系统 YARN，直接导致下一代 MapReduce 的核心从单一的计算框架 MapReduce转移为通用的资源管理系统 YARN。

YARN将 JobTracker 中的资源管理和作业控制功能分 开， 分 别 由 组件ResourceManager 和 ApplicationMaster 实 现， 其 中，ResourceManager 负责所有应用程序的资源分配，而 ApplicationMaster 仅负责管理一个应用程序，基于 YARN，用户可以运行各种类型的应用程序(不再像 1.0 那样仅局限于 MapReduce 一类应用)，从离线计算的 MapReduce 到在线计算 (流式处理)的 Storm 等。

三、YARN的基本设计思想

在 Hadoop 1.0 中，JobTracker 由资源管理(由 TaskScheduler 模块实现)和作业控制(由 JobTracker 中多个模块共同实现)两部分组成。当前 Hadoop MapReduce 之所以在可扩展性、资源利用率和多框架支持等方面存在不足，正是由于 Hadoop 对 JobTracker 赋予的功能过多而造成负载过重。此外，从设计角度上看，Hadoop 未能够将资源管理相关的功能与应用程序相关的功能分开，造成 Hadoop 难以支持多种计算框架。

下一代 MapReduce 框架的基本设计思想是将 JobTracker 的两个主要功能，即资源管理和作业控制(包括作业监控、容错等)，分拆成两独立的进程。资源管理进程与具体应用程序无关，它负责整个集群的资源(内存、CPU、磁盘等)管理，而作业控制进程则是直接与应用程序相关的模块，且每个作业控制进程只负责管理一个作业。这样， 通过将原有 JobTracker 中与应用程序相关和无关的模块分开，不仅减轻了 JobTracker 负载， 也使得 Hadoop 支持更多的计算框架。

四、YARN 的基本架构

4.1 基本架构图

Yarn在整体上看还是采用了和Hadoop1.x一样的Master/Slave结构（横向扩展混杂Slave/Slave结构），在整个Yarn资源管理系统当中，ResourceManager作为Master，各个节点的NodeManager作为Slave。各个节点上NodeManager的资源由ResourceManager统计进行管理和调度。当应用程序提交后，会有一个单独的ApplicationMaster来对该应用程序进行跟踪和管理，同时该ApplicationMaster还会为该应用程序向ResourceManager申请资源，并要求NodeManager启动该应用程序占用一定资源的任务。由于不同的 ApplicationMaster 被分布到不同的节点上，因此它们之间不会相互影响。

 4.2 基本组件介绍

4.2.1 ResourceManager

ResourceManager是Yarn的核心组件，主要由任务调度器（Resource Scheduler）和应用程序管理器（Applications Manager）组成。其主要功能是负责系统资源的管理和分配。

 4.2.1.1 任务调度器(Resource Scheduler)

调度器根据容量、队列等限制条件(如每个队列分配一定的资源，最多执行一定数量的作业等)，将系统中的资源分配给各个正在运行的应用程序。需要注意的是，该调度器是 一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪 应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务， 这些均交由应用程序相关的 ApplicationMaster 完成。调度器仅根据各个应用程序的资源需 求进行资源分配，而资源分配单位用一个抽象概念“资源容器”(Resource Container，简 称 Container)表示，Container 是一个动态资源分配单位，它将内存、CPU、磁盘、网络等 资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件， 用户可根据自己的需要设计新的调度器，YARN 提供了多种直接可用的调度器，比如 Fair Scheduler 和 Capacity Scheduler 等。

4.2.1.2 应用程序管理器（Applications Manager）

应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。

4.2.1.3 其他

ResourceManager中还包含了其他组件，如ResourceTrackerService用来直接处理心跳，NMLivelinessMonitor用来监控NodeManager，NodesListManager 提供NodeManager的黑白名单等等

4.2.2 NodeManager（NM）

NM是每个子节点上的资源和任务管理器，一方面，它会定向通过心跳信息向RM汇报本节点上的资源使用情况和各个Container的运行情况；另一方面，它会接收并且处理来自AM的Container启动和停止的各种请求。它的能有点像Hadoop1.x中的TaskTracker。

4.2.2.1 ApplicationMaster（AM）

每当用户提交了一个应用程序就会为这个应用程序产生一个对应的ApplicationMaster，并且这个这个单独进程是在其中一个子节点上运行的。它的主要功能：为应用向ResourceManager申请资源、在job对Task实行调度、与NodeManager通信以启动或者停止任务、监控所有任务的运行情况，并且在任务失败的情下，重新为任务申请资源并且重启任务、负责推测任务的执行、当ApplicationMaster向ResourceManager注册后，ApplicationMaster可以提供客户端查询作业进度信息等。

4.2.2.2 Container

Container是Yarn中对系统资源的抽象，同时它也是系统资源分配的基本单位，它封装节点上多维度资源，其中包括CPU、内存、磁盘、网络等。Yarn会为每个任务分配一个Container，并且该任务只能够使用该Container中所描述的资源。值得关注的的是，Yarn中的Container和MRv1中的Slot是完全不同的，Container是一个动态的资源划分单位，它是根据实际提交的应用程序所需求的资源自动生成的，换句话说，Container其里边所描述的CPU、内存等资源是根据实际应用程序需求而变的。而Slot是一个静态的资源抽象单位，每一个同类型的Slot所描述的资源信息都是一样的。

五、YARN的工作原理

 5.1 工作流程图

 5.2 工作流程步骤描述

 5.2.1 步骤1

用户向Yarn提交应用程序，其中包括用户程序、相关文件、启动ApplicationMaster命令、ApplicationMaster程序等。

 5.2.2 步骤2

ResourceManager为该应用程序分配第一个Container，并且与Container所在的NodeManager通信，并且要求该NodeManager在这个Container中启动应用程序对应的ApplicationMaster。

 5.2.3 步骤3

ApplicationMaster首先会向ResourceManager注册，这样用户才可以直接通过ResourceManager查看到应用程序的运行状态，然后它将为该应用程序的各个任务申请资源，并监控它们的运行状态直到运行结束，即重复后面4~7步骤。

5.2.4 步骤4

ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。

5.2.5 步骤5

一旦ApplicationMaster申请到资源后，便会与申请到的Container所对应的NodeManager进行通信，并且要求它在该Container中启动任务。

5.2.6 步骤6

任务启动。NodeManager为要启动的任务配置好运行环境，包括环境变量、JAR包、二进制程序等，并且将启动命令写在一个脚本里，通过该脚本运行任务。

 5.2.7 步骤7

各个任务通过RPC协议向其对应的ApplicationMaster汇报自己的运行状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以再任务运行失败时重启任务。

5.2.8 步骤8

应用程序运行完毕后，其对应的ApplicationMaster会向ResourceManager通信，要求注销和关闭自己。

这个需要注意的是在整个工作流程当中，ResourceManager和NodeManager都是通过心跳保持联系的，NodeManager会通过心跳信息向ResourceManager汇报自己所在节点的资源使用情况。

 六、YARN通讯协议

RPC 协议是连接各个组件的“大动脉”，了解不同组件之间的 RPC 协议有助于我们更深入地学习 YARN 框架。在 YARN 中，任何两个需相互通信的组件之间仅有一个 RPC 协 议，而对于任何一个 RPC 协议，通信双方有一端是 Client，另一端为 Server，且 Client 总 是主动连接 Server 的，因此，YARN 实际上采用的是拉式(pull-based)通信模型。

6.1 RPC通信图

 

箭头指向的组件是 RPC Server，而箭头尾部的组件是 RPC Client

 6.2 组件通讯协议描述

 6.2.1 ApplicationClientProtocol

JobClient(作业提交客户端)与 RM 之间的协议 ，JobClient 通过该 RPC 协议提交应用程序、查询应用程序状态等。

 6.2.2 ResourceManagerAdministrationProtocol

Admin(管理员)与 RM 之间的通信协议，Admin 通过该 RPC 协议更新系统配置文件，比如节点黑白名单、用户队列权限等。

 6.2.3 ApplicationMasterProtocol

AM 与 RM 之间的协议，AM 通过该 RPC 协议向 RM 注册和撤销自己，并为各个任务申请资源。

 6.2.4 ContainerManagementProtocol

AM 与 NM 之间的协议，AM 通过该 RPC 要求 NM 启动或者停止 Container，获取各个 Container 的使用状态等信息。

 6.2.5 ResourceTracker

NM 与 RM 之间的协议，NM 通过该 RPC 协议向 RM 注册，并 定时发送心跳信息汇报当前节点的资源使用情况和 Container 运行情况。

 七、资源调度器分类

目前，Hadoop 作业调度器主要有三种：FIFO、Capacity Scheduler 和 Fair Scheduler。Hadoop 版本 2.6.0-cdh5.14.2 默认的资源调度器是 Fair Scheduler。

 7.1 FIFO Scheduler

FIFO Scheduler 把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。

FIFO Scheduler 是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用 Capacity Scheduler 或 Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。

7.2 Capacity Scheduler

 

Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。

支持多个队列，每个队列可配置一定的资源量，每个队列都采用 FIFO 调度策略。

为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源量进行限定。

按照作业优先级和提交时间顺序，同时考虑用户资源量限制和内存限制对队列内任务排序。多个队列同时按照任务的先后顺序依次执行，也就是排在队列前面的最先执行，也是同时执行。

7.3 Fair Scheduler

 

支持多队列，多用户，每个队列中的资源量可以配置，同一队列中的作业公平共享队列中所有资源。

比如有三个队列 queue1、Queue2、Queue3，每个队列中的 job 按照优先级分配资源，优先级越高分配的资源越多，但是每个 job 都会分配到资源以确保公平。在资源有限的情况下，每个 job 理想情况下获得的计算资源与实际获得的计算资源存在一种差距，这个差距就叫做差额。在同一个队列中，job 的资源缺额越大，越先获得资源优先执行。作业是按照缺额的高低来先后执行的。在 Fair调度器中，我们不需要预先占用一定的系统资源，Fair 调度器会为所有运行的 job动态的调整系统资源。

如下图所示，当第一个大 job 提交时，只有这一个 job 在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair 调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。

今天YARN的相关内容就分享到这里，如果帮助到大家，欢约大家点赞+关注+收藏，有疑问也欢迎大家评论留言！