MapReduce V2---Yarn的架构及其执行原理

1.MRv1的局限性

   1)：扩展性差

           MRv1中，Jobracker同事兼备了资源管理和作业控制（job的生命周期管理(task调度，跟踪task过程状态，task处理容错）两个功能。

    单个的jobtracker无论在内存还是其他资源方面总存在瓶颈，在伸缩性、资源利用率、运行除mapreduce的其他任务等方面都会有限制。

MRv2 Yarn框架把资源调度和task管理监控分离开来，由资源管理器NodeManager负责资源调度，每一个application(job)由一个AppMaster负责对task进行调度管理监控，并且可以监控AppMaster的状态，有问题可以在其他节点重启。

   2)：资源利用率低

     MRv1 mapreduce框架使用slot做资源表示单位，并且map slot和reduce slot分离的，这样资源不能共享，资源利用率不高，yarn使用节点的cpu、内存等资源作为资源表示单位，大大提高了资源利用率。

   

2.Yarn的组成

ResourceManager（RM）

RM是全局资源管理器，负责整个系统的资源管理和分配。

主要由两个组件组成：调度器和应用程序管理器（ASM）

调度器：根据容量，队列等限制条件，将系统中的资源分配给各个正在运行的应用程序，不负责具体应用程序的相关工作，比如监控或跟踪状态

应用程序管理器：负责管理整个系统中所有应用程序

ApplicationMaster(AM)

用户提交的每个应用程序均包含一个AM

AM的主要功能：

     (1)与RM调度器协商以获取资源（用Container表示）

     (2)将得到的任务进一步分配给内部的任务

     (3)与NM通信以自动/停止任务

     (4)监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务

当前YARN自带了两个AM实现

     一个用于演示AM编写方法的实例程序distributedshell

     一个用于Mapreduce程序---MRAppMaster

其他的计算框架对应的AM正在开发中，比如spark等。

Nodemanager（NM）和Container

NM是每个节点上的资源和任务管理器

      (1)定时向RM汇报本节点上的资源使用情况和各个Container的运行状态

      (2)接收并处理来自AM的Container启动/停止等各种要求

Container是YARN中的资源抽象，它封装了某个节点上的多维度资源

     YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源

3.Yarn的执行流程

   

(1)：由客户端提交一个应用，由RM的ASM接受应用请求

提交过来的应用程序包括哪些内容：

a:ApplicationMaster

b:启动Applicationmaster的命令

c:本身应用程序的内容

(2):提交了三部分内容给RM，然后RM找NodeManager,然后

Nodemanager就启用Applicationmaster，并分配Container

 

接下来我们就要执行这个任务了，

(3):但是执行任务需要资源，所以我们得向RM的ASM申请执行任务的资源（它会在ＲＭ这儿注册一下，说我已经启动了，注册了以后就可以通过RM的来管理，我们用户也可以通过ＲＭ的ｗｅｂ客户端来监控任务的状态）ＡＳＭ只是负责APplicationMaster的启用

(4)我们注册好了后，得申请资源，申请资源是通过第四步，向ResourceScheduler申请的

(5)申请并领取资源后，它会找Nodemanager，告诉他我应经申请到了，然后Nodemanager判断一下，

(6)知道他申请到了以后就会启动任务，当前启动之前会准备好环境，

(7)任务启动以后会跟APplicationmaster进行通信，不断的心跳进行任务的汇报。

(8)完成以后会给ＲＭ进行汇报，让RSM撤销注册。然后RSM就会回收资源。当然了，我们是分布式的，所以我们不会只跟自己的Nodemanager通信。也会跟其他的节点通信。