Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而mapreduce等运算程序则相当于运行于操作系统之上的应用程序。
在hadoop1.0中有一些弊端，比如hdfs元数据信息保存的单节点故障，并且任务计算框架只能使用mapreduce，而且造成了任务管理器的压力过大，因此在hadoop2.0中加入了yarn资源统一管理的机制，不仅解决了元数据单节点故障问题（双namenode）而且实现了元数据的实时热备（共享机制JournalNode），在hdfs和mr之间加入了yarn，统一协调资源。
主要角色：
Resource Manager：资源管理器，负责整个集群的资源分配，只在NameNode上。RM包括两个组件，一个是Application Manager，用于管理集群中的所有用户作业；另一个是Scheduler。
Node Manager：节点管理器，负责在单个节点上启动和监控Container，在所有节点上都有一个。向RM负责并保持心跳。
Container：容器负责任务的具体执行，可以是一个进程，也可以是一个Linux cgroup，可以配置，每个容器都有资源限制（CPU，内存），一个Container代表一个节点上的一组资源。
Application Master：对于向Yarn提交的应用，Application Master是这个应用的中枢，负责监控应用的信息。Application Master自身也在一个Container里，与Node Manager协同工作来执行/监控Container。Application Master会通过心跳与Resource Manager建立联系，申请资源；心跳应答中，Application Master会收到绑定了一组资源的Container租约。
RM（Resource Manager）主要负责的是在不同应用之间调度资源，AM(Application Master)负责应用的进程状态信息的监控和容错等。
1.资源是怎么请求的？
步骤：
>1. 客户端联系资源管理器，请求运行一个 application master 进程;
>2. 资源管理器找到一个能够运行这个进程的容器;
>3. application master 一旦运行起来，可能在所在容器简单的运行一个计算，把结果返回给客户端，或者向资源管理器请求更多的容器;
>4. 请求更多的容器。
Yarn 本身不会为应用的各部分（客户端、master 和进程）间提供通信手段，大多数重要的yarn应用使用某种形式的远程通信机制（hadoop 的RPC层）来向客户端传递状态更新和返回结果，这些通信机制专属于应用的。
Yarn 应用可以运行在任意时刻提出资源申请，例如，可以在最开始提出所有的请求，或者为了满足不断变化的应用需要，动态提出请求，spark属于第一种，在集群上申请固定的资源，map reduce属于第二种，不断变化请求资源。
3.与MR1对比是怎样的，有什么优点1.一个用户作业对应一个应用，map reduce就是采用这种模型；
2.作业的每个工作流或每个用户对话对应一个应用。这种方法要比第一种高效，因为容器可以在不同作业间重用，并且可能缓存中间数据，spark就是采用这种模型；
3.多个用户共享一个长期运行的应用。这种应用通常作为一种协调者的角色在运行，像impala使用这种模型提供了一个代理应用，impala 守护进程通过该代理请求集群资源，避免了启动新application master 带来的开销，获得低延迟的查询响应。
4.Yarn的调度器
组成对比如上图所示 ，那有什么优点呢？
可扩展性，MR1当节点达到4000，任务数达到40000时，会遇到可扩展性瓶颈，瓶颈源自jobtracker 必须同时管理作业和任务。yarn利用其资源管理器和 application master 分离的架构优点客服了这个局限性，可以扩展到上万个节点及10万个任务;
利用率，在MR1中，每个tasktracker 都配置若干个固定长度的slot,这些slot都是静态分配的，分为map slot 和reduce slot ，map slot只能运行map 任务，reduce slot只能运行 reduce 任务；yarn中，一个节点管理器可以管理一个资源池，而不是指定固定数目的slot，像在MR1中map slot 空闲，而reduce slot 不足时，reduce 运行只能等待资源释放。
可用性，当服务守护进程失败时，通过另一服务守护进程复制接管工作所需的状态以便继续提供服务，以提高高可用性（HA）,然而jobtracker内存中大量快速变化的复杂状态，使得改善服务获得高可用性变得困难，而yarn 中分而治之的管理方式，对于资源管理器及application master 都提供了高可用性。
多租户，yarn采用的是租户方式的环境，mr只是yarn上的其中一种租户，可以运行多个版本mr以达到升级版本更好管理。
>1 FIFO（先进先出）调度，不需配置，不适合共享集群，因为会被大的应用占用整体资源；
>2 容器调度器（Capacity Scheduler），使用独立的专门的队列,保证小作业已提交就可以启动，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。
一般单个作业使用的资源不会超过其队列容量。然而，如果队列中有多个作业，而且队列资源不够用了呢，这时如果仍然有可用空闲资源，那么容器调度器可能会将空余的资源分配给队列中的作业，哪怕这会超过队列容量。这称为“弹性队列”，正常操作时，容量调度器不会通过强行中止来抢占容器（container），因此如果一个队列一开始资源够用，然后随着需求增长，资源开始不够用了时，那队列只能等其他队列释放容器资源，缓解这种情况的方法是，为队列设置一个最大容量限制，这样这个队列就不会过多侵占其他队列的容量，当然这样做是以牺牲队列弹性为代价的，因此需不断尝试和失败中找一个合理的折中。
>3 公平调度器(Fair Scheduler)，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
那如果在队列之间公平共享的呢?
如果有AB两个用户，分布拥有自己的队列。
1.A队列启动一个作业，B没有作业，A会分配到全部可用的资源，
2.当A的作业仍然在运行时，B启动一个作业，一段时间后，每个作业都用到了一半的集群资源，
3.如果B启动了第二个作业，且其他作业仍然在运行，那么第二个作业将和B的其他作业共享资源，因此B的每个作业将占用4分之一的集群资源，A仍然占用一半的集群资源。
