本文转自“董的博客”,完整文章请戳进去看!
背景
随着集群规模和负载增加,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)将可解决该问题。