ResourceManager和JobTracker有什么区别？为什么hadoop2.0没有RM?

低版本的hadoop下MapReduce处理流程
1、首先用户程序(JobClient)提交了一个job,job的信息会发送到Job Tracker,Job Tracker是Map-reduce框架的中心，他需要与集群中的机器定时通信heartbeat,需要管理哪些程序应该跑在哪些机器上，需要管理所有job失败、重启等操作。

2、TaskTracker是Map-Reduce集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。

3、TaskTracker同时监视当前机器的tasks运行状况。TaskTracker需要把这些信息通过heartbeat发送给JobTracker,JobTracker会搜集这些信息以给新提交的job分配运行在哪些机器上。

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

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的时候，会造成资源的浪