独家 | 一文读懂Hadoop（四）：YARN

随着全球经济的不断发展，大数据时代早已悄悄到来，而Hadoop又是大数据环境的基础，想入门大数据行业首先需要了解Hadoop的知识。2017年年初apache发行了Hadoop3.0，也意味着一直有一群人在对Hadoop不断的做优化，不仅如此，各个Hadoop的商业版本也有好多公司正在使用，这也印证了它的商业价值。

读者可以通过阅读“一文读懂Hadoop”系列文章，对Hadoop技术有个全面的了解，它涵盖了Hadoop官网的所有知识点，并且通俗易懂，英文不好的读者完全可以通过阅读此篇文章了解Hadoop。

本期独家内容“一文读懂Hadoop”系列文章 先介绍 Hadoop ，继而分别详细介绍 HDFS 、 MAPREDUCE 、 YARN 的所有知识点， 分为四期内容在近几天推送。 欢迎关注往期内容。

本期内容为大家详解 YARN ：

1. 简介

YARN 的基本思想是将资源管理和作业调度的功能分成独立的守护进程。 ResourceManager 和 NodeManager 构成了数据计算框架，其中 ResourceManager （ RM ）负责协调整个系统的所有应用程序的资源， NodeManager 是每个机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU ，内存，硬盘，网络 ) 并且向 ApplicationMaster 汇报。每个应用程序的 ApplicationMaster 实际上是一个负责跟 ResourceManager 协商资源，和 NodeManager 一起执行和监控任务的框架。

MapReduce 下一代架构

ResourceManager 拥有两大主要组件： Scheduler和ApplicationsManager 。

• Scheduler 负责给所有的运行的应用程序分配资源，受制于容量和队列等。 Scheduler 仅仅是调度而不关心应用程序的状态监控跟踪。也不保证失败任务和应用失败以及硬件失败。仅仅关心应用程序的资源需求，是一个抽象的资源容器，包括内存， cpu ，硬盘，网络等元素；

• Scheduler 是插件化的负责在各种队列和应用程序直接隔离集群资源，现在的 MR 调度机制包括 CapacityScheduler 和 FairScheduler 都是插件化的；

• CapacityScheduler 支持层次队列，支持共享集群资源；

• ApplicationsManager 负责接收任务提交，协调容器去执行应用 , 尤其 ApplicationMaster ，同时当 ApplicationMaster 失败了提供重启服务；

• NodeManager 在每个节点上都有，负责容器，监控资源使用情况，上报状态信息到 ResourceManager/Scheduler ；

• 每个应用的 ApplicationMaster 用于协调从 Scheduler 的资源容器状态跟踪监控。

2. 命令

2.1 概述

YARN 命令由 bin/yarn 脚本调用。运行不带任何参数的 yarn 脚本将打印所有命令的描述。

用法： yarn [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]

2.2 用户命令

Hadoop 集群用户使用的命令。

2.3 管理命令

Hadoop 集群管理员使用的命令。

3. 调度

3.1 容量调度

3.1.1 目的

容量调度，对于 Hadoop 的一个可插入的调度程序，允许用于 multiple-tenants 安全地共享一个大集群，使得他们的应用程序是根据所分配容量限制分配资源，及时处理。

3.1.2 概述

该容量调度被设计为运行 Hadoop 的一个共享的应用程序，在操作者友好的方式 multi-tenant 实现集群的最大化吞吐量和集群的最大利用率。

传统上每个组织都有它自己的私有组具有足够的能力来满足组织的 SLA 下的峰值或接近峰值条件下的计算资源。这通常会导致平均利用率和管理多个独立的群集不平衡，使之成为每个组织开销之一。组织之间共享集群是运行大型的 Hadoop 的安装，因为这使他们能够获得规模经济的好处，而无需创建私人集群的成本效益的方式。然而，组织都在关注共享群集，因为他们担心别人使用，这是他们的 SLA 至关重要的资源。

该容量调度被设计成允许共享一个大的集群，同时给每个组织能力的保证。其中心思想是，在 Hadoop 集群中的可用资源，谁共同出资建设集群的基础上需要计算需求多个组织之间共享。有一个组织可以访问不被他人使用任何产能过剩的一个额外的好处。这提供了弹性的组织以具有成本效益的方式。

跨组织共享集群就必须对 multi-tenant 的大力支持，因为每个组织必须保证能力和安全防护装置，以确保共享群集是不受单个表面应用程序或用户或设定物。该容量调度提供了一套严格的限制，以确保单个应用程序或用户或队列都不能消耗在集群中的资源不成比例。此外，容量调度提供 initialized/pending。

