Hadoop-YARN(资源管理系统)

转：http://www.cnblogs.com/sy270321/p/4398703.html

YARN （Yet Another Resource Negotiator另一种资源协调者）Apache Hadoop Yarn是 Hadoop MRv2计算机框架中构建的一个独立的、通用的资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

一、Yarn的出现背景

        由于MRv1在扩展性、可靠性、资源利用率和多框架等方面存在明显的不足，概括为以下几个方面：

        （1）扩展性差。在MRv1中，JobTracker同时兼备了资源管理和作业控制两个功能，这成为系统的最大瓶颈，严重制约了Hadoop集群的扩展性；

        （2）可靠性差。MRv1采用了Master/Slave结构，其中Master存在单点故障问题，一旦它出现故障将导致整个系统不可用；

        （3）资源利用率低。MRv1采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源。此外，Hadoop将槽位分为Map Slot和Reduce Slot两种，且不允许它们之间共享，常常导致一种槽位资源紧张而另一种槽位处于空间状态（如作业刚刚提交时，只会运行Map Task，Reduce Task就处于闲置状态）；

        （4）无法支持多种计算框架。MapReduce基于磁盘的离线计算框架已经不能满足应用要求，而新出现的计算框架，如基于内存的计算框架Spark、流式计算框架Storm等等，MRv1不能支持多种计算框架并存。

        Hadoop1.0即第一代Hadoop由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中HDFS由一个NameNode和多个DateNode组成，MapReduce由一个JobTracker和多个TaskTracker组成。Hadoop2.0即第二代Hadoop为克服Hadoop1.0中的不足：针对Hadoop1.0单NameNode制约HDFS的扩展性问题，提出HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展，同时彻底解决了NameNode单点故障问题；针对Hadoop1.0中的MapReduce在扩展性和多框架支持等方面的不足，它将JobTracker中的资源管理和作业控制分开，分别由ResourceManager（负责所有应用程序的资源分配）和ApplicationMaster（负责管理一个应用程序）实现。

        这样就使得框架从“一种计算框架一个集群”的模式转变为“共享集群”的模式，这样的好处是：

        （1）资源利用率大大提高。一种计算框架一个集群，往往会由于应用程序数量和资源需求的不均衡性，使得在某段时间有些计算框架集群资源紧张，而另外一些集群资源空闲。共享集群模式则通过多种框架共享资源，使得集群中的资源得到更加充分的利用；

        （2）运维成本大大降低。共享集群模式使得少数管理员就可以完成多个框架的统一管理；

        （3）共享集群的模式也让多种框架共享数据和硬件资源更为方便。

二、Yarn的基本架构

        Yarn是Hadoop2.0中的资源管理系统，它的基本设计思想是将MRv1中的JobTracker拆分成两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicatioinMaster。其中ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。

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

        1、ResourceManager（RM）全局的资源管理器，负责整个系统的资源管理和分配，它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（ApplicationManager，ASM）；

        2、NodeManager（NM）每个节点上的资源和任务管理器，一方面它会定时地向RM汇报本节点上的资源使用情况和各个 Container的运行状态，另一方面它接收并处理来自AM的Container启动/停止等各种请求；

        3、ApplicationMaster（AM）用户提交的每个应用程序均包含一个AM，主要功能包括：a、与RM调度器协商以获取资源（用Container表示）；b、将得到的任务进一步分配给内部的任务；c、与NM通信以启动和停止任务；d、监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务；

       4、Container是Yarn中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM和RM申请资源时，RM为AM返回的资源便是用Container表示的。Yarn会为每个任务分配一个Conatiner，且该任务只能使用该Container中描述 的资源。需要注意的是Container不同于MRv1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。

  YARN总体上仍然是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave,ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务。

　　 Hadoop2.0 YARN包含以下实体，可以看图：

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

　　由两个组件组成：

