引入：

Hadoop2.0中提供的一套用于资源管理和任务调度的机制，也正因为这套机制的出现，导致Hadoop1.0和Hadoop2.0不兼容 。

yarn出现的原因：

• 内因：在Hadoop1.0中，JobTrakcer既要对外接收任务，还要对内管理TaskTracker以及分配任务，并且JobTracker还需要监控TaskTracker的任务执行情况，这就导致JobTracker要负责的任务非常多，从而成为整个集群的性能瓶颈。并且Hadoop1.0中，JobTracker只允许存在一个，就意味着存在单点故障。在Hadoop1.0的官方文档中，给定，一个JobTracker最多能管理4000个TaskTracker，多一个都会导致效率成倍下降甚至导致JobTracker的崩溃
• 外果： Hadoop作为大数据的基本生态框架，有很多的计算框架(Pig，Tez，Spark等)基于它来使用。在Hadoop1.0中，各个计算框架之间会直接各自抢占Hadoop的资源，那么就导致框架之间的资源占用会产生冲突

job执行流程：

1. 客户端提交Job任务，将任务提交到ResourceManager中的ApplicationsManager上
2. ApplicationsManager收到任务之后，会先临时将任务存储到自带的队列中，然后等待NodeManager的心跳
3. 当ApplicationsManager收到心跳之后，会将任务在心跳响应中来返回，并且要求对应的NodeManager来开启一个ApplicationMaster进程来处理这个Job任务
4. NodeManager收到心跳响应之后，会在本节点内部开启一个进程ApplicationMaster，并且会将Job任务交给这个进程处理
5. ApplicationMaster收到Job任务之后，会将这个Job任务来进行拆分，拆分成子任务(如果是一个MapReduce程序，那么就是拆分为MapTask和ReduceTask)
6. ApplicationMaster拆分完子任务之后，就会给ApplicationsManager发请求申请资源
7. ApplicationsManager收到请求之后，会将请求转发给ResourceSchedular。 ReosurceSchedular在收到请求之后，会将需要的资源封装成一个Container(对资源的描述)对象返回给ApplicationsManger。ApplicationsManager会再将Container对象返回给ApplicationMaster
8. ApplicationMaster收到Container之后，会将资源进行二次分配，分配给具体的子任务。资源分配完成之后，ApplicationMaster就会将子任务分配到具体的NodeManager上，并且会监控这些子任务的执行情况

注意：

1. 每一个Job都会对应一个新的ApplicationMaster，那么意味着一个ApplicationMaster出现故障，不会影响其他任务的执行
2. YARN中的结构：ApplicationsManager管理ApplicationMaster，ApplicationMaster再管理具体的子任务
3. 在YARN中，会给每一个子任务来分配一份资源。默认一份资源包含了1个CPU核+1G内存，也就意味着一个MapTask/ReduceTask执行的时候可以抢占1个CPU核+1G内存
4. ApplicationMaster在要资源的时候会多要。例如默认情况下，副本数量为3，假设有4个MapTask和1个ReduceTask，那么考虑到数据本地化策略，所以ApplicationMaster要的资源数是4*3+1=13份，但是ResourceSchedular在返回资源的时候，不会超额返回，而是会根据实际情况返回 - 核心思想就是"要的多(防止资源分配失败)，给的少(避免资源浪费)"