从单用户应用程序的限制和排队控制，以确保公平集群和稳定性。

由容量调度提供的初级抽象是队列中的概念。这些队列通常设置由管理员反映共享集群的经济性。

为进一步控制和可预测的资源共享，在容量调度支持层次化队列，以确保资源的子队列的组织之间共享其他队列。

3.2 公平调度

3.2.1 目的

公平调度，一个用于 Hadoop 的可插入调度程序，它允许 YARN 应用程序公平地共享大型集群中的资源。

3.2.2 介绍

公平调度是将资源分配给应用程序的方法，使所有的应用程序得到的平均值，资源随时间的相等份额。 Hadoop 的下一代系统能够调度多个资源类型。默认情况下，公平调度器调度仅在内存中实现公平调度。它可以被配置为内存和 CPU 调度，利用资源优势公平的概念。此方法有由 Ghodsi 等人开发的。在应用程序使用的集群中，当有一个单一的应用程序运行时。当其他应用程序提交后，即释放被分配给新的应用程序的资源，这样每个应用程序对最终得到的资源量大致相当。不同于默认 Hadoop 的调度，形成应用程序的队列，这让短暂的应用程序在合理的时间内完成，而不会饿死长时间运行的应用程序。它也是一种合理的方式来共享多个用户之间的集群资源。最后在公平共享的同时还能配合的应用程序优先级 作为权重来确定总的资源为每个应用程序应该得到的资源数。

调度组织进一步应用到 “ 队列 ” ，并在这些队列之间分享资源 ?? 。默认情况下，所有用户共享一个单一的队列，命名为 “default” 。如果一个应用程序专门列出一个队列在一个容器资源请求，该请求被提交到该队列。它也可以分配基于包括通过配置请求中的用户名的队列。在每个队列调度策略用于共享运行的应用程序之间的资源。默认的是基于存储器的公平共享，但是 FIFO 和多资源具有优势资源公平也可以配置。队列可以被安排在一个层次结构来划分资源，并与重量配置为共享集群中的特定比例。

除了提供公平共享，公平调度器允许分配最低保证分享的队列，这是保证某些用户，组或生产应用程序总能得到足够的资源是有效的。当队列中包含的应用程序，它得到至少为其最小的份额，但是当队列并不需要它的全面保证份额，则超出部分拆分其他正在运行的应用程序之间。这让调度保障能力的同时有效地利用资源，当这些队列不包含应用程序的队列。

公平调度器让默认情况下运行的所有应用程序，但它也可以通过配置文件限制运行的每个用户和每个队列的应用程序的数量。这可能是有用的，当一个用户必须同时提交上百的应用程序，或在总体上提高性能，如果同时运行了太多的应用程序会导致创建太多的中间数据或过多的上下文切换。限制应用程序不会造成任何其后提交的应用程序失败，只能等待调度的队列中，直到一些用户的较早的应用程序完成的。

3.3 机会型容器

3.3.1 主要目标

与仅存在未分配资源时在节点中调度的现有 YARN 容器不同，机会性容器可以被分派到 NM ，即使它们在该节点处的执行不能立即开始。在这种情况下，机会性容器将在该 NM 处排队，直到资源变得可用。机会性容器执行的主要目标是提高集群资源利用率，从而增加任务吞吐量。资源利用率和任务吞吐量改进对于包括相对较短任务（秒级）的工作负载更加明显。

3.3.2 概述

YARN （公平和容量调度程序）中的现有调度程序仅在调度容器时在该节点上有未分配资源时才将容器分配给节点。这种保证的执行类型的优点在于，一旦 AM 将容器分派给节点，容器执行将立即开始，因为它保证将有可用的资源。此外，除非违反公平或能力限制，否则保证容器运行到完成而不被抢占。

虽然此设计提供了更可预测的任务执行，但它有两个主要缺点，可能导致次优的集群资源利用率：

• 反馈延迟。 当容器在节点完成其执行时， RM 通过下一个 NM-RM 心跳通知有可用资源，然后 RM 在该节点调度新容器， AM 通过下一个 AM-RM 心跳通知，最后 AM 在节点启动新的容器。这些延迟导致空闲节点资源，这又导致较低的资源利用，特别是当工作负载涉及持续时间相对较短的任务时。

