Apache Hadoop YARN：另一个资源协调者

摘要

Apache Hadoop[1]的最初设计重点关注于运行大规模的MapReduce作业以处理Web爬虫。对于越来越多样化的公司而言，Hadoop已成为数据和计算的市场-共享和访问数据及计算资源的实际场所。这种广泛的应用和无处不在的使用使初始设计远远超出了预期的目标，从而暴露出两个主要缺点：1）特定编程模型与资源管理基础设施的紧密耦合，迫使开发人员滥用MapReduce编程模型，以及2）集中式作业控制流的处理，导致调度器无尽的扩展性问题。

在本文中，我们总结了下一代Hadoop计算平台YARN的设计、开发和当前部署状态。我们引入的新架构将编程模型与资源管理基础架构分离开来，并将许多调度功能（例如任务容错）委托给每个应用程序组件。我们提供实验证据来证明我们所做的改进，通过报告在生产环境（包括100％的Yahoo!网格）上运行YARN的经验来确认提高的效率，并通过讨论将几种编程框架移植到YARN上，如Dryad、Giraph、Hoya、Hadoop MapReduce、REEF、Spark、Storm和Tez，来确认灵活性要求。

1. 引言

Apache Hadoop最初是MapReduce[12]的许多开源实现之一，其重点是解决Web爬虫索引所需的前所未有的规模。针对此用例对其执行架构进行了调整，重点是针对大量数据密集型计算的强大容错能力。在许多大型Web公司和初创公司中，Hadoop集群是存储和处理操作数据的常见场所。

更重要的是，它成为组织中工程师和研究人员可以即时且几乎不受限制地访问大量计算资源和公司数据库的地方。这既是Hadoop成功的原因，也是最大的诅咒，因为开发人员的群体将MapReduce编程模型扩展到了集群管理基础之外。通用模式提交“仅map”作业以生成集群中的任意进程。滥用的示例包括派生Web服务器和按组调度以进行迭代作业计算。为了利用物理资源，开发人员通常采用聪明的解决方法来避开MapReduce API的限制。

这些限制和误用激发了一大类的论文使用Hadoop作为无关环境的基线。尽管许多论文都暴露了有关Hadoop架构或实现的实质性问题，但有些论文只是（或多或少地）谴责了这些滥用的一些副作用。到目前为止，学术界和开源社区都已经很好地了解了原始Hadoop架构的局限性。

在本文中，我们提出了一个社区驱动的工作，旨在使Hadoop超越其最初的化身。我们介绍了称为YARN的下一代Hadoop计算平台，它脱离了其熟悉的整体式架构。通过将资源管理功能与编程模型分离，YARN将许多与调度相关的功能委托给每个作业组件。在此新的上下文中，MapReduce只是在YARN之上运行的应用程序之一。这种分离为编程框架的选择提供了很大的灵活性。在YARN上可用的替代编程模型的示例包括：Dryad[18]、Giraph、Hoya、REEF[10]、Spark[32]、Storm[4]和Tez[2]。在YARN上运行的编程框架根据需要协调应用程序内部通信、执行流程和动态优化，从而显著提高了性能。我们从早期架构师和实现者的角度描述YARN的起源、设计、开源开发和部署。

2. 历史和基本原理

在本节中，我们描述YARN的需求是如何从现实需要应运而生的起源概述。欢迎对需求的起源不感兴趣的读者掠过本节（为方便起见，需求进行粗体显示），然后继续阅读第3节，我们将对YARN的体系结构进行简要描述。

Yahoo!在2006年采用Apache Hadoop取代了驱动其WebMap应用[11]的基础架构，该技术可构建已知网络的图来驱动其搜索引擎。当时，该网络图包含超过1000亿个节点和1万亿条边。先前的基础架构名为“Dreadnaught”[25]已达到800台机器的可扩展性极限，并且需要对架构进行重大调整以适应Web的发展速度。Dreadnaught已经执行过的分布式应用程序类似于MapReduce[12]程序，因此通过采用可扩展性更高的MapReduce框架，可以轻松迁移搜索流水线的重要部分。这突显了在整个Hadoop早期版本中始终存在的第一要求，一直到YARN-[R1：]可扩展性。

除了Yahoo!的超大型流水线外， 搜索、优化广告分析、垃圾邮件过滤和内容优化的科学家推动了许多早期需求。随着Apache Hadoop社区扩展平台以处理越来越大的MapReduce作业，围绕**[R2：]多租户**的需求开始形成。在这种情况下，可以最好地理解计算平台的工程优先级和中间阶段。YARN的架构基于MapReduce平台不断发展的经验，可以满足许多长期的要求。在本文的其余部分，我们将假设您对传统Hadoop架构有基本了解，附录A中提供了其简要概述。

2.1 专用集群的时代

Hadoop最早的一些用户会在少数几个节点上建立集群，将其数据加载到Hadoop分布式文件系统（HDFS）[27]，通过编写MapReduce作业来获得他们感兴趣的结果，接着将其拉取下来[15]。随着Hadoop的容错能力的提高，持久化HDFS集群已成为常态。在Yahoo!，操作者会将“有趣”的数据集加载到共享集群中，从而吸引了对从中获取洞察感兴趣的科学家。尽管大规模计算仍是开发的主要驱动力，但HDFS还获得了权限模型、配额和其他功能，以改善其多租户操作。

为了解决一些多租户问题，Yahoo!开发并部署了Hadoop on Demand（HoD），它使用Torque[7]和Maui[20]在共享的硬件池上分配Hadoop集群。用户可以提交他们的带有大小适当的计算集群描述的作业给Torque，然后Torque会对其排队，直到有足够的节点可用为止。一旦节点可用，Torque将在头节点上启动HoD的“领导者”进程，该进程然后与Torque/Maui交互以启动HoD的从属进程，随后为该用户生成JobTracker和TaskTrackers，然后接受一系列作业。当用户释放集群时，系统将自动收集用户的日志，并将节点返回到共享池。由于HoD为每个作业都设置了一个新的集群，因此用户可以（稍微）运行旧版本的Hadoop，并且开发人员可以轻松地测试新功能。自Hadoop每三个月发布一次主要修订以来，HoD的灵活性对于保持这种节奏至关重要 - 我们将升级依赖关系的这种脱钩称为**[R3：]可维护性**。

尽管HoD也可以部署HDFS集群，但大多数用户都在共享的HDFS实例中部署了计算节点。随着HDFS的扩展，可以在其之上分配更多的计算集群，从而在更多数据集上形成增加用户密度的良性循环，从而带来新的洞察。由于大多数Hadoop集群都小于Yahoo!上最大的HoD作业，因此JobTracker很少成为瓶颈。

HoD证明了自己是一个通用平台，可以预见Mesos[17]的某些特性，它将扩展主框架模型以支持在并行的各种编程模型之间进行动态资源分配。在没有任何隔离和安全性方面的情况下，HoD也可以被视为EC2 Elastic MapReduce和Azure HDInsight产品的私有云前身。

2.2 Hadoop on Demand的缺点

Yahoo!由于资源利用率中等，最终退休了HoD，转而使用共享MapReduce集群。在map阶段，JobTracker会尽一切努力将任务放置在HDFS中靠近其输入数据的位置，最好放在存储该数据副本的节点上。由于Torque分配节点时不考虑位置，因此授予用户JobTracker的节点子集可能只包含少数相关副本。考虑到大量的小作业，大多数读取来自远程主机。抑制这些旧特性的努力取得了好坏参半的结果；虽然跨机架分布TaskTracker使得在机架内读取共享数据集的可能性更高，但map任务和reduce任务之间的记录shuffle必然会跨越机架，并且DAG中的后续作业将很少有机会解决其祖先的倾斜。[R4：]位置感知是YARN的重点要求。

