YARN

YARN

Apache YARN(Yet Another Resource Negotiator) 是Hadoop集群的资源管理系统。YARN为应用使用提供请求集群资源的API，对使用者而言，这些分布式计算框架的细节被YARN的资源管理所隐藏。下图展示的是分布式计算框架（MapReduce，spark等）运行在集群计算层（YARN）和集群存储层（HDFS，HBase）上。

其中pig，hive等是调用MapReduce的运行。

YARN的架构

YARN的体系架构见图：

YARN总体上是Master/Slave结构，主要由ResourceManager、NodeManager、 ApplicationMaster和Container等几个组件构成。

ResourceManager(RM) ：负责对各NM上的资源进行统一管理和调度。将AM分配空闲的Container运行并监控其运行状态。对AM申请的资源请求分配相应的空闲Container。主要由两个组件构成：调度器和应用程序管理器

1、调度器(Scheduler)：调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位是Container，从而限定每个任务使用的资源量。Shceduler不负责监控或者跟踪应用程序的状态，也不负责任务因为各种原因而需要的重启（由ApplicationMaster负责）。总之，调度器根据应用程序的资源要求，以及集群机器的资源情况，为应用程序分配封装在Container中的资源。 调度器是可插拔的，例如CapacityScheduler、FairScheduler。具体看下文的调度算法。

2、应用程序管理器(Applications Manager)：应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动AM、监控AM运行状态并在失败时重新启动等，跟踪分给的Container的进度、状态也是其职责。

NodeManager (NM) ：NM是每个节点上的资源和任务管理器。它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；同时会接收并处理来自AM的Container 启动/停止等请求。

ApplicationMaster (AM)： 用户提交的应用程序均包含一个AM，负责应用的监控，跟踪应用执行状态，重启失败任务等。ApplicationMaster是应用框架，它负责向ResourceManager协调资源，并且与NodeManager协同工作完成Task的执行和监控。MapReduce就是原生支持的一种框架，可以在YARN上运行Mapreduce作业。有很多分布式应用都开发了对应的应用程序框架，用于在YARN上运行任务，例如Spark，Storm等。如果需要，我们也可以自己写一个符合规范的YARN application。

Container： Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container 表示的。 YARN会为每个任务分配一个Container且该任务只能使用该Container中描述的资源。

解剖YARN的运行

YARN通过2个常驻后台程序提供它的核心服务：

1、ResourceManager（RM）：对集群中资源的使用进行管理；

2、NodeManager（NM）：运行在集群的所有节点从而去发起并监视containers。

container是在有限的资源下执行一个特别的应用进程。下图是YARN运行应用的流程图。

a、用户向YARN中提交应用程序，其中包括AM程序、启动AM的命令、命令参数、用户程序等；事实上，需要准确描述运行ApplicationMaster的unix进程的所有信息。提交工作通常由YarnClient来完成。

b、RM为该应用程序分配第一个Container，并与对应的NM通信，要求它在这个Container中启动AM；

c、AM首先向RM注册，这样用户可以直接通过RM査看应用程序的运行状态，运行状态通过 AMRMClientAsync.CallbackHandler的getProgress() 方法来传递给RM。 然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤d〜g；

d、AM采用轮询的方式通过RPC协议向RM申请和领取资源；资源的协调通过 AMRMClientAsync异步完成,相应的处理方法封装在AMRMClientAsync.CallbackHandler中。

e、—旦AM申请到资源后，便与对应的NM通信，要求它启动任务；通常需要指定一个ContainerLaunchContext，提供Container启动时需要的信息。

f、NM为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务；

g、各个任务通过某个RPC协议向AM汇报自己的状态和进度，以让AM随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务；ApplicationMaster与NM的通信通过NMClientAsync object来完成，容器的所有事件通过NMClientAsync.CallbackHandler来处理。例如启动、状态更新、停止等。

h、应用程序运行完成后，AM向RM注销并关闭自己。

YARN资源调度器

ResourceManager分配集群资源的时候，以抽象的Container形式分配给各应用程序，至于应用程序的子任务如何使用这些资源，由应用程序自行决定。主要有2种调度器：FIFO Scheduler 、Capacity Scheduler和Fair Scheduler。

Capacity Scheduler

适合于多用户共享集群的环境的调度器。在多用户的情况下，达到最大化集群的吞吐和利用率的目的。Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。下图为FIFO Scheduler