• 分配与已利用资源。 RM 基于在每个节点处分配的资源来分配容器，这可能显着高于实际使用的资源（例如，考虑已经分配了 4GB 内存但仅使用 2GB 的容器）。这降低了有效的资源利用，并且如果 RM 在调度期间考虑所利用的资源，则可以避免这种情况。然而，这必须以允许在运行的容器的所利用的资源增加的情况下回收资源的方式来完成。

为了减轻上述问题，除现有的容器，我们介绍的概念机会主义容器。即使在调度的时刻没有可用的（未分配的）资源，也可以将机会性容器分派给 NM 。在这种情况下，机会性容器将在 NM 处排队，等待资源变得可用于其开始执行。机会性容器具有比保证容器低的优先级，这意味着它们可以被抢占以保证容器开始它们的执行。因此，它们可以用于提高集群资源利用率，而不会影响现有保证容器的执行。

机会性容器的另一个优点是它们在 NM 处引入执行优先级的概念。例如，不要求严格执行保证的较低优先级作业可以对其任务使用机会性容器或容器执行类型的混合。

我们介绍了两种分配机会主义容器的方法：集中式和分布式。在集中式调度中，机会性容器通过 YARN RM 分配，而在分布式容器中，通过驻留在每个 NM 的本地调度器来分配。集中式分配允许更高质量的布置决策，并且实现跨应用的更多涉及的共享策略（例如，公平性）。另一方面，分布式调度可以提供更快的容器分配，这对于短任务是有用的，因为它避免了到 RM 的往返。在这两种情况下，保证容器的调度保持完整，并通过 YARN RM （使用现有的公平或容量调度程序）进行。

注意，在当前实现中，我们基于分配（和未使用）资源来分配容器。因此，我们处理上述 “ 反馈延迟 ” 问题，而不是 “ 分配与利用资源 ” 问题。

3.4 YARN安全容器

3.4.1 安全容器概述

• 容器隔离

容器执行器必须访问容器所需的本地文件和目录，例如 jar ，配置文件，日志文件，共享对象等。虽然它是由 NodeManager 启动的，但容器不应该访问 NodeManager 的私有文件和配置。运行由不同用户提交的应用程序的容器应该隔离，并且无法访问其他文件和目录。

• Linux 安全容器执行程序

在 Linux 环境中，安全容器执行程序是 LinuxContainerExecutor 。它使用一个名为 container-executor 的外部程序来启动容器。此程序具有 setuid 访问权限标志，允许其启动具有 YARN 应用程序用户权限的容器。

3.4.2 Yarn的工作流程

步骤 1 ： 用户将应用程序提交到 ResourceManager 上。

步骤 2 ： ResourceManager 为应用程序 ApplicationMaster 申请资源，并与某个 NodeManager 通信，以启动 ApplicationMaster 。

步骤3： ApplicationMaster 与 ResourceManager 通信，为内部要执行的任务申请资源，一旦得到资源后，将于 NodeManager 通信，以启动对应的任务。

步骤4： 所有任务运行完成后， ApplicationMaster 向 ResourceManager 注销，整个应用程序运行结束。

上述步骤中，步骤 2~3 涉及到资源申请与使用，而这正是 Container 出现的地方。

4. ResourceManger

4.1 概述

ResourceManager 是管理资源和调度 YARN 中运行的 application 的中心机构。因此，它在 Apache YARN 集群中存在潜在的单点故障。下面给出有关 ResourceManager Restart 特性，该特性强化 ResourceManager 可以跨越重启操作继续运转，另外让 ResourceManager 的停机时间对终端用户不可见。

ResourceManager Restart 特性分成两个阶段：

• ResourceManager Restart 阶段 1 （ Non-work-preserving RM restart ）： RM 在插件化的 state-store 中持久化 application/attempt 状态以及其他证书信息。在重启过程中 RM 会从 state-store 中重载这些信息，并且重新启动之前 Running 的 application 。用户不需要重新提交这些 application 。

• ResourceManager Restart 阶段 2 (Work-preserving RM restart): 聚焦在通过结合重启过程中来自 NodeManager 的容器状态和来自 ApplicationMaster 的容器请求重新构建 ResourceManager 的运行状态。与阶段 1 的关键不同是之前运行中的应用程序在 RM 重启中不会被 kill ，所以 application 不会因为 RM 的中断丢失它的工作内容。

4.2 高可用性