诸如Pig[24]和Hive[30]之类的高级框架通常在DAG中组成MapReduce作业的工作流，它们在计算的每个阶段都对数据进行过滤、汇总和预测。由于在使用HoD时，集群的大小在作业之间没有调整，因此在随后的更小阶段完成后，集群中的大部分容量都处于闲置状态。在一种极端但非常常见的情况下，在一个节点上运行单个reduce任务可能会阻止回收集群。在此状态下，一些作业使数百个节点处于空闲状态。

最后，作业等待时间主要由分配集群所花费的时间决定。用户在估计他们的作业需要多少个节点时仅能依靠试探法，并且经常会要求数十倍的资源来满足他们的直觉。集群分配延迟是如此之高，用户通常会与同事共享期待已久的集群，将节点的保留时间延长到比预期更长的时间，从而进一步增加了延迟。尽管用户喜欢HoD的许多功能，但集群利用的经济性迫使Yahoo!将其用户打包到共享集群中。[R5：]高集群利用率是YARN的头等大事。

2.3 共享集群

最终，HoD的信息太少，无法对其分配做出明智的决策，其资源粒度太粗糙，并且其API迫使用户向资源层提供误导性约束。

但是，迁移到共享集群并非易事。尽管数年间HDFS规模逐步扩大，但JobTracker却被HoD隔离。删除该防护后，MapReduce集群突然变得很大，作业吞吐量急剧增加，并且无辜添加到JobTracker中的许多功能成为了关键漏洞的源头。更糟糕的是，虽然JobTracker故障没有丢失一个作业流，但是造成了宕机，该宕机将丢失集群中所有正在运行的作业，并要求用户手动恢复其作业流。

宕机时间在处理流水线中造成作业积压，重新启动后将给JobTracker造成很大压力。重新启动通常涉及手动终止用户的作业，直到集群恢复。重新启动通常涉及手动终止用户的作业，直到集群恢复。 由于为每个作业存储了复杂的状态，因此从未完全调试过在重启后保留作业的实现。

操作大型的多租户Hadoop集群非常困难。尽管容错是设计的核心原则，但暴露给用户应用程序的面却很广阔。考虑到单点故障暴露出的各种可用性问题，至关重要的是连续监视集群中的工作负载以查找功能失常的作业。更为巧妙的是，由于JobTracker需要为其初始化的每个作业分配跟踪结构，因此其允许控制逻辑包括保护其自身可用性的保障措施；这可能会延迟为作业分配空闲集群资源，因为跟踪作业的开销可能使JobTracker进程不堪重负。所有这些关注点都可以归类为**[R6：]可靠性/可用性**。

随着Hadoop管理更多的租户、多样化的用例和原始数据，其隔离要求变得更加严格，但是授权模型缺乏强大的可扩展身份验证，这是多租户集群的一项关键功能。已添加并反向移植到多个版本。[R7：]安全且可审核的操作必须在YARN中保留。开发人员逐渐强化了系统，以适应对资源的多样化需求，这与面向插槽的资源视图不同。

虽然MapReduce支持广泛的用例，但它并不是所有大规模计算的理想模型。例如，许多机器学习程序需要对数据集进行多次迭代才能收敛到结果。如果将这一流程作为一系列MapReduce作业进行组合，则调度开销将显著延迟结果[32]。类似地，许多图算法可以使用批量同步并行模型（BSP）更好地表达，该模型使用消息传递在顶点之间进行通信，而不是在容错的大规模MapReduce作业[22]中使用繁重的多对多的通信屏障。这种不匹配成为阻碍用户工作效率的障碍，但是Hadoop中以MapReduce为中心的资源模型不允许使用任何竞争性应用程序模型。Hadoop在Yahoo!内部的广泛部署和其数据流水线的惯性使这些紧张关系变得无法解决。这没有阻碍用户编写“MapReduce”程序来生成替代框架。对于调度器，它们表现为具有完全不同的资源曲线的纯map作业，从而阻碍了内置在平台中的假设，并导致利用率低下、潜在的死锁和不稳定。YARN必须与用户宣布停战，并提供显式**[R8：]编程模型多样性支持**。

除了与新兴的框架要求不匹配外，类型化插槽还会损害利用率。虽然map和reduce的地位之间的隔离可防止死锁，但它也可能成为资源瓶颈。在Hadoop中，用户为每个提交的作业配置两个阶段之间的重叠。稍后开始执行的reduce任务可以增加集群的吞吐量，而在作业执行的提早启动它们可以减少其延迟。map和reduce槽位的数量由集群操作员确定，因此空闲map容量不能用于生成reduce任务，反之亦然。由于这两种任务类型以不同的速率完成，因此不能完美平衡配置。当任一插槽类型变得饱和时，可能都需要JobTracker对作业初始化施加反压，从而形成典型的流水线气泡。可替代的资源使调度复杂化，但是它们也使分配器能够更紧密地打包集群。这突出显示了对**[R9：]灵活的资源模型**的需求。

与HoD相比，向共享集群的迁移提高了利用率和本地性，这也大大减轻了人们对可维护性和可用性的担忧。在共享集群中部署新版本的Apache Hadoop是需要精心筹划的，这是一件令人头痛的常见事件。要修复MapReduce实现中的一个错误，操作者必须安排停机时间、关闭集群、部署新位、验证升级、然后接受新作业。通过将负责仲裁资源使用情况的平台与表达该程序的框架相结合，人们被迫同时开发它们；当操作者提高平台的分配效率时，用户必须合并框架变更。因此，升级集群要求用户停止、验证和恢复其流水线以进行无关联改变。尽管更新通常只需要重新编译，但用户对内部框架详细信息的假设或开发人员对用户程序的假设有时会在网格上运行的流水线上造成阻塞的不兼容性。

基于不断发展的Apache Hadoop MapReduce的经验教训，YARN旨在满足需求（R1-R9）。但是，MapReduce应用程序的庞大安装基数、相关项目的生态系统、陈旧的部署实践以及紧耦合的调试都无法忍受激进的重新设计。为了避免陷入“第二系统症候群” [6]，新架构尽可能重用了现有框架中的代码，表现出熟悉的模式，并在规划中留下了许多推测性的特性。这导致对YARN重新设计的最后要求：[R10：]向后兼容性。

在本文的其余部分，我们将对YARN的体系结构进行说明（第3节），并报告有关YARN在现实世界中的采用情况（第4节），并提供实验证据来验证一些关键的体系结构决策（第5节），最后通过将YARN与一些相关工作进行比较来得出结论（第6节）。

3. 架构

为了满足我们在第2节中讨论的需求，YARN将一些功能提升到负责资源管理的平台层，而将逻辑执行计划的协调留给了许多框架实现。具体来说，每个集群的ResourceManager（RM）跟踪资源使用情况和节点活跃性，强制分配不变性以及仲裁租户之间的争用。通过在JobTracker的章程中划分这些职责，中央分配器可以对租户要求进行抽象描述，而不用了解每个分配的语义。将该职责委派给ApplicationMaster（AM），该应用程序通过从RM请求资源，从其接收的资源中生成物理计划并协调故障的执行来协调单个作业的逻辑计划。

3.1 概述

