[BigData - Hadoop - YARN] YARN：下一代 Hadoop 计算平台

Apache Hadoop 是最流行的大数据处理工具之一。它多年来被许多公司成功部署在生产中。尽管 Hadoop 被视为可靠的、可扩展的、富有成本效益的解决方案，但大型开发人员社区仍在不断改进它。最终，2.0 版提供了多项革命性功能，其中包括 Yet Another Resource Negotiator (YARN)、HDFS Federation 和一个高度可用的 NameNode，它使得 Hadoop 集群更加高效、强大和可靠。在本文中，将对 YARN 与 Hadoop 中的分布式处理层的之前版本进行比较，了解 YARN 所带来的优点。

简介

Apache Hadoop 2.0 包含 YARN，它将资源管理和处理组件分开。基于 YARN 的架构不受 MapReduce 约束。本文将介绍 YARN，以及它相对于 Hadoop 中之前的分布式处理层的一些优点。本文将了解如何使用 YARN 的可伸缩性、效率和灵活性加强您的集群。

Apache Hadoop 简介

Apache Hadoop 是一个开源软件框架，可安装在一个商用机器集群中，使机器可彼此通讯并协同工做，以高度分布式的方式共同存储和处理大量数据。最初，Hadoop 包含如下两个主要组件：Hadoop Distributed File System (HDFS) 和一个分布式计算引擎，该引擎支持以 MapReduce 做业的形式实现和运行程序。

MapReduce 是 Google 推广的一个简单的编程模型，它对以高度并行和可扩展的方式处理大数据集颇有用。MapReduce 的灵感来源于函数式编程，用户可将他们的计算表达为 map 和 reduce 函数，将数据做为键值对来处理。Hadoop 提供了一个高级 API 来在各类语言中实现自定义的 map 和 reduce 函数。

Hadoop 还提供了软件基础架构，以一系列 map 和 reduce 任务的形式运行 MapReduce 做业。Map 任务 在输入数据的子集上调用 map 函数。在完成这些调用后，reduce 任务 开始在 map 函数所生成的中间数据上调用 reduce 任务，生成最终的输出。 map 和 reduce 任务彼此单独运行，这支持并行和容错的计算。

最重要的是，Hadoop 基础架构负责处理分布式处理的全部复杂方面：并行化、调度、资源管理、机器间通讯、软件和硬件故障处理，等等。得益于这种干净的抽象，实现处理数百（或者甚至数千）个机器上的数 TB 数据的分布式应用程序从未像如今这么容易过，甚至对于以前没有使用分布式系统的经验的开发人员也是如此。

Hadoop 的黄金时代

尽管 MapReduce 模型存在着多种开源实现，但 Hadoop MapReduce 很快就变得很是流行。Hadoop 也是全球最使人兴奋的开源项目之一，它提供了多项出色的功能：高级 API、近线性的可伸缩性、开源许可、在商用硬件上运行的能力，以及容错。它已得到数百（或许已达数千）个公司的成功部署，是大规模分布式存储和处理的最新标准。

一些早期的 Hadoop 采用者，好比 Yahoo! 和 Facebook，构建了包含 4,000 个节点的大型集群，以知足不断增加和变化的数据处理需求。可是，在构建本身的集群后，他们开始注意到了 Hadoop MapReduce 框架的一些局限性。

经典 MapReduce 的局限性

经典 MapReduce 的最严重的限制主要关系到可伸缩性、资源利用和对与 MapReduce 不一样的工做负载的支持。在 MapReduce 框架中，做业执行受两种类型的进程控制：

• 一个称为 JobTracker 的主要进程，它协调在集群上运行的全部做业，分配要在 TaskTracker 上运行的 map 和 reduce 任务。
• 许多称为 TaskTracker 的下级进程，它们运行分配的任务并按期向 JobTracker 报告进度。

Apache Hadoop 的经典版本 (MRv1)