ResourceManager （ RM ）负责跟踪集群中的资源，并调度应用程序（例如 MapReduce 作业）。在 Hadoop 2.4 之前， ResourceManager 是 YARN 集群中的单点故障。高可用性功能以活动 / 备用 ResourceManager 添加冗余，以消除这种单点故障。

5. NodeManager

NodeManager （ NM ）是 YARN 中每个节点上的代理，它管理 Hadoop 集群中单个计算节点，包括与 ResourceManger 保持通信，监督 Container 的生命周期管理，监控每个 Container 的资源使用（内存、 CPU 等）情况，追踪节点健康状况，管理日志和不同应用程序用到的附属服务（ auxiliary service ）。 NodeManager 负责启动和管理节点上的容器。容器执行 AppMaster 指定的任务。

• 健康检查服务

NodeManager 运行服务以确定其正在执行的节点的运行状况。服务对磁盘以及任何用户指定的测试执行检查。如果任何健康检查失败，则 NodeManager 将该节点标记为不正常，并将其传达给 ResourceManager ， ResourceManager 将停止向该节点分配容器。节点状态的通信是作为 NodeManager 和 ResourceManager 之间的心跳的一部分来完成的。磁盘检查器和运行状况监视器运行的时间间隔不影响心跳间隔。当心跳发生时，两个检查的状态用于确定节点的运行状况。

• 磁盘检查程序

磁盘检查程序检查 NodeManager 配置使用的磁盘的状态（ local-dirs 和 log-dirs ，分别使用 yarn.nodemanager.local-dirs 和 yarn.nodemanager.log-dirs 配置）。检查包括权限和可用磁盘空间。它还检查文件系统不处于只读状态。默认情况下，检查以 2 分钟间隔运行，但可以配置为按用户期望的频率运行。如果磁盘检查失败， NodeManager 停止使用该特定磁盘，但仍报告节点状态为正常。但是，如果多个磁盘无法通过检查（可以配置该数目，如下所述），则会将该节点报告为对 ResourceManager 不正常，并且不会将新容器分配给该节点。

• 外部健康脚本

用户可以指定自己的健康检查器脚本，由健康检查器服务调用。用户可以指定超时以及要传递给脚本的选项。如果脚本使用非零退出代码退出，超时或抛出异常，则会将节点标记为不正常。请注意，如果由于权限或路径不正确而无法执行脚本，则会将其视为失败，并将该节点报告为不正常。请注意，健康检查脚本不是强制性的。如果未指定脚本，则仅使用磁盘检查程序状态来确定节点的运行状况。

6. 节点标签

节点标签是一种对具有类似特征的节点进行分组的方法，应用程序可以指定运行的位置。

现在我们只支持节点分区，即：

一个节点可以只有一个节点分区，因此一个节点分区将一个集群分区为几个不相交的子集群。默认情况下，节点属于 DEFAULT 分区（ partition =“” ）。

用户需要配置每个分区可以使用不同队列的资源量。

有两种节点分区：

• Exclusive ： 容器将被分配给具有完全匹配节点分区的节点。（例如，请求分区 =“x” 将被分配给具有分区 =“x” 的节点，要求 DEFAULT 分区将被分配给 DEFAULT 分区节点）；

• Non-exclusive： 如果分区是非排他的，它将空闲资源共享给请求 DEFAULT 分区的容器。

用户可以指定每个队列可以访问的节点标签集，一个应用程序只能使用可以由包含应用程序的队列访问的节点标签的子集。

7. 扩展阅读

7.1 Web应用程序代理

Web 应用程序代理是 YARN 的一部分。同时也是资源管理器（ RM ）的一部分，它可以在独立模式下运行。用于减少 YARN 遭受 Web 攻击的可能性。 ResourceManager Web 的访问基于受信用户，当 Application Master 运行于一个非受信用户，其提供给 ResourceManager 的将是非受信连接， Web Application Proxy 可以阻止这种连接提供给 RM 。

7.2 时间轴服务器

7.2.1 介绍

以一种通用的方式向 YARN Timeline Server 上注册应用程序的当前和历史状态，便于存储和检索。它主要有两大职责：

• 持久化应用程序的具体信息

收集并检索应用程序或者框架的具体信息。例如， hadoop MR 框架里面的与分片线关系的信息，诸如 map tasks 、 reduce tasks 、 counters 等。应用程序开发者可以在 App Master 端或者应用程序需的 containers 中通过 TimelineClient 将这些信息发送给 Timeline Server 。

这些信息都可以通过 REST APIs 在具体 App 或者执行框架的 UI 界面查询到。