调度器（Scheduler）
　　　调度器根据容量，队列等限制条件（如每个队列分配一定的资源,最多执行一定数量的作业等），
      将系统中的资源分配给各个正在运行的应用。这里的调度器是一个“纯调度器”，因为它不再负责监控或者跟踪应用的执行状态等，
 此外，他也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务。调度器仅根据各个应用的资源　　　　　
 需求进行调度，这是通过抽象概念“资源容器”完成的，资源容器（Resource Container）将内存，CPU，磁盘，网络等资源封装在一起，从而限定每个任务使用的资源量。

 
应用管理器（ApplicationsManager，ASM）
　　　ASM主要负责接收作业，协商获取第一个容器用于执行AM和提供重启失败AM container的服务
　　　  ASM负责管理系统中所有应用程序的AM，正如上一节所述，ASM负责启动AM，监控AM的运行状态，在AM失败时对其进行重启等。
            为了完成该功能，ASM主要有以下几个组件：
           （1）SchedulerNegotiator：与调度器协商容器资源，并返回给AM
           （2）AMContainerManager：告知NM，启动或者停止某个AM的容器
           （3）AMMonitor：查看AM是否活着，并在必要的时候重启AM

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

ApplicationMaster(AM):用户提交每个应用程序均包含一个AM，主要功能与RM调度器协商以获取资源，进一步分配给内部的任务，与NM通信启动/停止任务，监控任务的运行状态

每个应用程序均会有一个AM，主要职责有：
　　（1）  与调度器协商资源
　　（2）  与NM合作，在合适的容器中运行对应的task，并监控这些task执行
　　（3） 如果container出现故障，AM会重新向调度器申请资源
　　（4）  计算应用程序所需的资源量，并转化成调度器可识别的格式（协议）
　　（5）  AM出现故障后，ASM会重启它，而由AM自己从之前保存的应用程序执行状态中恢复应用程序。
　　  注：在MapReduce中，由于AM会定时的保存job的运行时状态，因此，当AM重启时可以恢复对应的job，按照粒度有三种策略：
　　 <1>整个作业重新计算
　　 <2> 保存已经完成的map task和reduce task，只重新计算未完成的task
　　 <3> 保存task的进度，从task断点处开始计算，如：某个task完成了20%，则AM重启后，让该task从20%处开始计算。

Contanier:是YARN中资源的抽象，封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等。当AM想RM申请资源时，RM为AM返回的资源便是用Container表示的。

     （1）  Container是YARN中资源的抽象，它封装了某个节点上一定量的资源（CPU和内存两类资源）。它跟Linux Container没有任何关系，仅仅是YARN提出的一个概念（从实现上看，可看做一个可序列化/反序列化的Java类）。

    （2）  Container由ApplicationMaster向ResourceManager申请的，由ResouceManager中的资源调度器异步分配给ApplicationMaster；

     （3） Container的运行是由ApplicationMaster向资源所在的NodeManager发起的，Container运行时需提供内部执行的任务命令（可以使任何命令，比如java、Python、C++进程启动命令均可）以及该命令执行所需的环境变量和外部资源（比如词典文件、可执行文件、jar包等）。

 

另外，一个应用程序所需的Container分为两大类，如下：

　　（1） 运行ApplicationMaster的Container：这是由ResourceManager（向内部的资源调度器）申请和启动的，用户提交应用程序时，可指定唯一的ApplicationMaster所需的资源；

　　（2） 运行各类任务的Container：这是由ApplicationMaster向ResourceManager申请的，并由ApplicationMaster与NodeManager通信以启动之。

以上两类Container可能在任意节点上，它们的位置通常而言是随机的，即ApplicationMaster可能与它管理的任务运行在一个节点上。

一个应用程序在YARN上的运行步骤　

步骤1：用户将应用程序提交到ResourceManager上；

步骤2：ResourceManager为应用程序ApplicationMaster申请资源，并与某个NodeManager通信，以启动ApplicationMaster；

步骤3：ApplicationMaster与ResourceManager通信，为内部要执行的任务申请资源，一旦得到资源后，将于NodeManager通信，以启动对应的任务。

步骤4：所有任务运行完成后，ApplicationMaster向ResourceManager注销，整个应用程序运行结束。