随着Hadoop的流行，其局限性也在一定程度体现，各大公司也在hadoop上做了很多修改，下面是雅虎对Hadoop下一代的重构计划。

　　回顾

　　海量数据业务中，使用数量少规模大的集群比使用数量多规模小集群的成本低。规模大的集群能处理大数据集，同时也能支持更多的任务和用户。

　　Apache Hadoop MapReduce框架大约能够支持4000台机器。下一代的Apache Hadoop MapReduce框架会纳入一个通用的资源调度器，用户可以自定义每一个应用程序的执行。相比早期，故障时间在大规模高可靠性的集群中代价更高，更大规模的集群上保证安全性和多重用户才能支持大规模的用户。新的架构要加强它的创新性，灵活性和硬件使用。

　　背景

　　当前Hadoop MapReduce框架的实现表明了它的使用年限。

　　从目前集群的规模和其工作负荷的变化趋势来看，MapReduce 的JobTracker需要大规模的调整来修复它在可扩展性，内存消耗，线程模型，可靠性和性能上的缺陷。在过去的5年中，我们做了一些bug的修复，但是最近这些修复的成本越来越高，这表明对框架做出改变的难度越来越大。框架具有缺陷和对框架的补救是可以理解的，也是比较久远的，甚至可以追溯到2007年，这是我们修复MapReduce’s jira的文档：

　　https://issues.apache.org/jira/browse/MAPREDUCE-278.

　　从操作的角度来看，现在的Hadoop MapReduce框架在有任何重要的或者不重要的变化(例如bug修复，性能提升和特性化)时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让集群的每一个用户同时更新;这些更新会让用户为了验证他们之前的应用程序是不是适用新的Hadoop版本而浪费大量时间。

　　需求

　　考虑如何改进Hadoop MapReduce框架时，注意那些高优先级的需求是非常重要的。下一代的MapReduce框架最迫切的需求有以下几个：

• 　　可靠性
• 　　可用性
• 　　可扩展性-超过10000台机器的集群和200000个core
• 　　向后兼容(向前兼容)-确保在下一代的框架上用户的MapReduce应用不做改变依然能够运行。
• 　　变化-能让用户控制Hadoop软件栈的升级
• 　　可预测的潜在因素- 一个用户关心的主要方面
• 　　集群的使用

　　第二等级的需求是：

• 　　对MapReduce支持不同的编程模型
• 　　支持短期的服务

　　从上面给出的要求，需要对Hadoop下层处理数据的公共组件进行重新考虑。事实上，hadoop社区里已经有一些舆论说现在MapReduce框架的架构不能满足上述目标，必须要进行重构，看我们2008年2月在jira上制定的目标。

　　https://issues.apache.org/jira/browse/MAPREDUCE-279.

　　下一代的MapReduce

　　重构根本的思想是将JobTracker两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度/监控。新的资源管理器全局管理所有应用程序计算资源的分配，每一个应用的ApplicationMaster负责相应的调度和协调。一个应用程序无非是一个单独的传统的MapReduce任务或者是一个DAG(有向无环图)任务。ResourceManager和每一台机器的节点管理服务器能够管理用户在那台机器上的进程并能对计算进行组织。事实上，每一个应用的ApplicationMaster是一个详细的框架库，它结合从ResourceManager获得的资源和NodeManager协同工作来运行和监控任务。

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

　　资源管理器是基于应用程序对资源的需求进行调度的;每一个应用程序需要不同类型的资源因此就需要不同的容器。资源包括：内存，CPU，磁盘，网络等等。可以看出，这同现在Hadoop Mapreduce固定类型的资源使用模型有显著区别，它给集群的使用带来负面的影响。资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序。调度插件可以基于现有的能力调度和公平调度模型。

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

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

　　架构

　　

　　和当前Hadoop Mapreduce框架实现的逐一对比和改进

　　可扩展性