• 持久化已完成的应用程序的 Generic information

关于这一点，在 Application history server 中，显然只支持 MR 框架的 job 。 Generic information 包括了像 queue-name ，用户信息等用户程序级别的数据，还有设置在 ApplicationSubmissionContext 中的信息，用于运行应用程序的 application-attempts 列表，关于每个 application-attempt 的信息， container 列表以及运行在每个 application-attempt 下的每个 container 的信息。

7.2.2时间轴框架

• Timeline Domain

Timeline Domain 为 Timeline Server 提供了一个命令空间，使得用户可以搜集多个节点，将它们与其他用户和应用程序隔离开来。 Timeline server security 就定义在这一层。一个 Domain 首先是用于存储用户的信息、读写 ACL 信息、创建和修改时间戳。每个 Domain 以一个唯一的 ID 在整个 YARN 集群中标识。

• Timeline Entity

一个 Timeline Entity （即 Timeline 实体）包含一个概念实体的元信息以及它的相关的 events. 一个实体可以是一个 application ，一个 application attempt ，一个 container 卓尔其他任何的应用自定义的 object 。它还包含多个 Primary filters 用于作为 timeline store 中多个实体的索引。其他的数据可以以非索引的方式存储。每个实体都通过一个 EntityId 和 EntityType 唯一的确定。

• Timeline Events

Timeline Events 用于描述一个与某个具体 Application 的 timeline 实体相关的 event 。用户也可以随意定义一个 event 方法，比如启动一个应用程序，获取分配的 container 、操作失败或者其他的与用户和集群操作相关的失败信息等等。

7.2.3 时间轴服务v.2

YARN 时间轴服务 v.2 是时间轴服务的下一个主要迭代，遵循 v.1 和 v.1.5 。 V.2 是为了解决 v.1 的两个主要挑战而创建的。

• 可扩展性

V.1 限于写入 / 读取和存储的单个实例，并且不能超出群集扩展。 V.2 使用更可扩展的分布式写入架构和可扩展存储。

YARN 时间轴服务 v.2 将数据的收集（写入）与服务（读取）数据分离。它使用分布式收集器，每个 YARN 应用程序基本上有一个收集器。阅读器是专用于通过 REST API 提供查询的单独实例。 YARN Timeline Service v.2 选择 Apache HBase 作为主要后备存储，因为 Apache HBase 可以很好地扩展性，同时保持读取和写入的良好响应。

• 可用性改进

在许多情况下，用户对 YARN 应用程序的 “ 流 ” 或逻辑组级别的信息感兴趣。启动一组或一系列 YARN 应用程序以完成逻辑应用程序是更常见的。时间轴服务 v.2 明确支持流的概念。此外，它支持在流级别聚合。

流层次

7.3 应用程序

客户端提交应用到 Resource Manager ，首先客户端需要使用 ApplicationClientProtocol 连接 ResourceManager 获取一个 ApplicationId ，通过 ApplicationClientProtocol#getNewApplication( 类名 # 方法 ) ，然后通过 ApplicationClientProtocol#submitApplication 方法，提交应用运行。作为 ApplicationClientProtocol#submitApplication 方法的一部分，客户端需要提供足够的信息到 ResourceManager 用来 ‘ 发布 ’ 应用的第一个 Container 作为 ApplicationMaster 。你需要提供的信息包括应用运行所需要的本地文件或者 jar ，实际的执行的命令行（和必要的命令行参数），环境设置（可选）等等。你需要描述 ApplicationMaster 运行的 Unix 进程资源。

YARN 的 ResourceManager 将会发布 ApplicationMaster （按照指定的）。然后 ApplicationMaster 将会采用 ApplicationMasterProtocol 与 ResourceManager 进行通讯，首先 ApplicationMaster 会使用 ApplicationMasterProtocol#allocate 方法注册自己到 ResourceManager. 为了完成指定的任务。 ApplicationMaster 要通过 ApplicationMasterProtocol#allocate 来请求和接收 containers 。在一个 container 分配给他之后， ApplicationMaster 使用 ContainerManager#startContainer 来与 NodeManager 通讯发布任务到这个 container 。作为发布到 container 的部分， ApplicationMaster 需要指明 ContainerLaunchContext （这个类似于 ApplicationSubmissionContext ）并且发布的信息应包括指定的命令行，环境等。一旦任务完成 ApplicationMaster 会通过 ApplicationMasterProtocol#finishApplicationMaster 通知 ResourceManager 完成。