RM在专用计算机上作为守护程序运行，并充当在集群中各种竞争应用程序之间仲裁资源的中央机构。考虑到集群资源的集中和全局视图，它可以在租户之间强制执行丰富、熟悉的特性，例如公平性[R10]、容量[R10]和本地性[R4]。根据应用程序需求、调度优先级和资源可用性，RM为应用程序动态分配租约（称为容器）以在特定节点上运行。容器是绑定到特定节点[R4，R9]上的逻辑资源束（例如，2GB RAM，1 CPU）。为了执行和跟踪此类分配，RM与运行在称为NodeManager（NM）的每个节点上的特殊系统守护程序进行交互。RM和NM之间的通信基于心跳，以实现可扩展性。NM负责监视资源可用性，报告故障和容器生命周期管理（例如，启动和终止）。RM从这些NM状态快照中组装其全局视图。

作业通过公共提交协议提交给RM，并进入准入控制阶段，在此阶段中，将验证安全凭证并执行各种操作和管理检查[R7]。接受的作业将传递到调度器以运行。一旦调度器拥有足够的资源，应用程序就会从接受状态转移到运行状态。除了内部记账之外，这还涉及为AM分配一个容器并将其生成在集群中的某个节点上。在RM重新启动或失败的情况下，将接受的应用程序的记录写入持久化存储并进行恢复。

ApplicationMaster是作业的“负责人”，管理生命周期的各个方面，包括动态增加和减少资源消耗、管理执行流程（例如，针对map输出运行reducer）、处理故障和计算倾斜以及执行其他本地性优化。实际上，AM可以运行任意用户代码，并且可以用任何编程语言编写，因为与RM和NM的所有通信均使用可扩展的通信协议进行编码 - 例如，请考虑我们在4.2节中讨论的Dryad端口。YARN对AM所做的假设很少，尽管在实践中我们预期大多数作业将使用更高级别的编程框架（例如MapReduce、Dryad、Tez和REEF等）。通过将所有这些功能委托给AM，YARN的体系结构获得了很大的可扩展性[R1]、编程模型灵活性[R8]和改进了升级/测试[R3]流程（因为同一框架的多个版本可以共存）。

通常，AM将需要利用多个节点上可用的资源（CPU，RAM，磁盘等）来完成一项工作。为了获得容器，AM向RM发出资源请求。这些请求的形式包括位置偏好和容器属性的规范。RM将根据可用性和调度策略尝试满足来自每个应用程序的资源请求。当为AM分配资源时，RM会为资源生成一个租约，并由后续的AM心跳拉动。当AM将容器租约提供给NM[R4]时，基于令牌的安全机制将保证其真实性。一旦ApplicationMaster发现某个容器可供使用，它将使用租约对特定于应用程序的启动请求进行编码。在MapReduce中，容器中运行的代码是map任务或reduce任务。如果需要，运行中的容器可以通过特定于应用程序的协议直接与AM通信，以报告状态和活跃性并接收特定于框架的命令 - YARN既不提倡也不反对这种通信。总体而言，YARN部署为生命周期管理和容器监控提供了一个基本而强大的基础框架，而每个框架都管理着特定于应用程序的语义[R3，R8]。

本节总结了YARN的体系结构概述。在本节的其余部分，我们将提供每个主要组件的详细信息。

3.2 Resource Manager (RM)

ResourceManager暴露了两个公共接口：1）客户端提交应用程序，和2）ApplicationMaster动态协商获取资源，以及一个面向NodeManagers的内部接口，用于集群监控和资源访问管理。在下文中，我们将重点介绍RM和AM之间的公共协议，因为这最能代表YARN平台与其上运行的各种应用程序/框架之间的重要边界。

RM将集群状态的全局模型与正在运行的应用程序报告的资源需求摘要进行匹配。这样就可以严格执行全局调度属性（YARN中不同的调度器专注于不同的全局属性，例如容量或公平性），但是它要求调度器对应用程序的资源需求有准确的了解。通信消息和调度器状态必须紧凑高效，以使RM能够根据应用程序需求和集群的大小进行扩展[R1]。捕获资源请求的方式在捕获资源需求的准确性和紧凑性之间取得了平衡。幸运的是，调度器仅处理每个应用程序的整体资源配置文件，而忽略了本地优化和内部应用程序流。YARN完全从map和reduce资源的静态划分出发；它将集群资源视为（离散的）连续体[R9] - 正如我们将在4.1节中看到的，这极大地提高了集群利用率。

ApplicationMasters通过一个或多个ResourceRequests来编纂对资源的需求，每个ResourceRequests跟踪：

1. 容器数量（例如200个容器），
2. 每个容器的资源<2GB RAM，1 CPU>，
3. 位置偏好，以及
4. 应用程序中请求的优先级

ResourceRequests旨在允许用户捕获其需求的完整细节和/或需求的汇总信息（例如，可以指定节点级别，机架级别和全局位置偏好[R4]）。这允许将更统一的请求紧凑地表示为合集。此外，这种设计将允许我们对ResourceRequests施加大小限制，从而利用ResourceRequests的汇总特性作为应用程序偏好的有损压缩。这使得调度器可以高效地进行此类请求的通信和存储，并且允许应用程序清楚地表达其需求[R1，R5，R9]。这些请求的汇总性质还指导调度器（如果无法实现完美的本地性）选择好的备选项（例如，如果所需节点繁忙，则进行机架本地分配）。

该资源模型可以在同类环境中很好地为当前应用程序提供服务，但是我们希望随着生态系统的成熟和新要求的出现，它会随着时间的推移而发展。最新和发展中的扩展包括：明确跟踪组计划需求、以及软/硬约束来表达任意相同位置或不相交位置的放置分配。

调度器使用推荐的NM心跳来通告可用资源以跟踪、更新和满足这些请求。作为对AM请求的响应，RM生成容器和令牌，这些令牌授予对资源的访问权限。RM将NM所报告的已完成容器的退出状态转发给负责的AM。当新的NM加入集群时，也会通知AM，以便它们可以开始在新节点上请求资源。

该协议的最新扩展允许RM对称地从应用程序请求资源。这通常在集群资源变得稀缺并且调度器决定撤消分配给应用程序以维护调度不变性的某些资源时发生。我们使用类似于ResourceRequests的结构来捕获位置偏好（可以是严格的或可以协商的）。AM在满足此类“抢占”请求时具有一定的灵活性，例如，通过产生对其工作而言不太重要的容器（例如，到目前为止进展不大的任务）、检查任务状态或迁移计算到其他正在运行的容器。总体而言，与强制杀死容器以满足资源约束的平台相比，这允许应用程序保留工作。如果应用程序是非协商的，则RM在等待一定时间后，可以通过指示NM强制终止容器来获取所需的资源。

对于第2节中的预先提出的要求，重要的是指出ResourceManager不负责什么。如所讨论的，它不负责协调应用程序执行或任务容错，但不负责1）提供运行应用程序的状态或指标（现在是ApplicationMaster的一部分），也不负责2）提供已完成作业的框架特定报告（现在已委派给每个框架的守护程序）。这与ResourceManager仅应处理实时资源调度的观点相一致并有助于YARN中的中央组件扩展到Hadoop 1.0 JobTracker以外。

3.3 Application Master (AM)

应用程序可以是一组静态进程、对作业的逻辑描述、甚至是长期运行的服务。ApplicationMaster是协调集群中应用程序执行的进程，但它本身就像其他容器一样在集群中运行。RM的组件协商获取容器以生成此引导进程。

AM会定期向RM发出心跳，以确认其活跃性并更新其需求记录。在建立其需求模型之后，AM在向RM的心跳消息中编码其偏好和约束。为响应随后的心跳，AM将在绑定到集群中特定节点的资源束上收到容器租约。根据从RM收到的容器，AM可以更新其执行计划，以适应得知到的资源的丰富或稀缺。与某些资源模型相反，对应用程序的分配是后期绑定：产生的进程不是绑定到请求，而是绑定到租约。导致AM发出请求的条件在它收到其资源时可能不会保持为真，但是容器的语义是可替代的且框架相关的[R3，R8，R10]。AM还将更新其向RM请求的资源，因为它收到的容器会影响其当前和将来的需求。