　　将集群资源的管理，应用程序的生命周期，和对各个组件的管理相分离，这使得架构更好更优雅。Hadoop MapReduceJobTracker花费相当一部分时间和效率来管理应用的生命周期，这是导致软件遭难的主要原因，将它转移到每一个具体的应用程序上有显著的意义。

　　可扩展性和目前硬件发展趋势的关系特别重要，现在的Hadoop MapReduce已经能被部署到了4000台机器的集群上。但是，2009年的4000台最好的机器(8核，16G RAM，4TB硬盘)只是2011年4000台机器(16核，48G RAM，24TB硬盘)能力的一半。因此，运营成本的提升迫使我们使用超过6000台机器来组建更大的集群。

　　可用性

　　l-资源管理器使用Apache的ZooKeeper来处理失败情况，当资源管理器出错时，根据ZooKeeper里存储的集群状态可以很快的从备份机恢复。资源管理器会重启队列里和正在运行的所有应用。

　　lApplicationMaster-下一代的MapReduce支持对ApplicationMaster设置检查点的能力。MapReduce ApplicationMaster能够从失败的状态中恢复，因为它先前已经将自己的状态存到HDFS里。

　　线兼容性

　　下一代的MapReduce使用线兼容模型使不用版本的服务器和客户端能互相通信。在未来的版本，这个特性能使集群轮替式升级–一个操作上的优势。

　　创新和灵活性

　　改进架构的一个主要的好处是让MapReduce有效的变成了一个系统级的资源库。计算框架(资源管理器和节点管理器)完全是非商业化的，并且MapReduce的特性也是免费的。

　　这个特性允许端用户在同一集群上同时使用不用版本的MapReduce。这也允许不同的应用使用不同版本的MapReduce ApplicationMaster和运行环境。这样为应用的bug修复提供了很大的灵活性，增强的功能和新特性也不需要对整个集群升级。它同时也允许端用户按照自己的计划升级他们的MapReduce应用的版本，可以显著的增强集群的操作性。

　　运行用户自定义的MapReduce任务而不影响软件的稳定性能够促进创新。它还可以带来其他方面的特性，例如能够将用户版本的MapReduce程序引入在线Hadoop模型而又不影响其他用户。

　　集群的使用

　　下一代的Mapreduce的资源管理器使用一个通用概念给每个应用调度和分配资源。

　　集群的每一个机器概念上由很多资源组成，例如内存，CPU，I/O，带宽等等。基于应用程序定义的资源请求类型，每一个机器都是可被取代的，也可以当作容器分配给应用程序。同一个机器上可以支持多个用户，此机器上的一个容器是一组进程的集合，它独立于其他容器。

　　因此，它可以废弃现在的固定类型map的表示方法，并能减少Mapreduce程序的资源使用(slot)。固定类型的资源在不同时间段对集群的使用有显著的负面影响，它使map或者是reduce的资源匮乏。

　　除MapReduce以外还支持其他的编程模型

　　下一代的MapReduce提供一个完全免费的计算框架来支持Mapreduce和其他的编程模型。

　　框架允许用户通过实现一个自定义的ApplicationMaster来支持任何特定的框架，此ApplicationMaster能够从ResourceManager请求资源，并且这些资源满足一些常用的特性，例如隔离性，容量保证等等。

　　总之，它要支持多种编程模型，例如Mapreduce，MPI，Master-Worker和迭代模型，在同一个Hadoop集群上能对不用的应用程序运用合适的框架。这对应用(例如K-Means，Page-Rank)来说非常重要，用户自定义的应用也许会超过MapReduce应用一个数量级。

　　总结

　　Apache Hadoop，特别是Hadoop MapReduce对于处理海量数据集是一个十分成功的开源项目。我们的目的是重构Hadoop MapReduce来解决框架现有的问题，提高框架的可用性，加强集群的利用率，同时提供对多个编程模型的支持，也推进未来的变革。我们会协同Apache Hadoop社区来完成这个任务，同时将Apache Hadoop推进到下一个大数据量的时代。

　　原文链接：http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/