Yahoo二月份在博客上发表的一篇关于Hadoop MapReduce框架改进的文章，大概翻译了一下。
原帖地址：http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/
========================================
重构后的框架架构如下图所示：
重构MapReduce框架的基本的思想是将JobTracker的两个主要功能，资源管理和作业调度监控，分解为独立的模块。ResourceManager负责对应用(application)计算资源的分配，对于每一个应用，ApplicationMaster负责应用的调度和协作。一个应用可以是一个传统的MapReduce作业，也可以是又作业组成的DAG。ResourceManager和每个节点上运行的负责管理用户进程的NodeManager，共同组成计算框架。ApplicationMaster一个与此框架适用的类库，负责与ResourceManager协商资源，协同NodeManager执行监控任务。
ResourceManager支持多级应用队列，可以为这些队列指定一定资源配额。ResourceManager是一个纯粹的调度器，不负责应用运行状态的监控，也不负责软件或硬件造成应用失败后任务的重启。
ResourceManager的调度功能是基于应用资源请求量的，每个应用会有多种资源请求类型，不同类型的资源被封装到资源容器(container)中。资源的请求包括对内存，CPU，硬盘，网络等的请求。注意这和以前的基于资源槽slot模型有着很大的变化，资源槽模型给系统的利用率带来了很大的负面影响。
ResourceManager有一个调度策略插件，负责将集群中的资源分配到不同的资源队列中。调度策略插件可以基于现有的CapacityScheduler 和FairScheduler进行设计。
NodeManager运行在集群上的每一个节点上，负责启动应用容器，监控资源的利用情况，将利用情况报告给资源调度器。
ApplicationMaster负责和资源调度器协商资源，启动任务，跟踪任务运行状态和任务完成进度，处理任务失败。
将资源的管理和应用运行周期的跟踪分离后形成的系统具有更好的可扩展性。原来的Hadoop MapReduce框架中的JobTracker耗费了大量的资源跟踪应用生命周期，这是造成软件失误的重要原因。
ResourceManager使用了一个更通用的概念来表示计算资源。一个容器(container)是一组在逻辑上独立的进程集合，提供了很强的多租户支持。
下一代MapReduce支持MapReduce之外的编程模式，框架允许用户自定义ApplicationMaster。