Yarn，又名MRv2，由于Hadoop1的MR计算框架的缺陷应运而生。
1.首先了解下MRv1的体系，主要分为JobTraker和TaskTracker，其中，每当有新的job提交时该job的相关信息就会提交到JobTraker，然后JobTraker就要全程管理这个job，包括启动，失败时重启和针对任务数量分配在合适的TaskTracker中(每个task占用一个对应slot的资源)，另外，TaskTracker还需要周期性反馈这些task的完成情况以及节点的资源状况。也就是说JobTraker既要负责管理所有job的执行(比如失败了需要JobTraker来命令其重启)，还要负责所有job的资源调度(包括分配和监听资源变化)，这给JobTraker带来了很大压力和资源消耗。
而具体的资源分配是：JobTraker会根据各个节点(每个节点管理一个TaskTracker)上的资源状况(maptask slot和reduce slot有多少个)来进行将job的maptask和reducetask分配到合适的位置，这样的TaskTracker也非常的死板，有如下两个缺点：
①生硬的把资源分成map和reduce两种类型，不能灵活转换，如果一个节点上只剩下reduce slot的资源，就无法执行maptask，浪费了这些资源
②slot的资源过于固定，不灵活，没有考虑每个(map or reduce)task的区别，前面MR我们也有讲到，虽然每个maptask都是处理一个split分片，但是map的运算逻辑不同可能导致所需要的资源差异很大，比如有些内存消耗很大的maptask都分配到了同一个TaskTracker，就会造成内存溢出
于是，我们来看下Yarn做了什么变化吧：
1.将JobTraker分成全局资源管理层面的ResourceManager(RM，全局一个)和作业执行层面的Application Master(AM,一个job对应一个，负责每个作业的具体执行，以及资源调度，比如根据具体的job拆分成多个maptask和reducetask，然后和RM去申请资源，RM根据S)。
2.将TaskTraker改为NodeManager(NM，定期向RM汇报资源状况，维护该节点中container的状态)，且资源单位不再是死板的map/reduce slop，而是可以动态变化的Container，Container即可以给map用也可以给reduce使用，是按需分配的(只有两种需求：CPU和内存)，比如内存型就分配多些内存资源
接下来，具体介绍下流程：
①客户发出请求，RM收到之后，让其中的Applications Manager(AsM)和该job对接，包括先提交该job，然后负责监听该任务后续的状态(比如坏了要重启，完成了要释放资源)，以及和Scheduler协商来给该job其分配一个启动的Application Master的资源(container)。
②接着上面的，AsM根据Scheduler中的资源队列情况，首先会找到一个有资源的合适的Node(可能是距离该client比较近的，我猜的，也可能随便找个)，然后在该Node申请一个container用于开启对应job的Application Master(AM，负责该job生命周期内所有工作，包括以后的资源申请即分配，任务分发与执行)
③AM启动之后，会和RM的AsM汇报并注册，然后就是根据自己实际的到的任务进行资源申请。(申请不是一次性申请完毕的，而是通过轮询RM中的Scheduler以一步步获取资源，比如5个Maptask，和2个reducetask，先申请map，之后申请reduce)
④RM接收到申请，会根据Scheduler中的资源队列以及各个task的实际情况，来给改job在合适的NM上分配container，这里很关键，平常我们都习惯说“AM向RM获取资源，如果在一个NM上资源不足就换一个NM”，这是没错，但是过于笼统，很容易让人误以为：
Ⅰ：AM创建之后一定要向RM继续申请资源，这其实并不是的，如果AM所处的容器本身就可以解决该问题，那么就直接在该处jvm上运行然后返回结果就可以了
Ⅱ：AM名下的N个任务仿佛没有区别，只要资源队列中有node含有足够的资源就往里面扔(即在该node创建container)，其实也不然：《Hadoop权威指南》的4.1.1资源请求 中说到，yarn有个灵活的资源请求模型，会尽量让task的执行“本地化”运算，尤其是maptask，假设其处理的split分片的数据分布在节点M，AM会优先轮询资源队列Scheduler中M节点是否有足够的资源，没有就查看其他副本节点，再没有就查看同机架上的，总之都是为了节省数据传输的带宽。
⑤一旦一个task分配到container了，就可以执行它自己的任务了，此外每个task还要保持和AM的联系，让AM掌握清楚自己底下的task的状况，以便出错时的处理
⑥当所有task都成功完成，AM也完结了，向RM汇报注销并关闭自己以及释放相应的资源