大型的 Hadoop 集群显现出了由单个 JobTracker 致使的可伸缩性瓶颈。依据 Yahoo!，在集群中有 5,000 个节点和 40,000 个任务同时运行时，这样一种设计实际上就会受到限制。因为此限制，必须建立和维护更小的、功能更差的集群。

此外，较小和较大的 Hadoop 集群都从未最高效地使用他们的计算资源。在 Hadoop MapReduce 中，每一个从属节点上的计算资源由集群管理员分解为固定数量的 map 和 reduce slot，这些 slot 不可替代。设定 map slot 和 reduce slot 的数量后，节点在任什么时候刻都不能运行比 map slot 更多的 map 任务，即便没有 reduce 任务在运行。这影响了集群的利用率，由于在全部 map slot 都被使用（并且咱们还须要更多）时，咱们没法使用任何 reduce slot，即便它们可用，反之亦然。

最后但一样重要的是，Hadoop 设计为仅运行 MapReduce 做业。随着替代性的编程模型（好比 Apache Giraph 所提供的图形处理）的到来，除 MapReduce 外，愈来愈须要为可经过高效的、公平的方式在同一个集群上运行并共享资源的其余编程模型提供支持。

2010 年，Yahoo! 的工程师开始研究一种全新的 Hadoop 架构，用这种架构来解决上述全部限制并增长多种附加功能。

解决可伸缩性问题

在 Hadoop MapReduce 中，JobTracker 具备两种不一样的职责：

• 管理集群中的计算资源，这涉及到维护活动节点列表、可用和占用的 map 和 reduce slots 列表，以及依据所选的调度策略将可用 slots 分配给合适的做业和任务
• 协调在集群上运行的全部任务，这涉及到指导 TaskTracker 启动 map 和 reduce 任务，监视任务的执行，从新启动失败的任务，推测性地运行缓慢的任务，计算做业计数器值的总和，等等

为单个进程安排大量职责会致使重大的可伸缩性问题，尤为是在较大的集群上，JobTracker 必须不断跟踪数千个 TaskTracker、数百个做业，以及数万个 map 和 reduce 任务。下图演示了这一问题。相反，TaskTracker 一般近运行十来个任务，这些任务由勤勉的 JobTracker 分配给它们。

大型 Apache Hadoop 集群 (MRv1) 上繁忙的 JobTracker

为了解决可伸缩性问题，一个简单而又绝妙的想法应运而生：咱们减小了单个 JobTracker 的职责，将部分职责委派给 TaskTracker，由于集群中有许多 TaskTracker。在新设计中，这个概念经过将 JobTracker 的双重职责（集群资源管理和任务协调）分开为两种不一样类型的进程来反映。

再也不拥有单个 JobTracker，一种新方法引入了一个集群管理器，它唯一的职责就是跟踪集群中的活动节点和可用资源，并将它们分配给任务。对于提交给集群的每一个做业(Task)，会启动一个专用的、短暂的 JobTracker 来控制该做业中的任务的执行。有趣的是，短暂的 JobTracker 由在从属节点上运行的 TaskTracker 启动。所以，做业的生命周期的协调工做分散在集群中全部可用的机器上。得益于这种行为，更多工做可并行运行，可伸缩性获得了显著提升。

YARN：下一代 Hadoop 计算平台

咱们如今稍微改变一下用辞。如下名称的改动有助于更好地了解 YARN 的设计：

• ResourceManager 代替集群管理器
• ApplicationMaster 代替一个专用且短暂的 JobTracker
• NodeManager 代替 TaskTracker
• 一个分布式应用程序代替一个 MapReduce 做业

YARN 是下一代 Hadoop 计算平台，以下所示。

YARN 的架构

在 YARN 架构中，一个全局 ResourceManager 以主要后台进程的形式运行，它一般在专用机器上运行，在各类竞争的应用程序之间仲裁可用的集群资源。ResourceManager 会追踪集群中有多少可用的活动节点和资源，协调用户提交的哪些应用程序应该在什么时候获取这些资源。ResourceManager 是唯一拥有此信息的进程，因此它可经过某种共享的、安全的、多租户的方式制定分配（或者调度）决策（例如，依据应用程序优先级、队列容量、ACLs、数据位置等）。

