1、YARN背景介绍

YARN是在MRv1基础上演化而来的，它克服了MRv1的各种局限性。相比于YARN，MRv1的局限性可概括为如下几个方面：

扩展性差。在MRv1中，JobTracker同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了Hadoop集群的扩展性；
*
可靠性差。MRv1采用了master/slave结构，其中，master存在单点故障问题，一旦它出现故障将导致整个集群不可用；
*
资源利用率低。MRv1采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源。此外，Hadoop将槽位分为Map Slot和Reduce Slot两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另外一种闲置（比如一个作业刚刚提交时，只会运行Map Task，此时Reduce Slot闲置）；
*
无法支持多种计算框架。随着互联网的高度发展，MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、流式计算框架和迭代式计算框架等，而MRv1不能支持多种计算框架并存。

为了克服以上几个缺点，Apache开始尝试对Hadoop进行升级改造，进而诞生了更加先进的下一代MapReduce计算框架MRv2。正式由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN，直接导致下一代MapReduce的核心从单一的计算框架MapReduce转移为通用的资源管理系统YARN。下图展示了以MapReduce为核心的软件栈与以YARN为核心的软件栈的对比情况，在以MapReduce为核心的软件栈中，资源管理系统YARN是可插拔替换的，比如选择Mesos替换YARN，一旦MapReduce接口改变，所有的资源管理系统的实现均需要跟着改变；但以YARN为核心的软件栈则不同，所有框架都需要实现YARN定义的对外接口以运行在YARN之上，这意味着Hadoop2.X可以打造一个以YARN为核心的生态系统。

随着互联网的高速发展，基于数据密集型应用的计算框架不断出现，从支持离线处理的MapReduce，到支持在线处理的Storm，从迭代式计算框架Spark到流式处理框架S4，各种框架诞生于不同的公司或者实验室，它们各有所长，各自解决了某一类应用问题。而在大部分互联网公司中，这几种框架可能同时被采用，比如在搜索引擎公司中，一种可能的技术方案如下：网页建立索引采用MapReduce框架，自然语言处理/数据挖掘采用Spark（如网页PageRank计算、聚类分类算法等），对性能要求很高的数据挖掘算法用MPI等。考虑到资源利用率、运维成本、数据共享等因素，公司一般希望将所有这些框架都部署到一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，同时采用某种资源隔离方案（如轻量级cgroups）对各个任务进行隔离，这样便诞生了轻量级计算平台，如下图所示，YARN便是弹性计算平台的典型代表。

YARN是一个弹性计算平台，它的目标已经不再局限于支持MapReduce一种计算框架，而是朝着对多种框架进行统一管理的方向发展。相比于“一种计算框架一个集群”的模式，共享集群的模式存在多种好处：

资源利用率高。如果每个框架一个集群，则往往由于应用程序数量和资源需求的不均衡性，使得在某段时间内，有些计算框架的集群资源紧张，而另外一些集群资源空闲。共享集群模式则通过多种框架共享资源，使得集群中的资源得到更加充分的利用。
*
运维成本低。如果采用“一个框架一个集群”的模式，则可能需要多个管理员管理这些集群，进而增加运维成本，而共享集群模式通常仅需要少数管理员即可完成多个框架的统一管理。
*
数据共享。随着数据量的暴增，跨集群间的数据移动不仅需要花费更长的时间，且硬件成本也会大大增加，而共享集群模式可让多种框架共享数据和硬件资源，将大大减小数据移动带来的成本。

2、YARN基本架构

YARN总体上仍然是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。

下图描述了YARN的基本组成结构，YARN主要由ResourceManager、NodeManager、ApplicationMaster（图中给出了MapReduce和MPI两种计算框架的ApplicationMaster，分别为MRAppMstr和MPI AppMstr）和Container等几个组件构成。

A、ResourceManager（RM）

RM是一个全局的资源管理器，负责整个集群中所有资源的统一管理和分配，它接收来自各个节点（NodeManager）的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序（实际上是ApplicationMaster）。

整体上来讲，ResourceManager需通过两个RPC协议与NodeManager和（各个应用程序的）ApplicationMaster交互，如下图所示：

根据上图，各个RPC协议的具体工作内容描述如下：

