MapReduce V2---Yarn的架构及其执行原理
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中描述的资源
(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通信。也会跟其他的节点通信。