Hadoop 重新设计，旨在简化升级并支持其他的编程范式

近日，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