ResourceTracker：NodeManager通过该RPC协议向ResourceManager注册、汇报节点健康状况和Container运行状态，并领取ResourceManager下达的命令，这些命令包括重新初始化、清理Container等，在该RPC协议中，ResourceManager扮演RPC Server的角色（由内部组件ResourceTrackerService实现），而NodeManager扮演RPC Client的角色，换句话说，NodeManager与ResourceManager之间采用了”pull模型“，NodeManager总是周期性地主动向ResourceManager发起请求，并通过领取下达给自己的命令；
*
ApplicationMasterProtocol：应用程序的ApplicationMaster通过该RPC协议向ResourceManager注册、申请资源和释放资源。在该协议中，ApplicationMaster扮演RPC Client的角色，而ResourceManager扮演RPC Server的角色，换句话说，ResourceManager与ApplicationMaster之间也采用了”pull模型“；
*
ApplicationClientProtocol：应用程序的客户端通过该RPC协议向ResourceManager提交应用程序、查询应用程序状态和控制应用（比如杀死应用程序）等。在该协议中，应用程序客户端扮演RPC Client的角色，而ResourceManager扮演RPC Server的角色。

概括起来，ResourceManagert主要完成以下几个功能：

与客户端交互，处理来自客户端的请求；
*
启动和管理ApplicationMaster，并在它运行失败时重新启动它；
*
管理NodeManager，接收来自NodeManager的资源汇报信息，并向NodeManager下达管理命令（比如杀死Container等）；
*
资源管理与调度，接收来自ApplicationMaster的资源申请请求，并为之分配资源等。

从另一个角度进行总结，RM主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Application Manager，ASM）。

（1）调度器

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

（2）应用程序管理器

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

B、ApplicationMaster（AM）

用户提交的每个应用程序均包含一个AM，主要功能包括：

与RM调度器协商以获取资源（用Container表示）；
*
将得到的任务进一步分配给内部的任务；
*
与NM通信以启动/停止任务；
*
监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

当前YARN自带了两个AM实现，一个是用于演示AM编写方法的实例程序distributedshell，它可以申请一定数目的Container以并行运行一个Shell命令或者Shell脚本；另一个是运行MapReduce应用程序的AM——MRAppMaster。

ApplicationMaster管理部分主要由三个服务构成，分别是ApplicationMaster Launcher、AMLivelinessMonitor和ApplicationMasterService，它们共同管理应用程序的ApplicationMaster的生存周期。ApplicationMaster的启动流程如下图所示：

从ResourceManager获得资源到启动ApplicationMaster的详细过程，描述如下：

步骤1：用户向YARN ResourceManager提交应用程序，ResourceManager收到提交请求后，先向资源调度器申请用以启动ApplicationMaster的资源，待申请到资源后，再由ApplicationMasterLauncher与对应的NodeManager通信，从而启动应用程序的ApplicationMaster；
*
步骤2：ApplicationMaster启动完成后，ApplicationMasterLauncher会通过事件的形式，将刚刚启动的ApplicationMaster注册到AMLivelinessMonitor，以启动心跳监控；
*
步骤3：ApplicationMaster启动后，先向ApplicationMasterService注册，并将自己所在host、端口号等信息汇报给它；
*
步骤4：ApplicationMaster运行过程中，周期性地向ApplicationMasterService汇报”心跳“信息（包含想要申请的资源描述）；
*
步骤5：ApplicationMasterService每次收到ApplicationMaster的心跳信息后，将通知AMLivelinessMonitor更新该应用程序的最近汇报心跳的时间；
*
步骤6：当应用程序运行完成后，ApplicationMaster向ApplicationMasterService发送请求，注销自己；
*
步骤7：ApplicationMasterService收到注销请求后，标注应用程序运行状态为完成，同时通知AMLivelinessMonitor移除对它的心跳监控。

C、NodeManager（NM）

NodeManager是YARN中单个节点上的代理，它管理Hadoop集群中单个计算节点，功能包括与ResourceManager保持童心、管理Container的生命周期、监控每个Container的资源使用（内存、CPU等）情况、追踪节点健康状况、管理日志和不同应用程序用到的附属服务（auxiliary service）。总结来说就是两点：一方面，它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自AM的Container启动/停止等各种请求。

整体上来讲，NodeManager需通过两个RPC协议与ResourceManager服务以及各个应用程序的ApplicationMaster交互，如下图所示：

（1）ResourceTrackerProtocol协议

NodeManager通过该RPC协议向ResourceManager注册、汇报节点健康状况和Container运行状态，并领取ResourceManager下达的命令，包括重新初始化、清理Container占用资源等。在该RPC协议中，ResourceManager扮演RPC Server的角色，而NodeManager扮演RPC Client的角色（由内部组件NodeStatusUpdater实现），换句话说，NodeManager与ResourceManager之间采用了“pull模型”，NodeManager总是周期性地主动向ResourceManager发起请求，并领取下达给自己的命令。