作为说明，MapReduce AM针对具有相同资源需求的map任务之间的本地性进行了优化。在HDFS上运行时，每个输入数据块都在k台计算机上覆制。AM收到容器后，会将其与待处理的map任务集进行匹配，选择输入数据靠近容器的任务。如果AM决定在容器中运行map任务mi，那么存储mi输入数据副本的主机就不那么吸引人了。AM将更新其请求以减少其他k-1个主机的权重。主机之间的关系对于RM仍然是不透明的；同样，如果mi失败，则AM负责更新其需求以进行补偿。对于MapReduce，请注意，Hadoop JobTracker提供的某些服务（例如RPC上的作业进度、状态的Web界面、对MapReduce特定的历史数据的访问）不再是YARN体系结构的一部分。这些服务由ApplicationMaster或框架守护程序提供。

由于RM不解释容器状态，因此通过RM，AM确定NM报告的容器退出状态的成功或失败的语义。由于AM本身是在不可靠的硬件集群中运行的容器，因此它应该要能够抵抗故障。YARN为恢复提供了一些支持，但是由于容错能力和应用程序语义如此紧密地交织在一起，因此许多负担都落在了AM上。我们将在3.6节中讨论容错模型。

3.4 Node Manager (NM)

NodeManager是YARN中的“工作者”守护程序。它对容器租约进行身份验证、管理容器的依赖关系、监视其执行情况并为容器提供一系列服务。操作者对其进行配置，以报告该节点上可用并分配给YARN的内存、CPU和其他资源。向RM注册后，NM会通过心跳发送其状态并接收指示。

YARN中的所有容器（包括AM）都由容器启动上下文（CLC）来描述。该记录包括环境变量映射、可远程访问的存储中存储的依赖关系、安全令牌、NM服务的有效负载以及创建进程所需的命令。验证租约[R7]的真实性后，NM为容器配置环境，包括使用租约中指定的资源约束初始化其监视子系统。为了启动容器，NM将所有必需的依赖项（数据文件、可执行文件、压缩文件）复制到本地存储中。如果需要，CLC还包括用于认证下载的凭据。根据CLC中的指定，可以在应用程序中的容器之间、由同一租户启动的容器之间、甚至在租户之间共享依赖关系。NM最终会垃圾收集运行容器未使用的依赖项。

NM也将按照RM或AM的指令杀死容器。当RM报告其拥有的应用程序已完成、当调度器决定将其移交给其他租户时，或者当NM检测到容器超出其租约限制时（R2，R3，R7），容器可能会被杀死。AM可能会在不再需要相应作业时要求杀死容器。每当容器退出时，NM都会清理本地存储中的工作目录。应用程序完成后，其容器所拥有的所有资源都会在所有节点上被丢弃，包括仍在集群中运行的所有进程。

NM还定期监视物理节点的运行状况。它监视本地磁盘的任何问题，并频繁运行由管理员配置的脚本，该脚本反过来又可以指向任何硬件/软件问题。发现此类问题后，NM将其状态更改为不健康，并报告RM大致相同的状态，然后做出调度器相关的决定，以终止该节点上的容器和/或停止将来的分配，直到解决健康问题为止。

除上述内容外，NM还为该节点上运行的容器提供本地服务。例如，当前的实现包括一个日志聚合服务，该服务将在应用程序完成后将应用程序写入stdout和stderr的数据上载到HDFS。

最后，管理员可以使用一组可插拔的辅助服务来配置NM。退出容器后，将清理容器的本地存储，但允许提倡保留一些输出，直到应用程序退出。以这种方式，进程可以产生在容器的寿命之外持续存在的数据，以由节点来管理。这些服务的一个重要用例是Hadoop MapReduce应用程序，使用辅助服务为其在map和reduce任务之间传输中间数据。如前所述，CLC允许AM将有效负载寻址到辅助服务；MapReduce应用程序使用此通道来传递令牌，及用来对reduce任务访问shuffle服务进行身份验证。

3.5 YARN框架/应用程序写入者

从前面对核心体系结构的描述中，我们提取了YARN应用程序写入者的职责：

1. 通过将ApplicationMaster的CLC传递给RM来提交应用程序。
2. RM启动AM时，AM应向RM注册并定期通过心跳协议通告其活跃性和需求。
3. RM分配容器后，AM可以构造CLC以在相应的NM上启动容器。它还可以监视正在运行的容器的状态，并在应回收资源时将其停止。监控容器内部作业的进度完全由AM负责。
4. AM完成工作后，应从RM中注销并干净地退出。
5. 使用框架的开发者可以选择在他们自己的客户端之间添加控制流，以报告作业状态并暴露控制界面。

即使是简单的AM也可能相当复杂；一个具有少数功能的分布式shell示例是超过450行Java代码。存在简化YARN应用程序开发的框架，我们将在4.2节中探讨其中的一些框架。客户端库 - YarnClient、NMClient、AMRMClient - 与YARN一起提供，并暴露了更高级别的API，以避免针对低级别协议进行编码。针对故障（包括自身故障）进行加强的AM并非易事。如果应用程序暴露服务或连接通信图，则它还负责其安全操作的所有方面；YARN仅保护其部署。

3.6 容错能力和可用性

从一开始，Hadoop就被设计为在商业硬件上运行。通过在其堆栈的每一层中建立容错能力，它隐藏了检测和从用户的硬件故障中恢复的复杂性。YARN继承了这一理念，尽管现在责任已分配到集群中运行的ResourceManager和ApplicationMaster之间。

在撰写本文时，RM仍是YARN体系结构中的单点故障。通过在初始化时从持久性存储中恢复其状态，RM可以从自身故障中恢复。恢复过程完成后，它将杀死集群中正在运行的所有容器，包括活跃的ApplicationMaster。然后，它启动每个AM的新实例。如果该框架支持恢复（并且大多数情况下都是为了常规容错），则该平台将自动恢复用户的流水线[R6]。正在为AM添加更多协议支持以使AM能在RM重新启动时存活。这样，AM可以在RM关闭时继续使用现有容器进行处理，并可以在RM恢复后与RM重新同步。通过被动/主动故障恢复RM到备用节点，来解决YARN集群的高可用性。

当NM发生故障时，RM会通过其心跳响应超时来对其进行检测，将在该节点上运行的所有容器标记为已杀死，然后将故障报告给所有正在运行的AM。如果故障是暂时的，则NM将与RM重新同步，清除其本地状态，然后继续。在这两种情况下，AM都会对节点故障做出反应，有可能重做故障期间该节点上运行的任何容器所做的工作。

由于AM在集群中运行，因此其故障不会影响集群[R6，R8]的可用性，但是由于AM故障而导致应用程序出现故障的可能性高于Hadoop1.x。如果AM失败，则RM可能会重启AM，尽管平台不支持恢复AM状态。重新启动的AM与自己正在运行的容器进行同步也不是该平台关注的问题。例如，Hadoop MapReduce AM将恢复其已完成的任务，但是在撰写本文时，正在运行的任务以及AM恢复期间完成的任务将被终止并重新运行。

最后，容器本身的故障处理完全留给框架。RM收集来自NM的所有容器退出事件，并在心跳响应中将其传播到相应的AM。MapReduce ApplicationMaster已经侦听这些通知，并通过从RM请求新容器来重试map或reduce任务。