在用户提交一个应用程序时，一个称为 ApplicationMaster 的轻量型进程实例会启动来协调应用程序内的全部任务的执行。这包括监视任务，从新启动失败的任务，推测性地运行缓慢的任务，以及计算应用程序计数器值的总和。这些职责之前分配给全部做业的单个 JobTracker。ApplicationMaster 和属于它的应用程序的任务，在受 NodeManager 控制的资源容器中运行。

NodeManager 是 TaskTracker 的一种更加普通和高效的版本。没有固定数量的 map 和 reduce slots，NodeManager 拥有许多动态建立的资源容器。容器的大小取决于它所包含的资源量，好比内存、CPU、磁盘和网络 IO。目前，仅支持内存和 CPU (YARN-3)。将来可以使用 cgroups 来控制磁盘和网络 IO。一个节点上的容器数量，由配置参数与专用于从属后台进程和操做系统的资源之外的节点资源总量（好比总 CPU 数和总内存）共同决定。

有趣的是，ApplicationMaster 可在容器内运行任何类型的任务。例如，MapReduce ApplicationMaster 请求一个容器来启动 map 或 reduce 任务，而 Giraph ApplicationMaster 请求一个容器来运行 Giraph 任务。您还能够实现一个自定义的 ApplicationMaster 来运行特定的任务，进而发明出一种全新的分布式应用程序框架，改变大数据世界的格局。您能够查阅 Apache Twill，它旨在简化 YARN 之上的分布式应用程序的编写。

在 YARN 中，MapReduce 降级为一个分布式应用程序的一个角色（但还是一个很是流行且有用的角色），如今称为 MRv2。MRv2 是经典 MapReduce 引擎（如今称为 MRv1）的重现，运行在 YARN 之上。

 

一个可运行任何分布式应用程序的集群

ResourceManager、NodeManager 和容器都不关心应用程序或任务的类型。全部特定于应用程序框架的代码都转移到它的 ApplicationMaster，以便任何分布式框架均可以受 YARN 支持 — 只要有人为它实现了相应的 ApplicationMaster。

得益于这个通常性的方法，Hadoop YARN 集群运行许多不一样工做负载的梦想才得以实现。想像一下：您数据中心中的一个 Hadoop 集群可运行 MapReduce、Giraph、Storm、Spark、Tez/Impala、MPI 等。

单一集群方法明显提供了大量优点，其中包括：

• 更高的集群利用率，一个框架未使用的资源可由另外一个框架使用
• 更低的操做成本，由于只有一个 “包办一切的” 集群须要管理和调节
• 更少的数据移动，无需在 Hadoop YARN 与在不一样机器集群上运行的系统之间移动数据

管理单个集群还会获得一个更环保的数据处理解决方案。使用的数据中心空间更少，浪费的硅片更少，使用的电源更少，排放的碳更少，这只是由于咱们在更小但更高效的 Hadoop 集群上运行一样的计算。

 

YARN 中的应用程序提交

本节讨论在应用程序提交到 YARN 集群时，ResourceManager、ApplicationMaster、NodeManagers 和容器如何相互交互。下图显示了一个例子。

YARN 中的应用程序提交

假设用户采用与 MRv1 中相同的方式键入 hadoop jar 命令，将应用程序提交到 ResourceManager。ResourceManager 维护在集群上运行的应用程序列表，以及每一个活动的 NodeManager 上的可用资源列表。ResourceManager 须要肯定哪一个应用程序接下来应该得到一部分集群资源。该决策受到许多限制，好比队列容量、ACL 和公平性。ResourceManager 使用一个可插拔的 Scheduler。Scheduler 仅执行调度；它管理谁在什么时候获取集群资源（以容器的形式），但不会对应用程序内的任务执行任何监视，因此它不会尝试从新启动失败的任务。

