近日，Yahoo! Hadoop Map-Reduce开发团队领导Arun Murthy展示了针对Hadoop的重新设计过的核心Map-Reduce架构，旨在简化升级、支持更大的集群、更快的恢复，还要支持除了Map-Reduce以外的其他编程范式。重新设计的Hadoop核心将引擎分割为一个资源管理器，用以支持各种集群计算范式，同时将map-reduce作为一个用户库，组织可以在同一个集群中运行多个版本的map-reduce代码。新的设计非常类似于开源的Mesos集群管理项目——Yahoo!和Mesos对其中的差异进行了评述。
新方案的主要优势在于：
- 可伸缩性：支持6000台机器所构成的集群，每台机器拥有16个核心、48GB的RAM、48TB的磁盘大小、100k的并发任务及10k的并发job。
- 可用性：目前的Job Tracker是单失败点，升级需要停止整个集群才行。
- 敏捷性：新的设计将map-reduce作为一个用户库，这样同一个集群中所运行的job就可以使用不同的版本了。
- 更低的延迟：新的设计考虑到了更快的响应、特别是对于小范围的任务。
- 更好的利用率：毫无疑问，更加精细化的资源与调度模型可以降低资源的浪费。
- 支持多种编程模型：Murthy说Yahoo内部希望支持其他范式的呼声越来越高，如MPI。
此次重新设计的主旨在于将职责划分为通用的集群资源管理系统，同时还有一个针对map-reduce的独立应用master，实际上可以是任何的编程模型。这将替换掉Job Tracker和Task Tracker。资源管理系统包含如下集群范围内的控制器：
- 一个ResourceManager，执行集群范围内的资源调度，如内存、CPU、磁盘、网络等等。
- 一个Scheduler插件，可以针对ResourceManager实现不同的策略（类似于目前的scheduler API，但却拥有不同的接口，并且需要新的实现）。
- 每个应用一个ApplicationMaster（比如map-reduce编程），可以请求资源、追踪进度、处理失败，并且可以保持计算状态。
下一代的MapReduce架构。来自于Yahoo
可以分布于各个worker节点上，有：
- 一个共享的NodeManager，可以访问work节点资源（比如说，通过认证请求并开启任务）。
- 每个应用的Containers（类似于任务），使用本地资源进行计算。
此次重新设计考虑到了：
- 通过使用ZooKeeper保存集群状态而实现的高可用性，可以快速实现故障恢复，转向备份资源管理器上。任何ApplicationMaster都可以将状态放到HDFS中。比如说如果出现崩溃，map-reduce Application Master就会将状态保存起来并且可以快速恢复。
- 通过定义良好的wire协议实现向后兼容性，考虑到了同一个集群中的ResourceManager和NodeManager不断增加、同时运行不同版本的map-reduce或是其他编程范式情况下的更新问题。Arun说到，Yahoo!研究员经常会运行MPI、Master-Worker和迭代模型，这么做考虑到了编程模型上的更新，如Hadoop在线原型。
- 更好的利用率，替换掉了固定的map并使用一种模型减少了资源占用，该模型利用了底层的资源，如磁盘和CPU以避免浪费或是防止竞争。
在随后的讨论中，Murthy说到系统将不会使用Linux容器来限制资源，因为测试表明这种方式的代价太大了，但他们会使用Linux cgroups来实现沙箱进程，强制容器进程不会超过限定。系统考虑到了位置敏感的请求（比如说，在一台机器上运行任务或是文件附近的rack），在map-reduce job中维护位置信息，这也是其他的分布式编程范式所需的。为了支持map-reduce的shuffle阶段，NodeManager容许远程任务发出远程请求来读取磁盘上的本地数据。一开始，map-reduce容器会根据运行在该节点上的每个map任务分割单独的NodeManager以改进性能。Murthy提到未来他们想增加一个合并操作，该操作可以对单独的节点和单独的rack上的所有map任务进行排序，从而进一步改进shuffle的效率。
Murthy说到，该项技术目前处于开发的原型阶段。Yahoo!很希望今年就部署上去以便支持更大的集群，但这要取决于内部发布代码的流程并且要与Apache Hadoop的发布相协调才行。在Arun于2月份的Bay Area Hadoop User Group会议上的演讲后，MapR Technolgies的Ted Dunning询问Mesos是否还没准备好呢。Murthy回应到，Mesos需要一个JobTracker和TaskTracker来运行map-reduce，而该实现却不再需要JobTracker和TaskTracker了。我们让Mesos团队来回答这个问题。
来自Mesos团队的Andy Konwinski说到：“市场需要竞争才能蓬勃发展，因此这对于Mesos来说是个好消息。我也期待与来自于Yahoo!的天才们在友好的气氛下展开合作和竞争”。Mesos团队的Matei Zaharia说到：
我觉得最好利用此次对MapReduce的重构机会来支持多种资源管理器——这不仅仅是出于Mesos的目的，而是因为人们自然而然地想在Sun Grid Engine、LSF和Condor之上运行Hadoop。通用应用的资源调度要比实现MapReduce困难得多，现在可能已经有不少实验和各种系统来解决这个问题了。Yahoo的重构会简化Hadoop在Mesos上的运行。无论如何，我们这边都会支持Hadoop。
来自Mesos团队的Benjamin Hindman说到：
我们计划继续开发Mesos，让其成长为强大的系统。我觉得这么做的一个好处在于Mesos会继续得到构建，从头开始，除了数据处理外还能运行其他各种应用。在Twitter，我们每天都运行越来越多的像应用一样的通用“服务器”。
在被问到提议的Hadoop架构与Mesos有何区别时，Zaharia说到：
主要的一个差别在于Mesos master中的状态管理。在Mesos中，应用是可以执行自己的调度的，master只包含关于当前活动应用和运行任务的软状态信息。特别是master无需知道应用没有启动的挂起任务的。在Hadoop下一代的设计中，就我理解而言，master会在ZooKeeper中维护所有挂起任务的一个列表，这样就需要管理更多的状态了。除了这个技术问题外，Mesos从一开始就支持非MapReduce框架，我们已经在MPI、长期运行的服务以及名为Spark的并行处理系统中使用它了。从实际角度来看，另一个差异在于Mesos可以在Hadoop 0.20（使用一个补丁）中使用，而无需等待新版Hadoop发布。
InfoQ有幸采访到了Yahoo! Hadoop开发团队的副总裁Eric Baldeschwieler以深入了解该项目的起源及与Mesos的区别。Baldeschwieler说到，现在有很多项目都提供了集群调度功能，其中就包括了Mesos。然而，Yahoo!感觉到现有这些方案都无法解决map-reduce的问题。他说，一些方案是新近出现的，还不太成熟，而成熟的方案则缺少一些重要特性。 他说下一代的Map Reduce设计会反映出这几年在Hadoop所积累的经验，随着Yahoo!不断改进map-reduce，这其实是个自然而然的过程。
关于Mesos，Baldeschwieler说它是个好榜样，但Yahoo!需要一个集成的Hadoop组件，而不是一个元层（meta-layer）。他说下一代的MapReduce架构已经设计很长一段时间了，Yahoo!团队在设计过程中与Mesos团队成员通力合作，并且对他们的工作很感兴趣。Baldeschwieler说，他欢迎Mesos团队对Hadoop项目做出贡献，这将有助于他们更好地集成Hadoop。他说，过去Yahoo!采用了外部开发的Hadoop技术，并且通过开辟社区证明了他们的价值，如HBase和Hive。
Hadoop生态圈将逐渐演变为一个支持多种编程范式的资源调度器，并且非常强调可伸缩性、可靠性和效率，这一切都令人期待不已。
查看英文原文：Hadoop Redesign for Upgrades and Other Programming Paradigms