一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job，如果这个队列的资源够用，那么就分配给这些job，如果这个队列的资源不够用了呢？其实Capacity调度器仍可能分配额外的资源给这个队列，这就是弹性队列(queue elasticity)的概念。

一般情况下，Capacity调度器不会强制释放Container，当一个队列资源不够用时，这个队列只能获得其它队列释放后的Container资源。当然，我们可以为队列设置一个最大资源使用量，以免这个队列过多的占用空闲资源，导致其它队列无法使用这些空闲资源，这就是弹性队列需要权衡的地方。

Capacity Scheduler特点

• 容量保证：每个队列都分配了一部分容量，他们可以支配着部分资源。提交到特定队列的应用程序，可以使用该队列的资源。管理员可以配置每个队列容量的最低保证和资源使用上限。

• 安全性：每个队列都有严格的ACL（控制访问列表），它可以控制用户提交应用程序到特定队列上。同时保证用户不能查看或修改其它用户提交的应用程序，并且队列管理员和集群系统管理员可以对其进行维护。

• 灵活性：队列的空闲资源可以分配各其它队列使用。如果某队列的资源分配未达到队列资源使用上限，在其需要更多资源时，将分配其它队列的空闲资源给该繁忙队列。

• 多用户性：支持多用户共享集群，一些列的综合设置可以防止单个应用程序、用户或队列独占队里或集群的全部资源。

• 可操作性：支持运行时配置和队列停止。队列的属性（例如：资源容量分配、ACL等）可以在运行时由管理员以一种安全的方式更改，从而减少了对用户的影响。同时提供给管理员和用户一个界面，用于查看当前队列资源的使用情况。管理员可以在集群运行时添加新队列，可以在停止运行的队列的同时保证队列上的任务运行完成，而新的任务不能提交到该队列上。注意现在不支持在运行时删除队列，如果需要删除队列，需要重启集群。

• 层级队列：层级队列可确保资源在该组织的子队列之间被共享，从而提供更多的可控制性和预测性。

• 基于资源的调度：支持资源密集型的应用程序，允许应用程序使用的资源量高于默认值，从而该调度器可以支持不同资源需求的应用程序。目前只支持内存资源的配置，通过配置可支持CPU资源。

Fair Scheduler

Fair Scheduler是由Facebook贡献的，是Hadoop上一个可插拔式的调度器，允许YARN应用程序在一个大的集群上公平地共享资源。公平调度是一种为应用程序分配资源的方法，多用户的情况下，强调用户公平地使用资源。默认情况下Fair Scheduler根据内存资源对应用程序进行公平调度，通过配置可以修改为根据内存和CPU两种资源进行调度。当集群中只有一个应用程序运行时，那么此应用程序占用这个集群资源。当其他的应用程序提交后，那些释放的资源将会被分配给新的应用程序，所以每个应用程序最终都能获取几乎一样多的资源。

在Fair Scheduler中，不需要预先占用一定的系统资源，Fair Scheduler会动态调整应用程序的资源分配。例如，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。需要注意的是，在下图Fair Scheduler中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。

Fair Scheduler允许为队列分配担最小的共享资源量，这样可以保证某些用户、groups或者应用程序总能获取充足的资源。当一个队列中有正在运行的应用程序时，它至少能够获取设置的最小资源，当队列中无任务时，它的资源将会被拆分给其他运行中的任务。

Fair Scheudler在默认情况下允许所有的任务运行，但是这也可以通过配置文件来限制每个用户下和每个队列下运行的任务个数。处于限制时，新提交的任务不会提交失败，而是在Scheduler queue中等待，直到先前的任务结束，再执行。

Fair Scheduler vs Capacity Scheduler

相同点

• 都支持多用户多队列，即：适用于多用户共享集群的应用环境

• 都支持层级队列

• 支持配置动态修改，更好的保证了集群的稳定运行。

• 均支持资源共享，即某个队列中的资源有剩余时，可共享给其他缺资源的队列

• 单个队列均支持优先级和FIFO调度方式

不同点

• Capacity Scheduler与Fair Scheduler最大的区别为调度策略的不同

• Capacity Scheduler的调度策略是，可以先选择资源利用率低的队列，然后在队列中通过FIFO或DRF进行调度。

• Fair Scheduler的调度策略是，可以使用公平排序算法选择队列，然后再队列中通过Fair（默认）、FIFO或DRF的方式进行调度。