第二代MapReduce阶段解析

MR1存在的问题：
1、JobTracker 是 Map-reduce 的集中处理点，存在单点故障。

2、JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。

3、在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单（map数大或reduce数大，说明这个作用大），没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM内存溢出。

4、在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot（内存槽）, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是集群资源利用的问题。

重构根本思想是将JobTracker 两个主要的功能分离成单独的组件，这两个功能是资源管理（ResourceManager）和任务调度/监控（ApplicationMaster）。

ResourceManager全局管理所有应用程序计算资源的分配，每一个应用的 ApplicationMaster 负责相应的调度和协调。ResourceManager 和每一台机器的Node Manager能够管理用户在那台机器上的进程并能对进行计算。

事实上，每一个应用的 ApplicationMaster 是一个详细的框架库，它结合从 ResourceManager 获得的资源和 NodeManager 协同工作来运行和监控任务。

上图中 ResourceManager 支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲它就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪（JobTracker有做）。同样，它也不能因为重启或硬件错误造成运行任务的失败。

ResourceManager 是基于应用程序对资源的需求进行调度的，每一个应用程序需要不同类型的资源因此就需要不同的容器（Container）。资源包括：内存，CPU，磁盘，网络等等。

RM提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序。调度插件可以基于现有的容量调度和公平调度模型。

上图中 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向RM汇报。

每一个应用的 ApplicationMaster 的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败原因。

Yarn对比MR1的优势
设计上大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的进程分布式化了（ApplicationMaster），更安全。

在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的应用，让更多类型的编程模型能够跑在 Hadoop 集群中。

对资源的表示以内存为单位 ，比之前容易剩余 （map数、Reduce数）slot 数的方式更合理。没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。

MR1中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。

Container 是 Yarn 为了将来作资源隔离而提出的一个框架（逻辑概念）。