随着集群规模和负载增加，MapReduce JobTracker在内存消耗，线程模型和扩展性/可靠性/性能方面暴露出了缺点，为此需要对它进行大整修。

需求

当我们对Hadoop MapReduce框架进行改进时，需要时刻谨记的一个重要原则是用户的需求。近几年来，从Hadoop用户那里总结出MapReduce框架当前最紧迫的需求有：

（1）可靠性（Reliability）– JobTracker不可靠

（2）可用性（Availability）– JobTracker可用性有问题

（3） 扩展性（Scalibility）-拥有10000个节点和200，000个核的集群

（4） 向后兼容性（Backward Compatibility）：确保用户的MapReduce作业可无需修改即可运行

（5）  演化（Evolution）：让用户能够控制软件栈的升级，尤其是与Hive，HBase等的兼容。

（6） 可预测的延迟：这是用户非常关心的。小作业应该尽可能快得被调度，而当前基于TaskTracker->JobTracker ping（heartbeat）的通信方式代价和延迟过大，比较好的方式是JobTracker->TaskTracker ping, 这样JobTracker可以主动扫描有作业运行的TaskTracker（调用RPC）（见MAPREDUCE-279）。

（7）集群资源利用率。 Map slot和reduce slot不能共享，且reduce 依赖于map结果，造成reduce task在shuffle阶段资源利用率很低，出现“slot hoarding”现象。

次重要的需求有：

（1）支持除MapReduce之外的计算框架，如DAG，迭代计算等。

（2）  支持受限的，短时间的服务(for example ????)

面对以上这些需求，我们有必要重新设计整个MapReduce数据计算架构。大家已达成共识：当前的MapReduce架构不能够满足我们上面的需求，而双层调度器（Two level Scheduler）将可解决该问题。