这样，我们就结束了对体系结构的介绍，并深入研究了YARN的实际安装部署。

4. 现实中的YARN

我们知道一些大型公司正在积极使用YARN。以下报告了我们在Yahoo!上运行YARN的经验。然后，我们接着讨论一些已移植到YARN的流行框架。

4.1 Yahoo!上的YARN

Yahoo!将生产网格从传统Hadoop的稳定分支之一升级到YARN。我们在下文中报告的统计数据是关于传统Hadoop升级前的最后30天以及从升级时间（每个网格不同）到2013年6月13日的平均统计数据。在解释以下统计数据时，请注意以下重要事项：我们将要呈现的结果来自大型集群的实际升级经验，该集群的重点是保持关键共享资源的可用性，而不是像典型的合成实验那样注重科学的可重复性/一致性。为了帮助读者轻松地解释结果，我们将报告一些全局统计数据，然后重点介绍在升级前后硬件（大部分）没有变化的大型网格，最后确定该特定网格上的工作负载转移特性。

4.1.1 所有集群上的YARN

总之，升级后，YARN在所有集群中每天处理约500000个作业，每天总计超过230个计算年。底层存储超过350 PB。

YARN的最初目标之一是提高可扩展性，而Yahoo!报告表示它们运行的集群不超过4000个节点，这些节点曾经是YARN之前最大的集群。YARN带来的资源利用率的显著提高增加了每个网格可以维持的作业数量。这完全消除了当前进一步扩展的需要，甚至使运营团队能够延迟重新配置已停用的7000多个节点。

另一方面，YARN的日志聚合组件似乎增加了对HDFS NameNode的压力，尤其是对于大型作业。现在估计NameNode是Yahoo!集群中的可扩展性的瓶颈。幸运的是，社区中正在进行大量工作，以通过优化YARN日志聚合来提高NameNode的吞吐量并减轻NameNode的压力。在具有大量小型应用程序的几个大型集群中，已观察到YARN中的可扩展性问题，但是心跳处理方面的最新改进已缓解了其中一些问题。

4.1.2 某个特定集群的统计信息

现在，我们将重点介绍Yahoo!网格运营团队在一个特定的2500节点网格上运行YARN的经验和统计数据。

图2显示了之前/之后，运营团队可以轻松地在2500个机器集群上运行的负载。这是Yahoo!上最繁忙的集群一直被逼近极限。在图2a中，我们显示正在运行的作业数量显著增加：从Hadoop 1.0版本上的约77k增长到YARN上的约10万个定时作业。此外，这个集群达到每天125K作业持续吞吐量，其峰值在每天约15万作业（或几乎两倍于此集群以前的舒适区的作业数量）。平均作业大小从58个map，20个reducer增加到85个map，16个reducer - 请注意，这些作业包括用户作业以及系统应用程序产生的其他微小作业，例如通过distcp，Oozie[19]等进行数据复制/传输数据，以及其他数据管理框架。同样，所有作业的任务数量从Hadoop 1.0上的4M增加到YARN上的平均约1000万，持续负载约为1200万，峰值约为1500万 - 见图2。

评估集群管理系统效率的另一个关键指标是平均资源利用率。同样，工作负载的变化使我们将要讨论的统计信息在直接比较中的用处不大，但是我们发现CPU利用率（通过汇总所有计量的CPU时间并除以计量的节点正常运行时间进行计算。）显著增加。在Hadoop 1.0上，评估的CPU使用率徘徊在2500台计算机上的320％或3.2/16个核上。从本质上讲，转移到YARN时，CPU利用率几乎翻了一番，相当于每次6个连续绑定的核，最高峰值为10个完全利用的核。总体而言，这表明YARN能够完全占用约2.8 * 2500 = 7000个核来完全忙于运行用户代码。这与我们上面讨论的集群上运行的作业和任务数量的增加是一致的。可以部分解释这些改进的最重要的体系结构差异之一就是消除了map和reduce槽之间的静态拆分。

在图3中，我们绘制了一段时间内的几个作业统计信息：并发运行的和挂起的容器，已提交的、已完成的、正在运行的和待处理的作业。这显示了资源管理器处理大量应用程序、容器请求和执行的能力。此集群中使用的CapacityScheduler版本尚未使用抢占功能，因为这是最近添加的功能。尽管尚未对抢占进行大规模测试，但我们认为谨慎使用抢占将显著提高集群利用率，但我们在5.3节中显示了一个简单的微基准测试。

为了进一步表征在此集群上运行的工作负载的特性，我们在图4中显示了不同大小的应用程序的直方图，该直方图描绘了：1）每个存储桶中的应用程序总数，2）该存储桶中的应用程序使用的CPU总数 ，以及3）该存储桶中应用程序使用的容器总数。正如过去观察到的那样，尽管大量应用程序非常小，但它们只占集群容量的一小部分（在这2500台计算机集群中，大约价值3.5核CPU每台机器）。有趣的是，如果比较插槽利用率与CPU利用率，我们会发现大型作业似乎为每个容器使用更多的CPU。这与更好地调整大型作业（例如，一致地使用压缩）以及可能运行更长的任务相一致，从而分摊了启动开销。

总体而言，Yahoo!报告指出，为将YARN加强为可用于生产的可扩展系统而进行的工程工作非常值得。计划继续升级到最新版本2.1-beta，以保持快速发展势头。经过积累了36000年计算时间和数月的生产压力测试，Yahoo的运营团队证实YARN的架构转变对他们的工作负载非常有利。在下面的引号中对此进行了很好的总结：“升级到YARN相当于增加1000台机器[到目前为止2500台机器的集群]”。

4.2 应用程序和框架

YARN的关键要求是使编程模型具有更大的灵活性。尽管YARN在撰写本文时为Beta版本，但它已经被YARN吸引的许多编程框架所证实。我们简要总结了YARN原生的或移植到平台上的一些项目，以说明其体系结构的通用性。

Apache Hadoop MapReduce已经可以在YARN上使用几乎相同的功能集。它已进行了大规模测试，对生态系统中其他项目（如Pig、Hive、Oozie等）进行了修改，使其可以在YARN之上的MR之上工作，并具有与传统Hadoop相比处于同等或更好水平的基准测试。MapReduce社区已确保针对1.x编写的应用程序可以以完全二进制兼容的方式（mapred的API）或仅通过重新编译（mapreduce API的源码兼容性）在YARN上运行。

Apache Tez是一个Apache项目（在撰写本文时为Incubator），旨在提供通用的有向无环图（DAG）执行框架。其目标之一是提供一组构建基块，这些构建基块可以组合成任意DAG（包括一个简单的2阶段（Map和Reduce）DAG，以保持与MapReduce的兼容性）。Tez为诸如Hive和Pig的查询执行系统提供了更为自然的执行计划模型，以免强制将这些计划转换为MapReduce。当前的重点是加快复杂的Hive和Pig查询，这些查询通常需要多个MapReduce作业，从而可以作为单个Tez作业运行。将来，将考虑更丰富的功能，例如对交互式查询和通用DAG的一般支持。

Spark是来自加州大学伯克利分校[32]的开源研究项目，目标是机器学习和交互式查询工作负载。针对此类应用程序，利用弹性分布式数据集（RDD）的中心思想可以实现比传统MapReduce显著改进的性能。Spark最近已被移植到YARN[?]。

Dryad[18]将DAG作为执行流的抽象，并且已与LINQ[31]集成在一起。移植到YARN的版本是100％原生C ++和C＃用于工作者节点，而ApplicationMaster利用一薄层Java与原生Dryad图形管理器的ResourceManager进行对接。最终，Java层将被与协议缓冲区接口的直接交互所取代。YARN上的Dryad与其非YARN版本完全兼容。

