YARN

YARN的基本思想是将JobTracker的两个主要功能（资源管理和作业调度/监控）分离，主要方法是创建一个全局的ResourceManager（RM）和若干个针对应用程序的ApplicationMaster（AM）。

MapReduceV1时代

那时候，我们还没有YARN。Job Tracker负责一些列的工作。

1. 首先用户程序(JobClient)提交了一个job,job的信息会发送到Job Tracker,Job Tracker是Map-reduce框架的中心，他需要与集群中的机器定时通信heartbeat,需要管理哪些程序应该跑在哪些机器上，需要管理所有job失败、重启等操作。
2. TaskTracker是Map-Reduce集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。
3. TaskTracker同时监视当前机器的tasks运行状况。TaskTracker需要把这些信息通过heartbeat发送给JobTracker,JobTracker会搜集这些信息以给新提交的job分配运行在哪些机器上。
   
   下面这张图主要是要再次提醒下每个task都拥有一个JVM。HADOOP MR使用的是进程模型（非SPARK）
   

但是随着集群规模个工作负荷的增长，原框架的问题便暴露出来了。

1. JobTracker是Map-reduce的集中处理点，存在单点故障
2. JobTracker完成了太多的任务，造成了过多的资源消耗，当map-reduce job非常多的时候，会造成很大的内存开销，潜在来说，也增加了JobTracker fail的风险，这也是业界普遍总结出老hadoop 的Map-Reduce只能支持4000节点主机的上限。
3. 在TaskTracker端，以map/reduce task的数目作为资源的表示过于简单，没有考虑到cpu/内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM
4. 在TaskTracker端，把资源强制划分为map task slot和reduce task slot如果当系统中只有map task或者只有reduce task的时候，会造成资源的浪费，也就是前面提到过的集群资源利用的问题。
   5.源代码非常难读，因为一个类做了太多的事情，而代码量过多，造成class的任务不清晰，增加bug的修复和版本维护的难读。

MapReduceV2时代

一个典型被YARN管理的集群包含

App Timeline Server （单个服务）
ResourceManager （单个服务，相当于MASTER）
NodeManagers （多个服务，相当于SLAVE）
YARN Clients （若干个客户端库）

如图所示，AM负责向RM申请资源，NM负责监控节点状态和程序运行情况。
一个完整的启动流程如下

1. Client向RM发出请求
2. RM返回一个ApplicationID作为回应
3. Client向RM回应Application Submission Context（ASC）。ASC包括ApplicationID、user、queue，以及其他一些启动AM相关的信息，除此之外，还有一个Container Launch Context（CLC），CLC包含了资源请求数（内存与CPU），job files，安全token，以及其他一些用以在一个node上启动AM的信息。任务一旦提交以后，client可以请求RM去杀死应用或查询应用的运行状态
4. 当RM接受到ASC后，它会调度一个合适的container来启动AM，这个container经常被称作为container 0。AM需要请求其他的container来运行任务，如果没有合适的container，AM就不能启动。当有合适的container时，RM发请求到合适的NM上，来启动AM。这时候，AM的PRC与监控的URL就已经建立了。
5. 当AM启动起来后，RM回应给AM集群的最小与最大资源等信息。这时AM必须决定如何使用那么当前可用的资源。YARN不像那些请求固定资源的scheduler，它能够根据集群的当前状态动态调整。
6. AM根据从RM那里得知的可使用的资源，它会请求一些一定数目的container。This request can be very specific,including containers with multiples of the resource minimum values (e.g., extra memory)。
7. RM将会根据调度策略，尽可能的满足AM申请的container。