1. Yarn调度队列
在Yarn中，负责给应用分配资源的是Scheler，并提供了多种调度器和可配置的策略供选择。
在Yarn中有是三种调度器可以选择：FIFO Scheler，Capacity Scheler，Fair Scheler。
FIFO Scheler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheler是最简单也是最容易理解的调度器，不需要任何配置，但其不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheler或Fair Scheler，这两种调度器都允许大任务和小任务在提交的同时获得一定的资源。
下面 Yarn调度器对比图 展示了这几个调度器的区别，从图中可以看出，在FIFO调度器中，小任务会被大任务阻塞。
而对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。
在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如下图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，在下图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成以后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器既得到了高资源的利用率又能保证小任务的及时执行。
Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。
通过上面那幅图，我们已经知道一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job，如果这个队列的资源够用，那么就分配给这些job，如果这个队列的资源不够用了呢？其实Capacity调度器仍可能分配额外的资源给这个队列，这就是“弹性队列”(queue elasticity)的概念。
在正常的操作中，Capacity调度器不会强制释放Container，当一个队列资源不够用时，这个队列只能获得其它队列释放后的Container资源。当然，我们可以为队列设置一个最大资源使用量，以免这个队列过多的占用空闲资源，导致其它队列无法使用这些空闲资源，这就是”弹性队列”需要权衡的地方。
该调度器预定义了一个root队列，所有队里都是该队列的子队列。
在配置root下面的子队列时使用逗号隔开，同时在定义层级队列时使用叫做 queue path 来表明，如 yarn.scheler.capacity.root.a.queues 。各个子队列都可以使用百分比来表示占用父队列资源的比例，如未配置，则表示可以占用到父队列资源的全部资源。同时还可以配置一个用户可以分配的最大资源数、可以同时运行多少个应用等。
调度器中的配置修改后可以使用admin进行动态刷新。
Fair调度器的设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数来设置），用户在各自队列运行中逐渐资源变得平分。
Fair调度器的配置文件位于类路径下的fair-scheler.xml文件中，这个路径可以通过yarn.scheler.fair.allocation.file属性进行修改。若没有这个配置文件，Fair调度器采用的分配策略，调度器会在用户提交第一个应用时为其自动创建一个队列，队列的名字就是用户名，所有的应用都会被分配到相应的用户队列中。
我们可以在配置文件中配置每一个队列，并且可以像Capacity 调度器一样分层次配置队列。比如，参考capacity-scheler.xml来配置fair-scheler：
队列的层次是通过嵌套<queue>元素实现的。所有的队列都是root队列的孩子，即使我们没有配到<root>元素里。在这个配置中，我们把dev队列有分成了eng和science两个队列。
Fair调度器中的队列有一个权重属性（这个权重就是对公平的定义），并把这个属性作为公平调度的依据。在这个例子中，当调度器分配集群40:60资源给prod和dev时便视作公平，eng和science队列没有定义权重，则会被平均分配。这里的权重并不是百分比，我们把上面的40和60分别替换成2和3，效果也是一样的。注意，对于在没有配置文件时按用户自动创建的队列，它们仍有权重并且权重值为1。
每个队列内部仍可以有不同的调度策略。队列的默认调度策略可以通过顶级元素<defaultQueueSchelingPolicy>进行配置，如果没有配置，默认采用公平调度。
尽管是Fair调度器，其仍支持在队列级别进行FIFO调度。每个队列的调度策略可以被其内部的<schelingPolicy> 元素覆盖，在上面这个例子中，prod队列就被指定采用FIFO进行调度，所以，对于提交到prod队列的任务就可以按照FIFO规则顺序的执行了。需要注意，prod和dev之间的调度仍然是公平调度，同样eng和science也是公平调度。
同时Fair调度器采用了一套基于规则的系统来确定应用应该放到哪个队列。在上面的例子中，<queuePlacementPolicy> 元素定义了一个规则列表，其中的每个规则会被逐个尝试直到匹配成功。例如，上例第一个规则specified，则会把应用放到它指定的队列中，若这个应用没有指定队列名或队列名不存在，则说明不匹配这个规则，然后尝试下一个规则。primaryGroup规则会尝试把应用放在以用户所在的Unix组名命名的队列中，如果没有这个队列，不创建队列转而尝试下一个规则。当前面所有规则不满足时，则触发default规则，把应用放在dev.eng队列中。
上面规则可以归结成一句话，除非队列被准确的定义，否则会以用户名为队列名创建队列，还有一个简单的配置策略可以使得所有的应用放入同一个队列（default），这样就可以让所有应用之间平等共享集群而不是在用户之间。直接设置yarn.scheler.fair.user-as-default-queue=false，这样应用便会被放入default 队列，而不是各个用户名队列。另外，我们还可以设置yarn.scheler.fair.allow-undeclared-pools=false，这样用户就无法创建队列了。
尽管上面的配置中没有展示，每个队列仍可配置最大、最小资源占用数和最大可运行的应用的数量。如下：
当一个job提交到一个繁忙集群中的空队列时，job并不会马上执行，而是阻塞直到正在运行的job释放系统资源。为了使提交job的执行时间更具预测性（可以设置等待的超时时间），Fair调度器支持抢占。
抢占就是允许调度器杀掉占用超过其应占份额资源队列的containers，这些containers资源便可被分配到应该享有这些份额资源的队列中。需要注意抢占会降低集群的执行效率，因为被终止的containers需要被重新执行。
可以通过设置一个全局的参数yarn.scheler.fair.preemption=true来启用抢占功能。此外，还有两个参数用来控制抢占的过期时间（这两个参数默认没有配置，需要至少配置一个来允许抢占Container）：
如果队列在minimum share preemption timeout指定的时间内未获得最小的资源保障，调度器就会抢占containers。我们可以通过配置文件中的顶级元素<>为所有队列配置这个超时时间；我们还可以在<queue>元素内配置<minSharePreemptionTimeout>元素来为某个队列指定超时时间。
与之类似，如果队列在fair share preemption timeout指定时间内未获得平等的资源的一半（这个比例可以配置），调度器则会进行抢占containers。这个超时时间可以通过顶级元素 <> 和元素级元素 <fairSharePreemptionTimeout> 分别配置所有队列和某个队列的超时时间。上面提到的比例可以通过 <> (配置所有队列)和 <fairSharePreemptionThreshold> (配置某个队列)进行配置，默认是0.5。
2. Hadoop的资源管理系统 —— Yarn
Yarn 是 Hadoop 的资源管理系统，用于取代 MapRece1 的资源调度，改善 MapRece 的实现，并且有足够的通用性，可以支持其他的分布式计算模式
一般情况下，应用不直接使用 Yarn 的API，而是通过一些分布式计算框架（MapRece、Spark等）来间接实现资源调度管理，使用这些框架的 Yarn 应用运行在集群计算层（Yarn）和集群存储层（HDFS、HBase）上。
Yarn 主要由两部分组成：resource manager、node manager。
资源管理器（resource manager）管理集群上资源的使用，节点管理器（node manager）运行在集群中所有节点上且能够启动和监控容器（container）。容器用于执行特定应用程序的进程，每个容器都有资源限制（内存、CPU）。
在 Yarn 上运行一个应用的步骤如图所示：
在 MapRece1中，有两类守护进程控制作业执行过程： jobtracker、tasktracker 。
jobtracker 通过调度 tasktracker 上运行的任务来协调所有运行在系统上的作业，记录每项作业任务的整体进度情况，若有任务失败，则在另一个 tasktracker 节点上重新调度该任务。
tasktracker 在运行任务的同时将运行进度报告发送给 job tracker。
MapRece1 的 jobtracker 既要负责资源管理（作业的调度分配），将任务分配给不同的 tasktracker；又要负责任务进度的监控。如果集群非常繁忙，每时每刻都有大量的作业，每个作业下又有很多任务，jobtracker 需要面面俱到了解每个任务的执行情况，负担很重。
在 MapRece2 对 Yarn 的应用中，一般是会先让 RM 启动容器运行一个 Application Master 的进程，然后该进程负责创建和监控所有的 map task 和 rece task，了解每个 task 的执行进度，每个 task 都会运行在一个单独的 container 中，这些 container 都是 Application Master 统一调度负责向 RM 申请的，这样就把资源分配和作业运行调度监控解耦，让 Yarn 专注于资源调度。
FIFO 调度器将应用放置在一个队列中，然后按照提交的顺序（先入先出）运行应用。
【优点】简单易懂，不需要任何配置。
【缺点】不适合共享集群。大的应用会占用集群的所有资源，每个应用必须等待直到轮到自己运行，作业平均等待时间较长。
为了避免小作业被大作业阻塞，容量调度器会创建几个队列，其中会有专门队列给小作业执行，保证一提交就可以启动。
每个队列都被分配了一定比例容量的资源，保证大作业不会占用整个集群的所有资源。一般每个队列对应一个组织，这样就允许了多个组织共享一个 Hadoop 集群，每个组织可以分配到集群资源的一部分。队列可以进一步按层次划分，这样每个组织内的不同用户能够共享该组织队列所分配的资源。
在一个队列内，使用 FIFO 调度策略对应用进行调度，但是一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job，如果这个队列的资源够用，那么就分配给这些job。
官方文档： https://hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/CapacityScheler.html 。
容量调度器是 Hadoop2.7 默认的调度器，在 yarn-site.xml 中通过以下参数配置：
"弹性队列" ：如果队列 queue 资源不够用了，而其他队列可能是有空闲可用的资源，那么容量调度器可能会将空余的资源分配给队列 queue 中的队列，这种特性称为 "弹性队列"。可以通过 yarn.scheler.capacity.<queue-path>.maximum-capacity 参数来控制队列最大占用集群资源容量的比例。
示例：
在 root 队列下定义两个队列：prod、dev。分别占用集群 40%、60% 的容量。
prod 没有设置最大容量限制，所以当 dev 队列空闲，prod 资源不足时，可能会占用整个集群 100% 的资源。
dev 队列设置了最大容量显示为 75%，也就是及时另外 25% 的资源空闲，dev 最大也只能占用整个集群 75% 的资源。dev 队列下还有子队列 eng、science，容量都是 dev 容量的 50%，没有为子队列设置最大容量，所以每个子队列最大都可能占用 dev 队列 100% 的资源，所以占用的整个集群的绝对资源大小为 30%~75%。
将上述示例的配置添加到 hadoop 配置文件目录下的 capacity-scheler.xml 中，启动 Yarn，上控制台（ http://192.168.190.111:8088/cluster/scheler ）可以看到配置的队列容量限制。
查看配置的每个队列的容量限制是否生效。
可以看到 prod 队列容量限制是 40%，最大容量限制不设置则默认为 100%。
dev 的两个子队列，占用 dev 队列的相对容量大小为 50%~100%，占用整个集群的绝对容量大小为 30%~100%。
默认的容量调度器配置
公平调度器就是在队列内，所有的作业平等地分配资源，如果队列中只有一个作业，可以占用 100% 的资源；此时进来一个新的作业，则会调度到每个作业占用 50% 的资源，以此类推。
公平调度器不仅实现了队列内部的公平，还实现了队列之间的公平。
现在有两个队列 A、B。当 A 执行第一个作业，而 B 没有作业时，A可以占用整个集群的资源；当 A 作业还没完成，B 执行一个作业，则经过一段时间之后，两个作业各占用集群一半的资源；当 B 启动第二个作业时，队列内部的两个队列共享队列 B 的资源，经过一段时间，各占用集群 1/4 的资源，A 继续占用一半的集群资源。最终结果就是资源在用户之间实现了公平共享。
官方文档： https://hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/FairScheler.html 。
启用公平调度器，在 yarn-site.xml 中添加以下配置：
创建公平调度配置文件 fair-scheler.xml，内容如下：
公平调度器使用一个规则列表来确定应用应该放到哪个队列，可配置的值和含义如下：
将上述的配置配置好，启用 Yarn，web console 上看到的调度器如下：
3. YARN到底是怎么一回事
YARN的编程模型
1：保证编程模型的向下兼容性，MRv2重用了MRv1的编程模型和数据处理引擎，但运行环境被重写。
2：编程模型与数据处理引擎
maprece应用程序编程接口有两套：新的API（mapred)和旧的API（maprece）
采用MRv1旧的API编写的程序可直接运行在MRv2上
采用MRv1新的API编写的程序需要使用MRv2编程库重新编译并修改不兼容的参数 和返回值
3：运行时环境
MRv1:Jobracker和Tasktracker
MRv2:YARN和ApplicationMaster
YARN的组成
yarn主要由ResourceManager，NodeManager，ApplicationMaster和Container等几个组件组成。
ResourceManager（RM）
RM是全局资源管理器，负责整个系统的资源管理和分配。
主要由两个组件组成：调度器和应用 程序管理器（ASM）
调度器
调度器根据容量，队列等限制条件，将系统中的资源分配给各个正在运行的应用程序
不负责具体应用程序的相关工作，比如监控或跟踪状态
不负责重新启动失败任务
资源分配单位用“资源容器”resource Container表示
Container是一个动态资源分配单位，它将内存，CPU,磁盘，网络等资源封装在一起，从而限定每个任务的资源量
调度器是一个可插拔的组件，用户可以自行设计
YARN提供了多种直接可用的调度器，比如fair Scheler和Capacity Scheler等。
应用程序管理器
负责管理整个系统中所有应用程序
ApplicationMaster(AM)
用户提交的每个应用程序均包含一个AM
AM的主要功能
与RM调度器协商以获取资源（用Container表示）
将得到的任务进一步分配给内部的任务
与NM通信以自动/停止任务
监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务
当前YARN自带了两个AM实现
一个用于演示AM编写方法的实例程序distributedshell
一个用于Maprece程序---MRAppMaster
其他的计算框架对应的AM正在开发中，比如spark等。
Nodemanager（NM）和Container
NM是每个节点上的资源和任务管理器
定时向RM汇报本节点上的资源使用情况和各个Container的运行状态
接收并处理来自AM的Container启动/停止等各种要求
Container是YARN中的资源抽象，它封装了某个节点上的多维度资源
YARN会为每个任务分配一个Container，且改任务只能使用该Container中描述的资源
Container不同于MRv1的slot，它是一个动态资源划分单位，是根据应用程序的需求动态产生的
YARN主要由以下几个协议组成
ApplicationClientProtocol
Jobclient通过该RPC协议提交应用才程序，查询应用程序状态等
Admin通过该协议更新系统配置文件，比如节点黑名单，用户队列权限等。
ApplicationMasterProtocol
AM通过该RPC协议想RM注册和撤销自己，并为各个任务申请资源
ContainerManagementProtocol
AM通过要求NM启动或者停止Container，获取各个Container的使用状态等信息
ResourceTracker
NM通过该RPC协议向RM注册，并定时发送心跳信息汇报当前节点的资源使用情况和Container运行状况
YARN的工作流程
文字描述一下这个过程：
1：由客户端提交一个应用，由RM的ASM接受应用请求
提交过来的应用程序包括哪些内容：
a:ApplicationMaster
b:启动Applicationmaster的命令
c:本身应用程序的内容
2:提交了三部分内容给RM，然后RM找NodeManager,然后
Nodemanager就启用Applicationmaster，并分配Container
接下来我们就要执行这个任务了，
3:但是执行任务需要资源，所以我们得向RM的ASM申请执行任务的资源（它会在RM这儿注册一下，说我已经启动了，注册了以后就可以通过RM的来管理，我们用户也可以通过RM的web客户端来监控任务的状态）ASM只是负责APplicationMaster的启用
4::我们注册好了后，得申请资源，申请资源是通过第四步，向ResourceScheler申请的
5:申请并领取资源后，它会找Nodemanager，告诉他我应经申请到了，然后Nodemanager判断一下，
6:知道他申请到了以后就会启动任务，当前启动之前会准备好环境，
7:任务启动以后会跟APplicationmaster进行通信，不断的心跳进行任务的汇报。
8:完成以后会给RM进行汇报，让RSM撤销注册。然后RSM就会回收资源。当然了，我们是分布式的，所以我们不会只跟自己的Nodemanager通信。也会跟其他的节点通信。
4. 怎样获得在yarn框架上运行jar包的执行结果
1、打开Spring Boot应用，通过Maven命令package命令将应用打成jar包。
5. [老实李] YARN通用资源管理系统
Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处
maprece1.0回顾
1. client 负责把作业提交到集群
2. ResourceManager 负责集群资源的统一管理和调度，承担了 JobTracker 的角色，整个集群只有“一个”，总的来说，RM有以下作用：
3. NodeManager 管理YARN集群中的每个节点。整个集群可以有多个。负责单个节点上资源的管理和使用（具体点说是负责计算节点上container的启动、监控和管理，防止Application Master使用多于它申请到的计算资源）。NM有以下作用
4. ApplicationMaster 每个应用有一个，负责应用程序整个生命周期的管理 。
ApplicationMaster 负责协调来自 ResourceManager 的资源，并通过 NodeManager 监视容器的执行和资源使用（CPU、内存等的资源分配）。请注意，尽管目前的资源比较传统（CPU 核心、内存），但未来会带来支持的新资源类型（比如图形处理单元或专用处理设备）。AM有以下作用：
5. Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。Container有以下作用：
剖析MapRece作业运行机制
1、作业的提交
2、作业的初始化
3、任务的分配
4、任务的执行
5、进度和状态的更新
6、作业的完成
简单版工作流程
详细版工作流程
步骤1：用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster、用户程序等。
步骤2：ResourceManager为该应用程序分配第一个Container，并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster。
步骤3：ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控他的运行状态，直到运行结束，即要重复步骤4-7。
步骤4：ApplicationMaster采用轮询的方式通过RPC协议找ResourceManager申请和领取资源。
步骤5：一旦Application申请到资源后，便与对应的NodeManager通信，要求启动任务。
步骤6：NodeManager为任务设置好运行环境，包括环境变量、JAR包、二进制程序等，然后将任务启动命令写到另一个脚本中，并通过运行该脚本启动任务。
步骤7：各个任务通过RPC协议向ApplicationMaster汇报自己的状态和进度，ApplicationMaster随时掌握各个任务的运行状态，从而可以再任务失败时重新启动任务。在应用程序运行过程中，用户可以随时通过RPC协议ApplicationMaster查询应用程序的当前运行状态。
步骤8：应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。
1.YARN的HA
2.hdfs的HA
Namenode和resourcemanager的HA两点最大的不同：
1.ZKFC是作为ResourceManager之中的一个进程，而Hadoop中则是一个外置的守护进程
hadoop1.0到hadoop2.0的变迁
MapRece对任务执行的更多控制（暂时不明白）
1.调度器基本作用
根据节点资源（slot、container）使用情况和作业的要求，将任务调度到各个节点上执行
2.作业调度器考虑的因素
1、作业优先级。作业的优先级越高，它能够获取的资源（slot数目)也越多。Hadoop 提供了5种作业优先级，分别为 VERY_HIGH、HIGH、NORMAL、 LOW、VERY_LOW，通过maprece.job.priority属性来设置，或者用JobClient的setJobPriority()方法来设置。
2、作业提交时间。顾名思义，作业提交的时间越早，就越先执行。
3、作业所在队列的资源限制。调度器可以分为多个队列，不同的产品线放到不同的队列里运行。不同的队列可以设置一个边缘限制，这样不同的队列有自己独立的资源，不会出现抢占和滥用资源的情况
3.Hadoop的自带作业调度器
4.如何配置使用调度器？
将其JAR文件放到Hadoop的类路（classpath）
然后设置mapred.jobtracker.taskScheler属性（yarn.resourcemanager.scheler.class）值为org.apache.hadoop.yarn.server.resourcemanager.scheler.capacity.CapacityScheler
Application Master决定如何运行构成MapRece作业的各个任务。如果作业很小，就选择在与它同一个JVM上运行任务
什么样的作业称为小作业（又叫Uber任务或小任务）？
默认情况下，小作业指小于10个mapper且只有一个recer且输入大小小于HDFS块的任务。
涉及属性配置如下：
6. 如何查看yarn队列的vcore使用量
第二代的maprece框架的TaskScheler就是yarn YARN的编程模型 1：保证编程模型的向下兼容性，MRv2重用了MRv1的编程模型和数据处理引擎，但运行环境被重写。 2：编程模型与数据处理引擎 maprece应用程序编程接口有两套：新的API
7. 如何编写YARN应用程序
步骤1 获取ApplicationId。客户端通过RPC协议ClientRMProtocol向ResourceManager发送应用程序提交请求GetNewApplicationRequest，ResourceManager为其返回应答GetNewApplicationResponse，该数据结构中包含多种信息，包括ApplicationId、可资源使用上限和下限等。
步骤2 提交ApplicationMaster。将启动ApplicationMaster所需的所有信息打包到数据结构ApplicationSubmissionContext中，主要包括以下几种信息：
(1) application id
(2) application 名称
(3) application优先级
(4) application 所属队列
(5) application 启动用户名
(6) ApplicationMaster对应的Container信息，包括：启动ApplicationMaster所需各种文件资源、jar包、环境变量、启动命令、运行ApplicationMaster所需的资源（主要指内存）等。
客户端调用ClientRMProtocol#submitApplication(ApplicationSubmissionContext)将ApplicationMaster提交到ResourceManager上。
（ResourceManager收到请求后，会为ApplicationMaster寻找合适的节点，并在该节点上启动它）。
客户端可通过多种方式查询应用程序的运行状态，其中一种是调用RPC函数ClientRMProtocol#getApplicationReport获取一个应用程序当前运行状况报告，该报告内容包括应用程序名称、所属用户、所在队列、ApplicationMaster所在节点、一些诊断信息、启动时间等。
（2）编写ApplicationMaster
ApplicationMaster需要与ResoureManager和NodeManager交互，以申请资源和启动Container，期间涉及到多个数据结构和两个RPC协议。具体步骤如下：
步骤1 注册。ApplicationMaster首先需通过RPC协议AMRMProtocol向ResourceManager发送注册请求，该数据结构中包含ApplicationMaster所在节点的host、RPC port和TrackingUrl等信息，而ResourceManager将返回，该数据结构中包含多种信息，包括该应用程序的ACL列表、可资源使用上限和下限等。
步骤2 申请资源。根据每个任务的资源需求，ApplicationMaster可向ResourceManager申请一系列用于运行任务的Container，ApplicationMaster使用ResourceRequest类描述每个Container（一个container只能运行一个任务）：
1） Hostname 期望Container所在的节点，如果是“*”，表示可以为任意节点。
2） Resource capability 运行该任务所需的资源量，当前仅支持内存资源。
3） Priority 任务优先级。一个应用程序中的任务可能有多种优先级，ResourceManager会优先为高优先级的任务分配资源。
4） numContainers 符合以上条件的container数目。
一旦为任务构造了Container后，ApplicationMaster会使用RPC函数AMRMProtocol#allocate向ResourceManager发送一个AllocateRequest对象，以请求分配这些Container，AllocateRequest中包含以下信息：
1）Requested containers 所需的Container列表
2）Released containers 有些情况下，比如有些任务在某些节点上失败过，则ApplicationMaster不想再在这些节点上运行任务，此时可要求释放这些节点上的Container。
3）Progress update information 应用程序执行进度
4）ResponseId RPC响应ID，每次调用RPC，该值会加1。
ResourceManager会为ApplicationMaster返回一个AllocateResponse对象，该对象中主要信息包含在AMResponse中：
1）reboot ApplicationMaster是否需要重新初始化.当ResourceManager端出现不一致状态时，会要求对应的ApplicationMaster重新初始化。
2）Allocated Containers 新分配的container列表。
3）Completed Containers 已运行完成的container列表，该列表中包含运行成功和未成功的Container，ApplicationMaster可能需要重新运行那些未运行成功的Container。
ApplicationMaster会不断追踪已经获取的container，且只有当需求发生变化时，才允许重新为Container申请资源。
步骤3 启动Container。当ApplicationMaster（从ResourceManager端）收到新分配的Container列表后，会使用RPC函数ContainerManager#startContainer向对应的NodeManager发送ContainerLaunchContext以启动Container，ContainerLaunchContext包含以下内容：
1）ContainerId Container id
2）Resource 该Container可使用的资源量（当前仅支持内存）
3）User Container所属用户
4）Security tokens 安全令牌，只有持有该令牌才可启动container
5）LocalResource 运行Container所需的本地资源，比如jar包、二进制文件、其他外部文件等。
6）ServiceData 应用程序可能使用其他外部服务，这些服务相关的数据通过该参数指定。
6）Environment 启动container所需的环境变量
7）command 启动container的命令
ApplicationMaster会不断重复步骤2~3，直到所有任务运行成功，此时，它会调用AMRMProtocol#finishApplicationMaster，以告诉ResourceManage自己运行结束。
【注意】 整个运行过程中，ApplicationMaster需通过心跳与ResourceManager保持联系，这是因为，如果一段时间内（默认是10min），ResourceManager未收到ApplicationMaster信息，则认为它死掉了，会重新调度或者让其失败。通常而言，ApplicationMaster周期性调用RPC函数AMRMProtocol#allocate向其发送空的AllocateRequest请求即可。
8. YARN知识点总结
如果把大数据Hadoop集群当作一台计算机, 那么
HDFS = 磁盘
YARN = 任务调度器+资源管理器
所有任务都是运行在Yarn上
Yarn分为两个大的模块: ResourceManager NodeManager
运行在master机器上, 用于分配资源
两个模块
Scheler 负责资源分配
ApplicationsManager 负责应用管理.
RM不负责启动container, 而是告诉AM哪些container可用, 由AM向NM发起请求来启动container.
RM负责启动AM, 并且在应用程序失败时, 重启AM.
运行在slave机器上, 用于执行任务
container是计算资源, 代表任务执行时所分配的cpu,内存等资源.
每个任务都是在container里执行的.
执行过程
client首先向RM提交应用, 请求一个AM实例.
RM找到一个可以启动container的NM, 并启动一个AM实例
AM向RM注册之后, client就可以从RM查找到AM的详细信息, 可以和AM建立联系.
AM向RM的Scheler发送resource-request请求, Scheler返回资源描述, 包括资源名称(NM的地址,rack等)、优先级、资源需求和container集合
AM向对应的NM发起container-launch-specification来启动container
应用程序在container中运行, 并把进度、状态等信息通过application-specific协议发送给AM
应用程序执行完毕, AM向RM注销, 并回收对应的container
scheler是个可插拔的组件, Yarn常用3种scheler
FIFO Scheler
完全先进先出, 按照提交的先后顺序. 大任务会堵塞小任务. 不适合共享集群
Capacity Scheler
为每个团队分配单独的队列, 每个队列分配对应的资源. 每个队列内部使用FIFO方式.
如果资源不够, 可以使用其他队列释放出来的资源, 但是需要设置队列能够占用的最大资源, 防止队列资源占用过高.
Fair Scheler
根据权重来分配各队列可以使用的资源.
如果一个队列没有任务, 那么这个队列的资源可以被其他队列使用.
否则按照设置好的权重来分配队列的可用资源.
没有设置权重的队列则使用平均分配的方式分配资源
抢占preemption
为了执行任务, 把超出自己份额的应用的container杀掉, 用来执行新提交的任务.
Node Status: Node Manager和Resource Manager之间保持心跳, 并发送资源使用情况给RM.
9. Yarn 队列设置
设置：yarn.resourcemanager.scheler.class
Capacity Scheler，定义flink、default两个队列，各自50%
10. hadoop2.4版本中yarn的web管理界面不能查看作业状态！！！求助
no router to host...ssh方面的错误，如果你的集群安装的没有错误的话
ssh免登陆都可以的话（你的肯定是不行的）
请关闭你的集群节点的防火墙，并且正确安装ssh免登陆