Giraph是一个高度可扩展的、以顶点为中心的图形计算框架。它最初设计为在Hadoop 1.0之上运行，仅作为Map作业，在该作业中的一个map是特殊的并且充当协调者。移植到YARN的Giraph是很自然的，执行协调者的角色是由ApplicationMaster承担，并动态请求资源。

Storm是一个开源的分布式实时处理引擎，旨在跨集群机器扩展并提供并行流处理。一个常见的用例是将Storm用于在线计算，并将MapReduce用作批处理程序。通过将Storm移植到YARN上，可以释放资源分配的极大灵活性。此外，对底层HDFS存储层的共享访问简化了多框架工作负载的设计。

REEF元数据框架：YARN的灵活性在于对应用程序实现者的巨大投入。编写ApplicationMaster并处理容错、执行流程、协调等所有方面都是重大的努力。REEF项目[10]认识到了这一点，并排除了许多应用程序通用的一些难以构建的组件。这包括存储管理、高速缓存、故障检测、检查点、基于推送的控制流程（实验稍后展示）和容器再利用。框架设计人员可以在REEF之上构建，比直接在YARN上构建更容易，并且可以重用REEF提供的许多常见服务/库。REEF设计使其适用于MapReduce和DAG之类的执行以及迭代和交互式计算。

Hoya是一种Java工具，旨在利用YARN按需启动动态HBase集群[21]。在YARN上运行的HBase集群也可以动态增长和收缩（在我们的测试集群中，可以在不到20秒的时间内添加/删除RegionServer）。尽管仍在探索YARN中混合服务和批处理工作负载的启示，但该项目的早期结果令人鼓舞。

5. 实验

在上一节中，我们通过报告大型生产部署和繁荣的框架生态系统建立了YARN在现实世界中的成功。在本节中，我们将提供更具体的实验结果，以证明YARN的一些成功。

5.1 打破排序记录

在撰写本文时，YARN上的MapReduce实现正式持有Daytona和Indy GraySort基准测试记录，排序为1.42TB/min。同一系统也报告了（竞赛之外）在一分钟内排序1.61TB和1.50TB的MinuteSort成绩，优于现有的记录。实验在2100个节点上运行，每个节点配备了两个2.3Ghz hexcore Xeon E5-2630、64 GB内存和12x3TB磁盘。下表提供了结果摘要：

完整报告[16]提供了实验的详细说明。

5.2 MapReduce基准测试

MapReduce仍然是YARN上最重要和最常用的应用程序。我们很高兴地报告，与当前稳定的Hadoop-1发布版本1.2.1相比，大多数标准Hadoop基准测试在Hadoop 2.1.0中的YARN上表现更好。下面提供了将1.2.1与2.1.0进行比较的260节点集群上MapReduce基准测试的摘要。每个从节点都运行总计16核的2.27GHz Intel Xeon CPU，具有38GB物理内存和6x1TB 7200 RPM磁盘，每个磁盘均使用ext3文件系统格式。每个节点的网络带宽为1Gb/s。每个节点运行一个DataNode和一个NodeManager，并为容器分配了24GB RAM。我们在1.2.1中运行6个map和3个reduce，并在2.1.0中运行9个容器。每个map占用包含1.5GB JVM堆的2GB的总内存，而每个reduce占用包含3GB堆的4GB的总内存。JobTracker/ResourceManager运行在专用计算机上，HDFS NameNode也运行在专用计算机上。

我们将这些基准测试的结果解释如下。排序基准测试使用默认设置来衡量HDFS中1.52TB（每个节点6GB）排序的端到端时间。混洗基准测试可以仅使用合成数据校准将m个map的中间输出混洗为n个reduce的速度；记录都不是从HDFS读取或写入。虽然排序基准测试通常可以从HDFS数据路径的改进中受益，但两个基准测试在YARN上的性能都更好，这主要是由于MapReduce运行时本身的重大改进：map端排序的改进，reduce客户端流水线式的批量输出，和基于Netty[3]的服务器端混洗。扫描和DFSIO作业是用于评估在Hadoop MapReduce下运行的HDFS和其他分布式文件系统的规范基准；表1中的结果是我们实验中可归因于HDFS的效果的粗略度量。我们对集群的访问时间太短，无法调试和表征2.1.0文件系统的中等性能。尽管有这种噪音，即使YARN的设计针对多租户吞吐量进行了优化，但其单项作业的性能也可与中央协调器相竞争。

AM可扩展性基准测试通过使AM充满容器簿记职责来衡量单作业的鲁棒性。表1包括对MapReduce AM的两次测量。第一个实验是限制可用资源以匹配1.x部署的插槽可用性。当我们取消此人为限制并允许YARN使用整个节点时，其性能将大大提高。这两个实验测量了类型化插槽的开销。我们还将性能提高归因于更频繁的节点心跳和更快的调度周期，我们将在下面对此进行详细讨论。由于YARN主要负责分发和启动应用程序，因此我们将可扩展性基准测试视为一项关键指标。

我们在生产集群中观察到的针对YARN的瓶颈中的一些体系结构选择。如2.3节所述，类型化插槽会在节点上的可替代资源供应与执行Hadoop MapReduce任务的语义之间造成人为的不匹配，从而损害吞吐量。虽然第4.1节介绍了总体工作负载的收益，但我们看到即使调度单个作业也有好处。我们将此收益的大部分归因于改进的心跳处理。在Hadoop-1中，由于JobTracker中的粗粒度锁，每个节点在大型集群中只能每30-40秒进行一次心跳。尽管有巧妙的解决方法来降低延迟，例如用于处理轻量级更新的短路路径和用于加速重要通知的自适应延迟，但JobTracker中的协调状态仍然是大型集群中延迟的主要原因。相反，NodeManager会每1-3秒发送一次心跳。RM代码具有更高的可扩展性，而且它也解决了每个请求的一系列限制。

5.3 抢占的好处

在图5中，我们展示了YARN中最近添加的功能：使用保留工作的抢占来执行全局属性的能力。我们在一个小型（10台计算机）集群上进行了实验，以强调保留工作的抢占的潜在影响。集群运行CapacityScheduler，配置了两个队列A和B，分别拥有80％和20％的容量。一个MapReduce作业在较小的队列B中提交，几分钟后另一个MapReduce作业在较大的队列A中提交。在图中，我们显示了在三种配置下分配给每个队列的容量：1）没有给其超出保证提供容量（固定容量）的队列；2）队列可能消耗集群容量的100％，但不执行抢占；3）队列可能消耗集群容量的100％，但容器可能被抢占。保留工作的抢占使调度器可以过量使用队列B的资源，而不必担心队列A中的应用程序处于饥饿状态。当队列A中的应用程序请求资源时，调度器会发出抢占请求，这些请求由ApplicationMaster通过其任务的检查点并生成容器来进行服务。与情况(2)容量重新平衡大约需要20分钟的情况相反，这允许队列A在几秒钟内获得其所有保证的容量（集群的80％）。最后，由于我们使用的抢占是基于检查点的，并且不会浪费工作，因此在B中运行的作业可以从中断的位置重新启动任务，这样可以高效地进行工作。

5.4 Apache Tez的改进

