Yarn框架概述

从Hadoop用户那里总结出MapReduce框架当前最紧迫的需求有：
    （1）可靠性（Reliability）– JobTracker不可靠
    （2）可用性（Availability）– JobTracker可用性有问题
    （3） 扩展性（Scalibility）-拥有10000个节点和200，000个核的集群
    （4） 向后兼容性（Backward Compatibility）：确保用户的MapReduce作业可无需修改即可运行
    （5）  演化（Evolution）：让用户能够控制软件栈的升级，尤其是与Hive，HBase等的兼容。
    （6） 可预测的延迟：这是用户非常关心的。小作业应该尽可能快得被调度，而当前基于TaskTracker->JobTracker ping（heartbeat）的通信方式代价和延迟过大，比较好的方式是JobTracker->TaskTracker ping, 这样JobTracker可以主动扫描有作业运行的TaskTracker（调用RPC）（见MAPREDUCE-279）。
    （7）集群资源利用率。 Map slot和reduce slot不能共享，且reduce 依赖于map结果，造成reduce task在shuffle阶段资源利用率很低，出现“slot hoarding”现象。
次重要的需求有：
    （1）支持除MapReduce之外的计算框架，如DAG，迭代计算等。
    （2） 支持受限的，短时间的服务
面对以上这些需求，我们有必要重新设计整个MapReduce数据计算架构。大家已达成共识：当前的MapReduce架构不能够满足我们上面的需求，而MRv2/YARN将可解决该问题。

                                                       

                                                                                                  MRv2/Yarn架构图

MRv2最基本的设计思想是将JobTracker的两个主要功能，即资源管理和作业调度/监控分成两个独立的进程。在该解决方案中包含两个组件：全局的ResourceManager（RM）和与每个应用相关的ApplicationMaster（AM）。这里的“应用”指一个单独的MapReduce作业或者DAG作业。RM和与NodeManager（NM，每个节点一个）共同组成整个数据计算框架。RM是系统中将资源分配给各个应用的最终决策者。ApplicationMaster实际上是一个具体的框架库，它的任务是【与RM协商获取应用所需资源】和【与NM合作，以完成执行和监控task的任务】

ResourceManager
ResourceManager(RM)包括两个组件:调度器(Scheduler)和 应用管理器(ApplicationsManager，ASM)
在YARN 1.0中，调度器仅考虑了内存资源。 每个节点由多个固定内存大小（512MB或者1GB）的容器组成。ApplicationMaster可以申请该内存整数倍大小的容器。
    调度器仅根据各个应用的资源需求进行调度，这是通过抽象概念“资源容器”完成的，资源容器(Resource Container)将内存，CPU，磁盘，网络等资源封装在一起，从而限定每个任务使用的资源量。调度器是可插拔的组件，主要负责将集群中得资源分配给多个队列和应用。YARN自带了多个资源调度器，如Capacity Scheduler和Fair Scheduler等。
调度器周期性地收到NodeManager所在节点的资源变化信息，同时，调度器会将已使用完的容器分配重新分给合适的ApplicationMaster。
    ApplicationsManager主要负责接收作业，分配一个容器(Container)作为ApplicationMaster,负责管理系统中所有应用程序的ApplicationMaster，负责启动和监控ApplicationMaster的运行状态，在ApplicationMaster失败时对其进行重启等。为了完成上述功能，ApplicationsManager主要有以下几个组件：
（1）SchedulerNegotiator：与调度器协商容器资源，并返回给ApplicationMaster
（2）AMContainerManager：告知NodeManager，启动或者停止某个ApplicationMaster的容器
（3）AMMonitor：查看ApplicationMaster是否活着，并在必要的时候重启ApplicationMaster
    容器(Container)：是YARN为了将来作资源隔离而提出的一个框架，目前仅提供java虚拟机内存的隔离。

NodeManager
NodeManager是每个节点上的框架代理，每个节点上装有一个NodeManager，主要的职责有：
（1）为应用程序启动容器，同时确保申请的容器使用的资源不会超过节点上的总资源，
（2）为task构建容器环境，包括二进制可执行文件，jars等
（3）为所在的节点提供了一个管理本地存储资源的简单服务，应用程序可以继续使用本地存储资源即使他没有从ResourceManager那申请。比如：MapReduce可以使用该服务程序存储map task的中间输出结果。
（4）负责容器状态的维护与监控资源（内存，CPU，磁盘，网络等）的使用情况并将之汇报给调度器。

ApplicationMaster
ApplicationMaster：每个应用程序均会有一个ApplicationMaster，是一个详细的框架库，主要职责有：
（1）与调度器协商资源
（2）与NodeManager合作，在合适的容器中运行对应的task，并监控这些task执行
（3）如果container出现故障，ApplicationMaster会重新向调度器申请资源
（4）计算应用程序所需的资源量，并转化成调度器可识别的格式（协议）

（5）ApplicationMaster出现故障后，ApplicationsManager会重启它，而由ApplicationMaster自己从之前保存的应用程序执行状态中恢复应用程序。 

Yarn框架相对于MapReduce框架的优势：
（1）这个设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
（2）在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中。
（3）对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。
（4）老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
（5）Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。