同时，客户端通过 ResourceManager 监控应用的状态或者是直接查询 ApplicationMaster （如果支持这个服务的话），如有需要客户端也可以通过 ApplicationClientProtocol#forceKillApplication 杀掉应用的进程。

7.4 应用程序安全

任何编写 YARN 应用程序的人都需要了解该过程，以便编写短期应用程序或长期服务。他们还需要在早期开发阶段开始在安全集群上测试，以便编写实际工作的代码。

• YARN 安全性如何工作

YARN 资源管理器（ RM ）和节点管理器（ NM ）协作以用该用户的身份和因此的用户的访问权限来执行用户的应用。

（活动）资源管理器：

查找群集中的空间以部署应用程序的核心，应用程序主（ AM ）。

请求该节点上的 NM 分配容器并在其中启动 AM 。

与 AM 通信，以便 AM 可以请求新的容器并操纵 / 释放当前容器，并提供关于已分配和正在运行的容器的通知。

节点管理器：

本地化资源：从 HDFS 或其他文件系统下载到本地目录。这是使用附加到容器启动上下文的委托令牌来完成的。（对于非 HDFS 资源，使用其他凭据，如群集配置文件中的对象存储库登录详细信息）

以用户身份启动应用程序。

监视应用程序并向 RM 报告故障。

要在集群中执行代码， YARN 应用程序必须：

有一个客户端应用程序，它设置了 ApplicationSubmissionContext 详细说明是什么推出。这包括：

集群文件系统中要 “ 本地化 ” 的文件列表。

要在容器中设置的环境变量。

在容器中执行以启动应用程序的命令。

YARN 启动应用程序所需的任何安全凭证。

应用程序与任何 Hadoop 集群服务和应用程序交互所需的任何安全凭证。

有一个 Application Master ，当启动时，向 YARN RM 注册并监听事件。任何 AM 它希望执行的其他容器的工作必须要求他们离开 RM ，并且在分配时，创建 ContainerLaunchContext 包含要执行的命令，环境执行命令，双星定位和所有相关的安全证书。

即使 NM 处理本地化过程， AM 也必须能够检索在启动时提供的安全证书，以便它自己可以与 HDFS 和任何其他服务一起工作，并将这些证书中的一些或全部传递到启动容器。

• 获取和添加令牌到 YARN 应用程序

YARN 应用所需的代理令牌必须从作为认证用户执行的程序中获取。对于 YARN 应用程序，这意味着用户启动应用程序。它是 YARN 应用程序的客户端部分，必须这样做：

通过 UserGroupInformation 登录。

识别必须获取的所有令牌。

从特定的 Hadoop 服务请求这些令牌。

Marshall 将所有令牌转换成字节缓冲区。

将它们添加到 ApplicationSubmissionContext 中的 ContainerLaunchContext 。

需要哪些令牌？通常，至少需要一个令牌来访问 HDFS 。

应用程序必须从与其打算交互的每个文件系统请求委派令牌 - 包括集群的主 FS 。 FileSystem.addDelegationTokens （ renewer ， credentials ）可以用来收集这些 ; 它是没有发出令牌（包括非 kerberized HDFS 集群）的那些文件系统上的无操作。

与其他服务（如 Apache HBase 和 Apache Hive ）通信的应用程序必须从这些服务请求令牌，使用这些服务的库来获取委派令牌。所有令牌可以添加到相同的凭据集，然后保存到字节缓冲区以提交。

应用程序时间表服务器还需要一个委派令牌。这是在 AM 启动时自动处理的。

7.5 CGroups

CGroups 是将任务集及其所有未来的子任务聚集 / 分组成具有专门层次。 CGroups 是一个 Linux 内核功能，并被并入内核版本 2.6.24 。从 YARN 的角度来看，这允许容器在其资源使用中受到限制。一个很好的例子是 CPU 使用率。没有 CGroups ，很难限制容器 CPU 的使用。目前， CGroups 仅用于限制 CPU 使用。

7.6 预约系统

该预约系统为用户提供了资源预留，以确保可以随时运行重要作业的能力。 ReservationSystem 执行细力度的资源控制，并提供对绝对资 源量（而不是集群大小的百分比）的保证。保留可以是可延展的或具有成组含义，并且可以具有时变资源要求。 ReservationSystem 是 YARN ResourceManager 的组件。

本期独家内容“一文读懂Hadoop”系列文章 先介绍