最近雅虎开发者博客发了一篇介绍 Hadoop 重构计划 的文章。他们发现当集群的规模达到 4000 台机器的时候，Hadoop 遭遇到伸缩性的瓶颈。目前 Hadoop 各个模块的紧耦合使得在现有设计的基础上的继续改进举步维艰。这一点早已在社区内达成共识，目前他们正准备开始对 Hadoop 进行重构。
新架构的主要思想是把原来 JobTracker 的功能一分为二：ResourceManager 管理资源的分配，ApplicationMaster 管理任务监控和调度。ResourceManager 与原有的 JobTracker 类似，作为整个集群的控制中心；而 ApplicationMaster 则是每个 application 都有一个单独的实例，application 是用户提交的一组任务，它可以由一个或多个 job 组成。每台 slave 运行一个 NodeManager 实例，功能类似于原来的 TaskTracker。
雅虎的博客已经对新架构的优势作了全面的介绍，这里只列出几点我个人比较关注的：
1、层次化的管理
目前 Hadoop 的资源管理和任务调度都是在 JobTracker 中进行的，它需要复制所有 task 的资源分配和调度。而 task 是非常微观的调度单位，通常每个 job 都会产生成百上千个 task，而系统同一时刻又会有大量的 job 同时运行，这让 JobTracker 的管理负担变得非常繁重。新架构将这一管理任务下放到各个 ApplicationMaster，ResourceManager 只管理每个 application 的资源分配。这样即使系统中存在很多 application，ResourceManager 的负担也能控制在一个合理的程度；这也是新架构最大的优势。
2、ApplicationMaster 应该在 Master 还是 Slave 上运行？
新架构实际上将管理和调度的任务转移到 ApplicationMaster 上来，如果 ApplicationMaster 所在的节点挂掉，整个任务都需要重做。原来 JobTracker 可以跑在相对稳定的 Master 上，出错概率低；现在 ApplicationMaster 跑在好些 Slave 上，出错的概率就非常高了。而且新架构打破了原来简单的 Master-Slave 模型，节点之间的通讯和依赖关系变得更加复杂，增加了网络优化的难度。如果把 ApplicationMaster 全都放在 Master 上执行，则 Master 的负担会非常重（需要处理各种持续性的 heartbeat 和爆发性的如 getTaskCompletionEvents 这样的 rpc 请求），不过这个问题可以通过分布式的 Master 解决（Google 已经实现）。
3、资源管理方式
原来单纯地以简单静态的 slot 作为资源单位确实不能很好描述集群的资源状况。新架构将更细粒度地控制 CPU，内存，磁盘，网络这些资源。每个 task 都将在 Container 中执行，并只能使用其所分配到的系统资源。资源的分配可以用静态估计动态调整的方式实现。
4、支持其他编程模型
由于任务的管理和调度都由 ApplicationMaster 进行，ApplicationMaster 又相对独立于系统的其他模块，用户甚至可以部署自己的 ApplicationMaster，实现对其他编程模型的支持。这使得其他不大适合用 MapReduce 实现的应用程序也能在同一个 Hadoop 集群中运行。