在 ResourceManager 接受一个新应用程序提交时，Scheduler 制定的第一个决策是选择将用来运行 ApplicationMaster 的容器。在 ApplicationMaster 启动后，它将负责此应用程序的整个生命周期。首先也是最重要的是，它将资源请求发送到 ResourceManager，请求运行应用程序的任务所需的容器。资源请求是对一些容器的请求，用以知足一些资源需求，好比：

• 必定量的资源，目前使用 MB 内存和 CPU 份额来表示
• 一个首选的位置，由主机名、机架名称指定，或者使用 * 来表示没有偏好
• 此应用程序中的一个优先级，而不是跨多个应用程序

若是可能的话，ResourceManager 会分配一个知足 ApplicationMaster 在资源请求中所请求的需求的容器（表达为容器 ID 和主机名）。该容器容许应用程序使用特定主机上给定的资源量。分配一个容器后，ApplicationMaster 会要求 NodeManager（管理分配容器的主机）使用这些资源来启动一个特定于应用程序的任务。此任务能够是在任何框架中编写的任何进程（好比一个 MapReduce 任务或一个 Giraph 任务）。NodeManager 不会监视任务；它仅监视容器中的资源使用状况，举例而言，若是一个容器消耗的内存比最初分配的更多，它会结束该容器。

ApplicationMaster 会不遗余力协调容器，启动全部须要的任务来完成它的应用程序。它还监视应用程序及其任务的进度，在新请求的容器中从新启动失败的任务，以及向提交应用程序的客户端报告进度。应用程序完成后，ApplicationMaster 会关闭本身并释放本身的容器。

尽管 ResourceManager 不会对应用程序内的任务执行任何监视，但它会检查 ApplicationMaster 的健康情况。若是 ApplicationMaster 失败，ResourceManager 可在一个新容器中从新启动它。您能够认为 ResourceManager 负责管理 ApplicationMaster，而 ApplicationMasters 负责管理任务。

 

回页首

有趣的事实和特性

YARN 提供了多种其余的优秀特性。介绍全部这些特性不属于本文的范畴，我仅列出一些值得注意的特性：

• 若是做业足够小，Uberization 支持在 ApplicationMaster 的 JVM 中运行一个 MapReduce 做业的全部任务。这样，您就可避免从 ResourceManager 请求容器以及要求 NodeManagers 启动（可能很小的）任务的开销。
• 与为 MRv1 编写的 MapReduce 做业的二进制或源代码兼容性 (MAPREDUCE-5108)。
• 针对 ResourceManager 的高可用性 (YARN-149)。此工做正在进行中，已由一些供应商完成。
• 从新启动 ResourceManager 后的应用程序恢复 (YARN-128)。ResourceManager 将正在运行的应用程序和已完成的任务的信息存储在 HDFS 中。若是 ResourceManager 从新启动，它会从新建立应用程序的状态，仅从新运行不完整的任务。此工做已接近完成，社区正在积极测试。它已由一些供应商完成。
• 简化的用户日志管理和访问。应用程序生成的日志不会留在各个从属节点上（像 MRv1 同样），而转移到一个中央存储区，好比 HDFS。在之后，它们可用于调试用途，或者用于历史分析来发现性能问题。
• Web 界面的新外观。

 

回页首

结束语

YARN 是一个彻底重写的 Hadoop 集群架构。它彷佛在商用机器集群上实现和执行分布式应用程序的方式上带来了变革。

与初版 Hadoop 中经典的 MapReduce 引擎相比，YARN 在可伸缩性、效率和灵活性上提供了明显的优点。小型和大型 Hadoop 集群都从 YARN 中受益不浅。对于最终用户（开发人员，而不是管理员），这些更改几乎是不可见的，由于可使用相同的 MapReduce API 和 CLI 运行未经修改的 MapReduce 做业。