NodeStatusUpdater：NodeStatusUpdater是NodeManager与ResourceManager通信的唯一通道。当NodeManager启动时，该组件负责向ResourceManager注册，并汇报节点上总的可用资源（该值在运行过程中不再汇报）；之后，该组件周期性与ResourceManager通信，汇报各个Container的状态更新，包括节点上正运行的Container、已完成的Container等信息，同时ResourceManager会为之返回待清理Container列表、待清理应用程序列表、诊断信息、各种Token等信息。

（2）ContainerManagementProtocol协议

应用程序的ApplicationMaster通过该RPC协议向NodeManager发起针对Container的相关操作，包括启动Container、杀死Container、获取Container执行状态等。在该协议中，ApplicationMaster扮演RPC Client的角色，而NodeManager与ApplicationMaster扮演RPC Server的角色（由内部组件ContainerManager实现），换句话说，NodeManager与ApplicationMaster之间采用了“push模型”，ApplicationMaster可以将Container相关操作第一时间告诉NodeManager，相比于“pull模型”，可大大降低时间延迟。

ContainerManager：ContainerManager是NodeManager中最核心的组件之一，它由多个子组件构成，每个子组件负责一部分功能，共同协作管理运行在该节点上的所有Container。

D、Container

Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。需要注意的是，Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。当前，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制Cgroups进行资源隔离。

3、资源隔离

资源隔离是指为不同人物提供可独立使用的计算资源以避免它们相互干扰。当前存在很多资源隔离技术，比如硬件虚拟化、虚拟机、Cgroups、Linux Container等。

YARN对内存资源和CPU资源采用了不同的资源隔离方案，对于内存资源，它是一种限制性资源，它的量的大小直接决定了应用程序的死活。为了能够更灵活地控制内存使用量，YARN提供了两种可选方案：线程监控方案和基于轻量级资源隔离技术Cgroups的方案。默认情况下YARN采用线程监控的方案控制内存使用，即每个NodeManager会启动一个额外监控线程监控每个Container内存资源使用量，一旦发现它超过约定的资源量，即将其杀死。采用这种机制的另一个原因是Java中创建子进程采用了“fork()+exec()”的方案，子进程启动瞬间，它使用的内存量与父进程一致。从外面来看，一个进程使用的内存量可能瞬间翻倍，然后又降下来，采用线程监控的方法可防止这种情况下导致swap操作（因此，默认情况下YARN采用的是线程监控的方案）。另一种可选的方案则基于轻量级资源隔离技术Cgroups，Cgroups是Linux内核提供的弹性资源隔离机制，可以严格限制内存使用上限，一旦进程使用资源量超过事先定义的上限值，则可将其杀死。对于CPU资源，它是一种弹性资源，它的量的大小不会直接影响应用程序的死活，因此采用了Cgroups。

Cgroups（Control groups）是Linux内核提供的一种可以限制、记录、隔离进程组所使用的物理资源（如CPU、内存、IO等）的机制，最初由Google的工程师提出，后来整合进Linux内核。Cgroups最初的目标是为资源管理提供一个统一的框架，既整合现有的cpuset等子系统，也为未来开发新的子系统提供接口，以使得Cgroups适用于多种应用场合，从单个进程的资源控制到实现操作系统层次的虚拟化的应用场景均支持。总结起来，Cgroups提供以下功能：

限制进程组使用的资源量。比如，内存子系统可以为进程组设定一个内存使用上限，一旦进程组使用的内存达到限额，再申请内存，就会触发OOM；
*
进程组的优先级控制。比如，可以使用CPU子系统为某个进程组分配特定cpu share（Hadoop YARN正是使用了该功能）。
*
对进程组使用的资源量进行记账。比如，可以记录某个进程组使用的CPU时间，以便对不同进程组拥有者计费；
*
进程组控制。比如，可将某个进程组挂起和恢复。

4、YARN工作流程

运行在YARN上的应用程序主要分为两类：短应用程序和长应用程序。其中，短应用程序是指一定时间内（可能是秒级、分钟级或小时级，尽管天级别或者更长时间的也存在，但非常少）可运行完成并正常退出的应用程序，比如MapReduce作业、Tez DAG作业等。长应用程序是指不出意外，永不停止运行的应用程序，通常是一些服务，比如Storm Service（主要包括Nimbus和Supervisor两类服务），HBase Service（包括Hmaster和RegionServer两类服务）等，而它们本身作为一个框架提供了编程接口供用户使用。尽管这两类应用程序作用不同，一类直接运行数据处理程序，一类用于部署服务（服务之上再运行数据处理程序），但运行在YARN上的流程是相同的。

