1.yarn的介绍
YARN（Yet Anthor Resource Negotiator），是Hadoop 的子项目，为分离Hadoop2.0资源管理和计算组件而引入。负责资源管理分配。yarn具有通用性，支持其他的分布式计算模式。
支持：mapreduce、tez、hbase等等
2.yarn的架构
ResourceManager：主角色（一个）
applications manager（ASM，针对所有应用管理器）和scheduler（调度器）组成
①处理客户端请求
②监控NodeManager
③启动或监控ApplicationMaster（每一个应用都会生成一个）
④资源的分配与调度
NodeManager：从角色（多个）
心跳向resourceManager发送cpu内存等资源情况
计算节点，启动maptask、reducetask
①管理单个节点的资源
②处理来自ResourceManager的命令
③处理来自ApplicationMaster的命令
ApplicationMaster：（针对某一个应用管理，多个，在container中启动）
①为应用程序申请资源并分配给内部的任务
②任务的监控与容错
Container：（在nodemanager中启动）
Container是yarn中的资源抽象，封装了节点上的多维度资源，内存、cpu、磁盘、网络等
3.yarn的工作机制以及任务流程
1）client调用JobSubmiter.submitJobInternal（）
2）rpc调用yarn方法获取application id
3）客户端获得application id
4）客户端判断输入输出目录，有错误报错，无错计算分片
5）客户端将jar、xml配置文件、分片信息上传到hdfs
6）客户端调用资源管理器方法提交application到集群，asm收到job请求后将job加入scheduler队列
7）如果集群有充足的资源启动一个容器的话，scheduler开始调度资源，决定在某一个nodemanager启动容器container，nodemanager收到启动容器命令后启动一个container
8）容器中启动mrappmaster，app master对作业做初始化，创建如果簿记对象，用于记录将来各task回报的task运行进度、状态
9）从hdfs获取分片信息，app master确认启动maptask、reducetask的数量
10）app master为maptask向Resource Managerzhong 的scheduler申请资源，默认内存1024,1虚拟核，并告知maptask分片位置
11）scheduler收到请求后遵循数据本地化的原则，若分片所在节点有足够资源启动容器，就在该节点启动，如果没有尝试找最近的节点启动容器（移动计算不移动数据）。然后容器启动yarnchild进程，准备运行map task的逻辑
12）资源本地化，将jar、xml等资源下载到容器所在节点，启动map task，最终生成一个结果文件（分区有序）tip：app master为第一个申请资源后，即可对其他的maptask申请资源
13）当5%的map task完成， app master可以为reduce task申请资源，流程与maptask申请资源一致（reduce不需要遵循数据本地化，数据是从maptask拉取的），
app master向scheduler申请-》scheduler返回结果-》app master根据结果通知nodemanager-》nodemanager启动容器-》启动yarnchild进程
tip：一个nodemanager资源充足的情况下 会有多个容器（maptask、reducetask）
14）资源本地化-》运行reduce task-》copy merge sort -》 调用 reduce -》生成文件part-r-0000写入hdfs
关于任务进度：
每个task运行时，当状态发生改变，会通知mrappmaster并记录
mrappmaster有个全局视图：知道map阶段、reduce阶段完成的百分比
client每秒询问一下appmaster，并打印
reduce task轮询appmaster，看有没有map task完成，若有，则从此map task拉取分区数据
4.yarn的任务调度器
资源调度器是YARN最核心的组件之一，是一个插拔式的服务组件，负责整个集群资源的管理和分配。YARN提供了三种可用的资源调度器：FIFO、Capacity Scheduler、Fair Scheduler
1.优先队列调度器（FIFO）
把应用按提交顺序排成一个先进先出的队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，满足后再给下一个分配，一次类推。
FIFO是最简单也是最容易理解的调度器，也不需要任何配置，但是它不适用与共享集群。大的应用会占用所有集群资源，导致其它应用被阻塞。
2.容量调度器（Capacity Scheduler）
Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列的资源了，在一个队列内部，资源调度是采用的FIFO策略。
一个job可能使用不了整个队列的资源，这个队列中运行多个job，如果资源够用，那么久分配给这些job。如果资源不够用，Capacity调度器人分配额外的资源给这个队列，这是“弹性队列”的概念。
在正常的操作中，Capacity调度器不会强制释放Container，当一个队列资源不够用时，这个队列只能获取其他队列释放后的Container资源。我们可以为队列设置一个最大资源使用量，以免这个队列过多的占用空闲资源，导致其他队列无法使用这些空闲资源，这是“弹性队列”需要权衡的地方。
3.公平调度器（Fair Scheduler）
公平调度器的设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数设置）。公平调度器可以在多个队列间工作。假设有两个用户A和B，他们分别拥有一个队列。当A启动一个job而B没有job时，A会获得集群的全部资源，B启动job后，A会继续运行，不过会把一半资源还给B，如果B此时又启动一个job并且其它的job也还在运行，则这个job与B的第一job共享B这个队里的资源，占用B的一半资源，也就是整个集群的1/4的资源，而此时A的job还是占用一般资源，结果就是资源最终在两个用户间平等共享。