没有理由不将 MRv1 迁移到 YARN。最大型的 Hadoop 供应商都赞成这一点，并且为 Hadoop YARN 的运行提供了普遍的支持。现在，YARN 已被许多公司成功应用在生产中，好比 Yahoo!、eBay、Spotify、Xing、Allegro 等。

 

回页首

致谢

感谢 Piotr Krewski 和 Fabian Alenius 对本文进行技术审阅。

参考资料

学习

• 了解 IBM Watson 研究项目。
• 访问 Big Data University，获取有关 Hadoop 和大数据的免费课程。
• 查阅 了解大数据：分析企业级 Hadoop 和流数据，了解 IBM 的两种重要的大数据技术的详细信息。
• 访问 Apache Hadoop 项目，了解它是什么，如何获取它，如何开始执行，以及全部新闻。
• 查阅 Dhruba Borthakur 编写的 “Hadoop 分布式文件系统：架构和设计”。
• 了解 HadoopDB，MapReduce 和 DBMS 技术针对分析工做负载的一种架构组合。
• 查阅 Apache.org 上的 Hadoop MapReduce 教程。
• 查阅 “在云中使用 MapReduce 和负载平衡”，了解如何在云环境中实现 Hadoop MapReduce 框架，以及如何使用虚拟负载平衡来改善单节点和多节点系统的性能。
• 有关使用 CDH4 安装 Hadoop 的信息，请参阅 CDH4 安装 — Cloudera 支持。
• 使用 大数据术语（由 Pete Warden 编写，O'Reilly Media，ISBN：1449314597，2011 年），帮助了解新工具和差创新。
• Hadoop：指导性指南（由 Tom White 编写，O'Reilly Media，ISBN：1449389732，2010 年）介绍了如何使用 Hadoop 框架构建和维护可靠、可扩展、分布式的系统。
• HadoopDB：针对分析工做负载的 MapReduce 和 DBMS 技术的结构性混合（Azza Abouzeid 等，VLDB Endowment 会议论文 2(1)，2009 年）探索了构建一个集合两种技术的最佳特性的混合系统的可行性。
• 查阅 MapReduce：简化大型集群上的数据处理，Jeffrey Dean 和 Sanjay Ghemawat，OSDI，2004 年。
• SQL/MapReduce：一个自描述的、多态的、并行化的用户定义函数的实用方法（Friedman 等，VLDB Endowment 会议论文 2(2)，2009 年）介绍了发明这种新的 UDF 方法的动机，以及在 AsterData Systems 的 nCluster 数据库中的实现。
• “MapReduce 和 parallel DBMSes：朋友仍是敌人？”（Stonebraker 等，Commun.ACM 53(1)，2010 年）认为使用 MR 系统来执行最适合 DBMS 的任务，会获得不太满意的结果。
• 云环境中的大规模数据管理方法的调查（Sakr 等，Journal of IEEE Communications Surveys and Tutorials，13(3)，2011 年）全面调查了在云中部署数据密集型应用程序的大量方法和机制。
• 访问 developerWorks 开源专区，查找丰富的操做指引信息、工具和项目更新，以帮助您使用开源技术进行开发并将它们用于 IBM 产品。
• 在 developerWorks 大数据专区，了解关于大数据的更多信息，获取技术文档、how-to 文章、培训、下载、产品信息以及其余资源。
• 在 developerWorks Information Management 专区，了解关于信息管理的更多信息，获取技术文档、how-to 文章、培训、下载、产品信息以及其余资源。

得到产品和技术

• 参阅 InfoSphere BigInsights 信息中心 获取产品文档。
• 从 Apache.org 获取 Hadoop 0.20.1、Hadoop MapReduce 和 Hadoop HDFS。
• 使用 IBM 试用软件 在下一个开发项目上进行创新，这些软件可下载或经过 DVD 得到。

讨论

• 参与 developerWorks 博客 并加入 developerWorks 社区。
• 加入 developerWorks 中文社区，查看开发人员推进的博客、论坛、组和维基，并与其余 developerWorks 用户交流。