当在运行于Apache Tez上的Apache Hive中运行决策支持查询时，我们提供了一些基本的改进（在撰写本文时，是在早期阶段进行集成）。从TPC-DS基准测试[23]进行的查询涉及的联接、过滤器和分组汇总很少。即使经过积极的计划级别优化，Hive在使用MapReduce时也会生成由多个作业组成的执行计划。针对Tez执行时，相同的查询会导致线性DAG，具有单个Map阶段，然后是多个Reduce阶段。在20个节点的集群上使用MapReduce时，针对200比例因子数据的查询执行时间为54秒，而使用Tez时，查询执行时间则缩短为31秒。这种节省的大部分可归因于多个MapReduce作业的调度和启动开销，并避免了将中间MapReduce作业的输出持久保存到HDFS的不必要步骤。

5.5 REEF：会话的低延迟

YARN的关键方面之一是，它使建立在其上的框架能够按需管理容器和通信。我们通过利用REEF提供的容器重用和基于推送的通信的概念来展示这一点。该实验基于一个基于REEF的简单分布式外壳应用程序。提交一系列Unix命令（例如，date）时，我们会在完全空闲的集群上测量客户端的延迟。发出的第一个命令会招致调度应用程序和获取容器的全部开销，而随后的命令会通过客户端和ApplicationMaster快速转发到已经运行的容器中以执行。基于推送的消息传递进一步减少了延迟。我们实验中的加速非常可观，接近三个数量级 - 从超过12秒到平均31ms。

6. 相关工作

其他人已经意识到传统Hadoop架构中的相同局限性，并同时开发了替代解决方案，可以与YARN进行比较。与YARN最相似的众多努力包括：Mesos[17]、Omega[26]、Corona[14]和Cosmos[8]，分别由Twitter、Google、Facebook和Microsoft维护和使用。

这些系统具有共同的灵感，并且有改善可扩展性、延迟和编程模型灵活性的高级目标。许多架构差异反映了不同的设计优先级，有时甚至是不同历史背景的影响。虽然无法提供真正的定量比较，但我们将尝试强调一些体系结构差异以及我们对其基本原理的理解。

Omega的设计更倾向于分布式多层次调度。这反映了对可扩展性的更多关注，但使执行诸如容量/公平性/截止期限之类的全局属性变得更加困难。为了实现这一目标，作者似乎依赖于各种框架的协调开发，以及这些框架在运行时会相互尊重。对于像Google这样的封闭世界来说，这是明智的选择，但对于像Hadoop这样的开放平台则不可行，在Hadoop中，来自不同独立来源的任意框架共享同一集群。

与YARN和其他框架中基于心跳的控制面板框架方法相反，Corona使用基于推送的通信。延迟/可扩展性的折衷是重大的，应该进行详细的比较。

尽管Mesos和YARN都有两个层级的调度器，但是有两个非常重要的区别。首先，Mesos是基于供给的资源管理器，而YARN是基于请求的方法。YARN允许AM根据包括位置在内的各种标准来请求资源，允许请求者根据给出的内容和当前使用情况更改将来的请求。我们的方法对于支持基于位置的分配是必要的。其次，Mesos不是用每个作业的框架内调度器，而是利用了中央调度器池（例如，传统的Hadoop或MPI）。YARN支持将容器后期绑定到任务，每个任务都可以执行本地优化，并且似乎更适合滚动升级（因为每个任务都可以在框架的不同版本上运行）。另一方面，每个作业的ApplicationMaster可能比Mesos的方法导致更大的开销。

Cosmos在存储和计算层方面在架构上与Hadoop 2.0非常相似，主要区别在于没有中央资源管理器。但是，它似乎只用于一种应用程序类型：Scope[8]。由于目标范围更窄，Cosmos可以利用许多优化功能，例如本地压缩，索引文件，数据集分区的协同定位，以加快Scope的速度。多个应用程序框架的行为尚不清楚。

在这些最近的努力以前，在资源管理和调度方面有悠久的历史 - Condor[29]、Torque[7]、Moab[13]和Maui[20]。我们早期的Hadoop集群使用了其中一些系统，但是我们发现它们无法以最好的方式支持MapReduce模型。具体来说，既不能表示数据本地性，又不能表示map和reduce阶段的弹性调度需求，因此被迫分配附带第2.1节中讨论的使用成本的“虚拟”Hadoop。其中的某些问题可能是由于以下事实造成的：许多此类分布式调度器最初都是为支持MPI样式和HPC应用程序模型并运行粗粒度的非弹性工作负载而创建的。这些集群调度器的确允许客户端指定处理环境的类型，但不幸的是，本地化限制不是Hadoop的主要问题。

另一类相关技术来自云基础架构领域，例如EC2、Azure、Eucalyptus和VMWare的产品。这些主要针对集群的基于VM的共享，并且通常是为长时间运行的进程而设计的（因为VM引导时间的开销太高了）。

7. 结论

在本文中，我们总结了对Hadoop历史的回顾，并讨论了胡乱使用及新型应用程序如何使初始架构远远超出了其设计要实现的范围。然后，我们描述了导致YARN的渐近但意义深远的体系结构转变。由于资源管理和编程框架之间的脱钩，YARN提供了：1）更好的可扩展性，2）更高的效率，以及3）使大量不同的框架有效地共享集群。这些要求在实验上（通过基准测试）和通过展示Yahoo!的大规模生产经验都得到了证实，而Yahoo!的集群现已100％在YARN上运行。最后，我们通过提供社区活动的快照并简要报告已移植到YARN的许多框架，试图捕获围绕该平台的大量令人兴奋的事物。我们相信YARN既可以作为坚实的生产框架，也可以作为研究社区的宝贵运动场。

8. 致谢

我们通过承认YARN体系的血统开始了YARN的阐述。多年来，它对所有开发、操作、测试、支持、记录、宣传、资助、尤其是所有使用过的Apache Hadoop的人的债务都是无法估量的。最后，我们认识到一些。Ram Marti和Jitendranath Panday影响了其安全性设计。Dick King，Krishna Ramachandran，Luke Lu，Alejandro Abdelnur，Shenjiejie，Omkar Vinit Joshi，Jian He为实现工作做出了或将继续做出重大贡献。Karam Singh，Ramya Sunil，Rajesh Balamohan和Srigurunath Chakravarthi一直在测试和性能基准测试方面提供很大帮助。Rajive Chittajallu和Koji Noguchi分别从运营和用户支持的角度帮助引导需求和洞察力。我们感谢Yahoo!通过大量贡献和大量使用来支持YARN，还共享其一些集群的统计信息。我们感谢Dennis Fetterly和Sergiy Matusevych提供了有关Dryad和REEF的一些实验结果，以及Mayank Bansal帮助提供了2.1.0 MapReduce基准测试。最后但并非最不重要的一点是，Apache Hadoop YARN仍然是一个社区驱动的开源项目，其成功很大程度上要归功于Apache Hadoop YARN和MapReduce社区 - 在此感谢所有以各种方式帮助YARN的参与者和提交者。

附录A. 传统Hadoop

在YARN之前，Hadoop MapReduce集群由一个称为JobTracker（JT）的主节点和运行TaskTracker（TT）的工作节点组成。用户向JT提交了MapReduce作业，JT协调了各个TT中的任务执行。TT由操作者配置，具有固定数量的map插槽和reduce插槽。TT会定期向JT发送心跳，以报告该节点上正在运行的任务的状态并确认其活跃性。在心跳中，JT会更新与该节点上运行的任务相对应的状态，代表该作业执行操作（例如，调度失败的任务以重新执行），将该节点上的空闲时隙与调度器不变量进行匹配，在可用资源上匹配符合条件的作业，偏向于在有本地数据的节点上执行任务。

作为计算集群的中央仲裁者，JT还负责准入控制、跟踪TT的活动性（以重新执行正在运行的或输出不可用的任务）、以推测执行方式启动任务以绕过路由到的慢节点、通过Web服务器向用户报告作业状态、记录审核日志和汇总统计信息、验证用户身份以及其他许多功能；这些都限制了它的可扩展性。