当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：第一个阶段是启动ApplicationMaster；第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成，如下图所示。

根据上图，可将YARN的工作流程分为如下几个步骤：

步骤1：用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等；
*
步骤2：ResourceManager为该应用程序分配第一个Container，并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster；
*
步骤3：ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复图中的步骤4～7；
*
步骤4：ApplicationMaster采用轮询的方式通过RPC协议向ResourceMaster申请和领取资源；
*
步骤5：一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务；
*
步骤6：NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务；
*
步骤7：各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可以随时通过RPC向ApplicationMaster查询应用程序的当前运行状态；
*
应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。

5、YARN资源调度器

资源调度器是YARN中最核心的组件之一，且是插拔式的，它定义了一整套接口规范以便用户可按照需要实现自己的调度器。YARN自带了FIFO、Capacity Scheduler和Fair Scheduler三种常用的资源调度器，当然，用户可按照接口规范编写一个新的资源调度器，并通过简单的配置使它运行起来。

（1）FIFO Scheduler

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

FIFO Scheduler是最简单也最容易的资源调度器，但它并不适用于共享集群。大的应用可能会占用较多的集群资源，这就将导致其他应用被阻塞，而且它也没有考虑应用的优先级，因而应用场景非常受限。

（2）Capacity Scheduler

Capacity Scheduler是Yahoo开发的多用户调度器，它以队列为单位划分资源，每个队列可设定一定比例的资源最低保证和使用上限，同时，每个用户也可设定一定的资源使用上限以防止资源滥用。而当一个队列的资源有剩余时，可暂时将剩余资源共享给其他队列。总的来说，Capacity Scheduler主要有以下几个特定：

容量保证。管理员可为每个队列设置资源最低保证和资源使用上限，而所有提交到该队列的应用程序共享这些资源；
*
灵活性。如果一个队列中的资源有剩余，可以暂时共享给那些需要资源的队列，而一旦该队列有新的应用程序提交，则其他队列释放的资源会归还给该队列；
*
多重租赁。支持多用户共享集群和多应用程序同时运行，为防止单个应用程序、用户或者队列独占集群中的资源，管理员可为之增加多重约束（比如单个应用程序同时运行的任务数等）；
*
安全保证。每个队列有严格的ACL列表规定它的访问用户，每个用户可指定哪些用户允许查看自己应用程序的运行状态或者控制应用程序（比如杀死应用程序）。此外，管理员可指定队列管理员和集群系统管理员；
*
动态更新配置文件。管理员可根据需要动态修改各种配置参数，以实现在线集群管理。

（3）Fair Scheduler

Fair Scheduler是Facebook开发的多用户调度器，同Capacity Scheduler类似。它以队列为单位划分资源，每个队列可设定一定比例的资源最低保证和使用上限，同时，每个用户也可设定一定的资源使用上限以防止资源滥用；当一个队列的资源有剩余时，可暂时将剩余资源共享给其他队列。当然，Fair Scheduler也存在很多与Capacity Scheduler不同之处，主要体现在以下几个方面：

资源公平共享。在每个队列中，Fair Scheduler可选择按照FIFO、Fair或DRF（即Dominant Resource Fairness算法）策略为应用程序分配资源。其中，Fair策略是一种基于最大最小公平算法实现的资源多路复用方式，默认情况下，每个队列内部采用该方式分配资源。这意味着，如果一个队列中有两个应用程序同时运行，则每个应用程序得到1/2的资源；如果有三个应用程序同时运行，则每个应用程序可得到1/3的资源；
*
支持资源抢战。当某个队列中有剩余资源时，调度器会将这些资源共享给其他队列，而当该队列中有新的应用程序提交时，调度器要为它回收资源。为了尽可能降低不必要的计算浪费，调度器采用了先等待再强制回收的策略，即如果等待一段时间后尚有未归还的资源，则会进行资源抢战；从那些超额使用资源的队列中杀死一部分任务，进而释放资源；
*
负载均衡。Fair Scheduler提供了一个机遇任务数目的负载均衡机制，该机制尽可能将系统中的任务均匀分配到各个节点上。此外，用户也可以根据自己的需要设计负载均衡机制；
*
调度策略配置灵活。Fair Scheduler允许管理员为每个队列单独设置调度策略（当前支持FIFO、Fair或DRF三种）；
*
提供小应用程序相应时间。由于采用哦了最大最小公平算法，小作业可以快速获取资源并运行完成。

参考文献：

——《CSDN博客》

——《Hadoop技术内幕深入解析YARN架构设计与实现原理》

转自https://mp.weixin.qq.com/s/StTxnzbcVhTHmBC0BgbY2Q