参考文献

1. Apache hadoop. http://hadoop.apache.org.
2. Apache tez. http://incubator.apache.org/projects/tez.html.
3. Netty project. http://netty.io.
4. Storm. http://storm-project.net/.
5. H. Ballani, P. Costa, T. Karagiannis, and A. I. Rowstron. Towards predictable datacenter networks. In SIGCOMM, volume 11, pages 242–253, 2011.
6. F. P. Brooks, Jr. The mythical man-month (anniversary ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.
7. N. Capit, G. Da Costa, Y. Georgiou, G. Huard, C. Martin, G. Mounie, P. Neyron, and O. Richard. A batch scheduler with high level components. In Cluster Computing and the Grid, 2005. CCGrid 2005. IEEE International Symposium on, volume 2, pages 776–783 Vol. 2, 2005.
8. R. Chaiken, B. Jenkins, P.-A. Larson, B. Ramsey, D. Shakib, S.Weaver, and J. Zhou. Scope: easy and efficient parallel processing of massive data sets. Proc. VLDB Endow., 1(2):1265–1276, Aug. 2008.
9. M. Chowdhury, M. Zaharia, J. Ma, M. I. Jordan, and I. Stoica. Managing data transfers in computer clusters with orchestra. SIGCOMMComputer Communication Review, 41(4):98, 2011.
10. B.-G. Chun, T. Condie, C. Curino, R. Ramakrishnan, R. Sears, and M. Weimer. Reef: Retainable evaluator execution framework. In VLDB 2013, Demo, 2013.
11. B. F. Cooper, E. Baldeschwieler, R. Fonseca, J. J. Kistler, P. Narayan, C. Neerdaels, T. Negrin, R. Ramakrishnan, A. Silberstein, U. Srivastava, et al. Building a cloud for Yahoo! IEEE Data Eng. Bull., 32(1):36–43, 2009.
12. J. Dean and S. Ghemawat. MapReduce: simplified data processing on large clusters. Commun. ACM, 51(1):107–113, Jan. 2008.
13. W. Emeneker, D. Jackson, J. Butikofer, and D. Stanzione. Dynamic virtual clustering with xen and moab. In G. Min, B. Martino, L. Yang, M. Guo, and G. Rnger, editors, Frontiers of High Performance Computing and Networking, ISPA 2006 Workshops, volume 4331 of Lecture Notes in Computer Science, pages 440–451. Springer Berlin Heidelberg, 2006.
14. Facebook Engineering Team. Under the Hood: Scheduling MapReduce jobs more efficiently with Corona. http://on.fb.me/TxUsYN, 2012.
15. D. Gottfrid. Self-service prorated super-computing fun. http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-super-computing-fun, 2007.
16. T. Graves. GraySort and MinuteSort at Yahoo on Hadoop 0.23. http://sortbenchmark.org/Yahoo2013Sort.pdf, 2013.
17. B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A. D. Joseph, R. Katz, S. Shenker, and I. Stoica. Mesos: a platform for fine-grained resource sharing in the data center. In Proceedings of the 8th USENIX conference on Networked systems design and implementation, NSDI’11, pages 22–22, Berkeley, CA, USA, 2011. USENIX Association.
18. M. Isard, M. Budiu, Y. Yu, A. Birrell, and D. Fetterly. Dryad: distributed data-parallel programs from sequential building blocks. In Proceedings of the 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007, EuroSys ’07, pages 59–72, New York, NY, USA, 2007. ACM.
19. M. Islam, A. K. Huang, M. Battisha, M. Chiang, S. Srinivasan, C. Peters, A. Neumann, and A. Abdelnur. Oozie: towards a scalable workflow management system for hadoop. In Proceedings of the 1st ACM SIGMOD Workshop on Scalable Workflow Execution Engines and Technologies, page 4. ACM, 2012.
20. D. B. Jackson, Q. Snell, and M. J. Clement. Core algorithms of the maui scheduler. In Revised Papers from the 7th International Workshop on Job Scheduling Strategies for Parallel Processing, JSSPP ’01, pages 87–102, London, UK, UK, 2001. Springer-Verlag.
21. S. Loughran, D. Das, and E. Baldeschwieler. Introducing Hoya – HBase on YARN. http://hortonworks.com/blog/introducing-hoya-hbase-on-yarn/, 2013.
22. G. Malewicz, M. H. Austern, A. J. Bik, J. C. Dehnert, I. Horn, N. Leiser, and G. Czajkowski. Pregel: a system for large-scale graph processing. In Proceedings of the 2010 ACM SIGMOD International Conference on Management of data, SIGMOD’10, pages 135–146, New York, NY, USA, 2010. ACM.
23. R. O. Nambiar and M. Poess. The making of tpcds. In Proceedings of the 32nd international conference on Very large data bases, VLDB ’06, pages 1049–1058. VLDB Endowment, 2006.
24. C. Olston, B. Reed, U. Srivastava, R. Kumar, and A. Tomkins. Pig Latin: a not-so-foreign language for data processing. In Proceedings of the 2008 ACM SIGMOD international conference on Management of data, SIGMOD ’08, pages 1099–1110, New York, NY, USA, 2008. ACM.
25. O. O’Malley. Hadoop: The Definitive Guide, chapter Hadoop at Yahoo!, pages 11–12. O’Reilly Media, 2012.
26. M. Schwarzkopf, A. Konwinski, M. Abd-El-Malek, and J. Wilkes. Omega: flexible, scalable schedulers for large compute clusters. In Proceedings of the 8th ACM European Conference on Computer Systems, EuroSys ’13, pages 351–364, New York, NY, USA, 2013. ACM.
27. K. Shvachko, H. Kuang, S. Radia, and R. Chansler. The Hadoop Distributed File System. In Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), MSST’10, pages 1–10, Washington, DC, USA, 2010. IEEE Computer Society.
28. T.-W. N. Sze. The two quadrillionth bit of p is 0! http://developer.yahoo.com/blogs/hadoop/twoquadrillionth-bit-0-467.html.
29. D. Thain, T. Tannenbaum, and M. Livny. Distributed computing in practice: the Condor experience. Concurrency and Computation: Practice and Experience, 17(2-4):323–356, 2005.
30. A. Thusoo, J. S. Sarma, N. Jain, Z. Shao, P. Chakka, N. Z. 0002, S. Anthony, H. Liu, and R. Murthy. Hive - a petabyte scale data warehouse using Hadoop. In F. Li, M. M. Moro, S. Ghandeharizadeh, J. R. Haritsa, G. Weikum, M. J. Carey, F. Casati, E. Y. Chang, I. Manolescu, S. Mehrotra, U. Dayal, and V. J. Tsotras, editors, Proceedings of the 26th International Conference on Data Engineering, ICDE 2010, March 1-6, 2010, Long Beach, California, USA, pages 996–1005. IEEE, 2010.
31. Y. Yu, M. Isard, D. Fetterly, M. Budiu, U. Erlingsson, P. K. Gunda, and J. Currey. DryadLINQ: a system for general-purpose distributed data-parallel computing using a high-level language. In Proceedings of the 8th USENIX conference on Operating systems design and implementation, OSDI’08, pages 1–14, Berkeley, CA, USA, 2008. USENIX Association.
32. M. Zaharia, M. Chowdhury, M. J. Franklin, S. Shenker, and I. Stoica. Spark: cluster computing with working sets. In Proceedings of the 2nd USENIX conference on Hot topics in cloud computing, HotCloud’10, pages 10–10, Berkeley, CA, USA, 2010. USENIX Association.