前言

部分内容摘自尚硅谷、黑马等等培训资料

1. YARN框架概述

1.1 YARN产生和发展简史

1.1.1 Hadoop演进阶段

数据、程序、运算资源（内存、cpu）三者组在一起，完成了数据的计算处理过程。在单机环境下，这些都不是太大问题。为了应对海量数据的场景，Hadoop 出现并提供了分而治之的分布式处理思想。通过对 Hadoop 版本演进的简单回顾，可以让我们知道 YARN 的产生和发展简史，洞悉 YARN 发展进程。
很多 Hadoop 的早期用户使用 Hadoop 的方式与在众多主机上运行桌面应用程序类似。

在少量几个节点上手工建立一个集群；
将数据载入 Hadoop 分布式文件系统（HDFS）；
通过运行 MapReduce 任务来运算并获得结果；
然后拆掉集群。

这种方式的一部分原因是没有在 Hadoop HDFS 上持久存储数据的迫切需求，另一部分原因是没有共享数据和计算结果的动机。

1.1.1.1 阶段0：Ad Hoc集群

Ad Hoc应当理解为专用、特定的意思（数仓领域中常理解为即席查询）。Ad Hoc 集群时代标志着 Hadoop 集群的起源，集群以Ad Hoc、单用户方式建立。
后来，随着私人集群的使用和 Hadoop 容错性的提高，持久的 HDFS 集群出现，并且实现了 HDFS 集群的共享，把常用和感兴趣的数据集载入 HDFS 共享集群中。当共享 HDFS 成为现实，还没实现共享的计算平台就成为关切对象。
不同于 HDFS，为多个组织的多个用户简单设置一个共享 MapReduce 集群并非易事。尤其是集群下的物理资源的共享很不理想。

1.1.1.2 阶段1：HOD集群

为了解决集群条件下的多租户问题， Yahoo 发展并且部署了称为 “Hadoop on Demand” 的平台。Hadoop On Demand（HOD）是一个能在大规模物理集群上供应虚拟 Hadoop 集群的系统。在已经分配的节点上， HOD 会启动 MapReduce 和 HDFS 守护进程来响应用户数据和应用的请求。

HOD 的主要特点是用户可以使用 HOD 来同时分配多个 MapReduce 集群。
HOD 的缺点包括：无法支持数据本地化、资源回收效率低、无动态扩容缩容能力，多租户共享延迟高等。

1.1.1.3 阶段2：共享计算集群

共享 MapReduce 计算集群和与之协同工作的共享 HDFS 是 Hadoop 1.x 版本里的主要架构。

这种共享计算架构的主要组件如下所示：
JobTracker：一个中央守护进程，负责运行集群上的所有作业。
TaskTracker：系统里的从进程，根据 JobTracker 的指令来执行任务。
共享计算集群的主要弊端有 JobTracker 可扩展性瓶颈（JobTracker 在内存中保存用户作业的数据）、JobTracker 身兼多职（作业数据管理、作业状态记录、作业调度、）、可靠性和可用性欠缺（JobTracker 单点故障）、计算模型的单一（不是所有问题都能 MapReduce）。
并且 MapReduce 框架本身也经历了很多变化。但是 MapReduce 被绑定到了集群的管理层，证明 MapReduce 的变化演变是比较困难的。

1.1.1.4 阶段4：Yarn集群

针对共享计算集群，JobTracker 需要彻底地重写，才能解决扩展性的主要问题。但是，这种重写即使成功了，也不一定能解决平台和用户代码的耦合问题，也不能解决用户对非 MapReduce 编程模型的需求。如果不做重大的重新设计，集群可用性会继续被捆绑到整个系统的稳定性上。
YARN 闪亮登场了，一款被设计用以解决以往架构的需求和缺陷的资源管理和调度软件。经过之前的发展，Hadoop 走下了不少的弯路，甚至跳进了一些深坑。因此对于 YARN 的每个重大决策背后都有完整的惨痛的历史。

1.1.2 对YARN的需求

可扩展性： 可以平滑的扩展至数万节点和并发的应用。
可维护性： 保证集群软件的升级与用户应用程序完全解耦。
多租户： 需要支持在同一集群中多个租户并存，同时支持多个租户间细颗粒度地共享单个节点。
位置感知： 将计算移至数据所在位置。
高集群使用率： 实现底层物理资源的高使用率。
安全和可审计的操作： 继续以安全的、可审计的方式使用集群资源。
可靠性和可用性： 具有高度可靠的用户交互、并支持高可用性
对编程模型多样化的支持： 支持多样化的编程模型，需要演进为不仅仅以MapReduce为中心。
灵活的资源模型： 支持各个节点的动态资源配置以及灵活的资源模型。
向后兼容： 保持现有的MapReduce应用程序的向后兼容性。

1.2 YARN简介

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
可以把 Hadoop YARN 理解为相当于一个分布式的操作系统平台，而 MapReduce 等计算程序则相当于运行于操作系统之上的应用程序，YARN 为这些程序提供运算所需的资源（内存、cpu 等）。
YARN 是一个分布式的资源管理系统，用以提高分布式的集群环境下的资源利用率，这些资源包括内存、IO、网络、磁盘等。其产生的原因是为了解决原 MapReduce 框架的不足。最初 MapReduce 的 committer 们还可以周期性的在已有的代码上进行修改，可是随着代码的增加以及原 MapReduce 框架设计的不足，在原 MapReduce 框架上进行修改变得越来越困难，所以 MapReduce 的 committer 们决定从架构上重新设计 MapReduce，使下一代的 MapReduce （MRv2/Yarn）框架具有更好的扩展性、可用性、可靠性、向后兼容性和更高的资源利用率以及能支持除了 MapReduce 计算框架外的更多的计算框架。

1.3 YARN与MRv1区别

由于 MRv1（第一代MapReduce）在扩展性、可靠性、资源利用率和多框架等方面存在明显不足， Apache 开始尝试对 MapReduce 进行升级改造，于是诞生了更加先进的下一代 MapReduce 计算框架 MRv2。
并且在 MRv2 中，将资源管理任务调度模块单独抽离出来，构建成了一个独立的通用资源管理系统 YARN，而 MRv2 则专注于数据的计算处理了。

1.3.1 MRv1架构

在 Hadoop 1.0 中 MapReduce 框架（MRv1，第一代 MapReduce 框架），和 HDFS 一样，MapReduce 也是采用 Master/Slave 的架构，其架构如下图所示：

MapReduce 包含四个组成部分，分别为 Client，JobTracker，TaskTracker，Task。

Client： 客户端，每一个 Job 都会在用户端通过 Client 类，将应用程序以及参数配置 Configuration 打包成 Jar 文件存储在 HDFS，并把路径提交到 JobTracker 的 master 服务，然后由 master 创建每一个 Task（即 MapTask 和 ReduceTask），将它们分发到各个 TaskTracker 服务中去执行。
JobTracker： 管理主节点，JobTracker 负责资源监控和作业调度。JobTracker 监控所有的 TaskTracker 与 job 的健康状况，一旦发现失败，就将相应的任务转移到其它节点；同时 JobTracker 会跟踪任务的执行进度，资源使用量等信息，并将这些信息告诉任务调度器，而调度器会在资源出现空闲时，选择合适的任务使用这些资源。在 Hadoop 中，任务调度器是一个可插拔的模块，用于可以根据自己的需要设计相应的调度器。
TaskTracker： 执行从节点，TaskTracker 会周期性地通过 HeartBeat 将本节点上资源的使用情况和任务的运行进度汇报给 JobTracker，同时执行 JobTracker 发送过来的命令并执行相应的操作（如启动新任务，杀死任务等）。TaskTracker 使用 “slot” 等量划分本节点上的资源量。“slot” 代表计算资源（cpu，内存等）。一个 Task 获取到一个 slot 之后才有机会运行，而 Hadoop 调度器的作用就是将各个 TaskTracker 上的空闲 slot 分配给 Task 使用。slot 分为 MapSlot 和 ReduceSlot 两种，分别提供 MapTask 和 ReduceTask 使用。TaskTracker 通过 slot 数目（可配置参数）限定 Task 的并发度。
Task： 计算任务，Task 分为 MapTask 和 ReduceTask 两种，均由 TaskTracker 启动。HDFS 以固定大小的 block 为基本单位存储数据，而对于 MapReduce 而言，其处理单位是 split。split 是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。但需要注意的是，split 的多少决定了 MapTask 的数目，因为每一个 split 只会交给一个 MapTask 处理。

1.3.2 MRv1缺陷

在 Hadoop 1.0 中， JobTracker 由资源管理（由 TaskScheduler 模块实现）和作业控制（由 JobTracker 中多个模块共同实现）两部分组成，Hadoop 对 JobTracker 赋予的功能过多而造成负载过重。

Hadoop YARN 是在 MRv1 基础上演化而来的，它克服了 MRv1 中的各种局限性，概括为以下几个方面：

扩展性差： 在 MRv1 中， JobTracker 同时兼备了资源管理和作业控制两个功能，这成为系统的一个最大瓶颈，严重制约了 Hadoop 集群扩展性。
可靠性差： MRv1 采用了 master/slave 结构，其中， master 存在单点故障问题，一旦它出现故障将导致整个集群不可用。
资源利用率低： MRv1 采用了基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完槽位对应的资源，且其他任务也无法使用这些空闲资源。此外， Hadoop 将槽位分为 Map Slot 和 Reduce Slot 两种，且不允许它们之间共享，常常会导致一种槽位资源紧张而另外一种闲置（比如一个作业刚刚提交时，只会运行 Map Task，此时 Reduce Slot 闲置）。
无法支持多种计算框架： 随着互联网高速发展， MapReduce 这种基于磁盘的离线计算框架已经不能满足应用要求，从而出现了一些新的计算框架，包括内存计算框架、流式计算框架和迭代式计算框架等，而 MRv1 不能支持多种计算框架并存。

1.3.3 YARN架构

为了克服以上几个缺点， Apache 开始尝试对 Hadoop 进行升级改造，进而诞生了更加先进的下一代 MapReduce 计算框架 MRv2。正是由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN，直接导致下一代MapReduce的核心从单一的计算框架MapReduce转移为通用的资源管理系统YARN。

YARN 实际上是一个弹性计算平台，它的目标已经不再局限于支持 MapReduce 一种计算框架，而是朝着对多种框架进行统一管理的方向发展。

1.3.4 YARN与MRv1区别

Hadoop2.0 即第二代 Hadoop，由分布式存储系统HDFS、并行计算框架MapReduce和分布式资源管理系统YARN三个系统组成，其中 YARN 是一个资源管理系统，负责集群资源管理和调度，MapReduce 则是运行在 YARN 上的离线处理框架，称为 MRv2（MapReduce 的第二版）。

MRv1 主要由编程模型（由新旧 API 组成）、数据处理引擎（由 MapTask 和 ReduceTask 组成）和运行时环境（由一个 JobTracker 和若干个 TaskTracker 组成）三部分组成，为了保证编程模型的向后兼容性， MRv2 重用了 MRv1 中的编程模型和数据处理引擎，但运行时环境被完全重写，具体如下：

编程模型与数据处理引擎： MRv2 重用了 MRv1 中的编程模型和数据处理引擎。
- 为了能够让用户应用程序平滑迁移到 Hadoop 2.0 中， MRv2 应尽可能保证编程接口的向后兼容性，但由于 MRv2 本身进行了改进和优化，它在向后兼容性方面存在少量问题。
- MapReduce 应用程序编程接口有两套，分别是新 API（mapredue）和旧 API（mapred）， MRv2 可做到以下兼容性：采用 MRv1 旧 API 编写的应用程序，可直接使用之前的 JAR 包将程序运行在 MRv2 上；但采用 MRv1 新 API 编写的应用程序则不可以，需要使用 MRv2 编程库重新编译并修改不兼容的参数和返回值。
运行时环境： MRv1 的运行时环境主要由两类服务组成，分别是 JobTracker 和 TaskTracker。
- JobTracker 负责资源和任务的管理与调度， TaskTracker 负责单个节点的资源管理和任务执行。 MRv1 将资源管理和应用程序管理两部分混杂在一起，使得它在扩展性、容错性和多框架支持等方面存在明显缺陷。
- MRv2 则通过将资源管理和应用程序管理两部分剥离开，分别由 YARN 和 ApplicationMaster 负责，其中， YARN 专管资源管理和调度，而 ApplicationMaster 则负责与具体应用程序相关的任务切分、任务调度和容错等。

2. YARN架构组件及原理

YARN（Yet Another Resource Negotiator，另一种资源协调者）是 Hadoop 2.0 中的资源管理系统，它的基本设计思想是将 MRv1 中的 JobTracker拆分成了两个独立的服务：一个全局的资源管理器 ResourceManager 和每个应用程序特有的ApplicationMaster。其中 ResourceManager 负责整个系统的资源管理和分配，而 ApplicationMaster 负责单个应用程序的管理。

2.1 YARN体系架构

官方架构图：

2.2 YARN组件及功能

YARN 总体上仍然是 Master/Slave 结构（主从结构），在整个资源管理框架中，ResourceManager 为 Master， NodeManager 为 Slave，ResourceManager 负责对各个 NodeManager 上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向 ResourceManager 申请资源，并要求 NodeManger 启动可以占用一定资源的任务。由于不同的 ApplicationMaster 被分布到不同的节点上，因此它们之间不会相互影响。

上图描述了 YARN 的基本组成结构， YARN 主要由 ResourceManager、 NodeManager、ApplicationMaster（图中给出了 MapReduce 和 MPI 两种计算框架的 ApplicationMaster，分别为 MR AppMstr 和 MPI AppMstr）和 Container 等几个组件构成。

进程	描述	级别
ResourceManager	使用Scheduler（ResourceScheduler类）和ApplicationManager（RMAppManager类）分配群集资源	守护进程
ApplicationMaster	通过指示NodeManager创建或销毁Application的Container来管理Application的生命周期。一个Application只有一个ApplicationMaster进程	用户进程
NodeManager	通过在群集节点中创建和销毁容器来管理特定节点中的作业或工作流	守护进程
Container	Container是Yarn对计算资源的抽象，它其实是一组CPU和内存资源，所有的应用都会运行在Container中	用户进程

2.2.1 ResourceManager

RM（ResourceManager）是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager， ASM）。

调度器（Scheduler）： 根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
- 需要注意的是，该调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的 ApplicationMaster 完成。
- 调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称 Container）表示， Container 是一个动态资源分配单位，它将内存、 CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
- 此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器， YARN 提供了多种直接可用的调度器，比如 FairScheduler 和 Capacity Scheduler 等。
应用程序管理器（Applications Manager）： 负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等。

2.2.2 ApplicationMaster

用户提交的每个应用程序均包含一个 AM，主要功能包括：

与 RM 调度器协商以获取资源（用 Container 表示）；
将得到的任务进一步分配给内部的任务；
与 NM 通信以启动 / 停止任务；
监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。

当前 YARN 自带了两个 AM 实现，一个是用于演示 AM 编写方法的例程序 distributedshell，它可以申请一定数目的 Container 以并行运行一个 Shell 命令或者 Shell 脚本；另一个是运行 MapReduce 应用程序的 AM—MRAppMaster，此外，一些其他的计算框架对应的 AM 正在开发中，比如 Spark、Flink 等。

2.2.3 NodeManager

NM（NodeManager）是每个节点上的资源和任务管理器，一方面，它会定时地向 RM 汇报本节点上的资源使用情况和各个 Container 的运行状态；另一方面，它接收并处理来自 AM 的 Container 启动/停止等各种请求。

2.2.4 Container

Container 是 YARN 中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当 AM 向 RM 申请资源时， RM 为 AM 返回的资源便是用 Container表示的。 YARN 会为每个任务分配一个 Container，且该任务只能使用该 Container 中描述的资源。需要注意的是， Container 不同于 MRv1 中的 slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。当下， YARN 仅支持 CPU 和内存两种资源，且使用了轻量级资源隔离机制 Cgroups 进行资源隔离。

YARN 支持各种数据处理引擎对 HDFS 中的数据进行批处理、交互式和流处理。在不同的场景中使用不同的框架，常见的包括 MapReduce、Spark、Storm 和 Flink 等 Application。这种架构可以更好、更优雅地进行扩展。因此从一开始就内置了高可用性、安全性和多租户支持更多用户在大型集群上使用，新架构还将提高创新性，敏捷性和硬件利用率。

此外，YARN 提供以下功能：

多租户： 可以使用多个开放源代码和专有数据访问引擎来批量、交互式和实时访问同一数据集。多租户数据处理可提高企业在 Hadoop 投资上的回报。
Docker容器化： 可以使用 Docker 容器化来并行运行同一应用程序的多个版本。
集群利用率： 可以动态分配群集资源以提高资源利用率。
多种资源类型： 可以使用多种资源类型，例如 CPU 和内存。
可扩展性： 提高了数据中心的处理能力。YARN 的 ResourceManager 仅专注于调度，并在集群扩展到管理数 PB 数据的数千个节点时保持同步。
兼容性： Hadoop1.x 的 MapReduce 应用程序可在 YARN 上运行，而不会破坏现有流程。YARN 与 Hadoop 的先前稳定版本保持 API 兼容性。

2.3 YARN通信协议

RPC 协议是连接各个组件的“大动脉”，了解不同组件之间的 RPC 协议有助于更深入地理解学习 YARN 框架。在 YARN 中，任何两个需相互通信的组件之间仅有一个 RPC 协议，而对于任何一个 RPC 协议，通信双方有一端是 Client，另一端为 Server，且 Client 总是主动连接 Server 的，因此， YARN 实际上采用的是拉式（pull-based）通信模型。

如上图所示，箭头指向的组件是 RPC Server，而箭头尾部的组件是 RPC Client， YARN 主要由以下几个 RPC 协议组成：

JobClient（作业提交客户端）与 RM 之间的协议——ApplicationClientProtocol：JobClient 通过该 RPC 协议提交应用程序、查询应用程序状态等。
Admin（管理员）与 RM 之间的通信协议——ResourceManagerAdministrationProtocol：Admin 通过该 RPC 协议更新系统配置文件，比如节点黑白名单、用户队列权限等。
AM 与 RM 之间的协议——ApplicationMasterProtocol： AM 通过该 RPC 协议向 RM 注册和撤销自己，并为各个任务申请资源。
AM 与 NM 之间的协议——ContainerManagementProtocol： AM 通过该 RPC 要求 NM 启动或者停止 Container，获取各个 Container 的使用状态等信息。
NM 与 RM 之间的协议——ResourceTracker： NM 通过该 RPC 协议向 RM 注册，并定时发送心跳信息汇报当前节点的资源使用情况和 Container 运行情况。

2.4 YARN工作流程

运行在 Hadoop YARN 上的应用程序主要分为两类：短应用程序和长应用程序。

短应用程序： 指一定时间内（可能是秒级、分钟级或小时级，尽管天级别或者更长时间的也存在，但非常少）可运行完成并正常退出的应用程序，比如 MapReduce 作业、 Spark 作业等；
长应用程序： 指不出意外，永不终止运行的应用程序，通常是一些服务，比如 Storm Service（主要包括 Nimbus 和 Supervisor 两类服务）， Flink（包括 JobManager 和 TaskManager 两类服务）等，而它们本身作为一个框架提供了编程接口供用户使用。

尽管这两类应用程序作用不同，一类直接运行数据处理程序，一类用于部署服务（服务之上再运行数据处理程序），但运行在 YARN 上的流程是相同的。
当用户向 YARN 中提交一个应用程序后， YARN 将分两个阶段运行该应用程序：第一个阶段是启动 ApplicationMaster ；第二个阶段是由 ApplicationMaster 创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完成。

如上图所示， YARN 的工作流程分为以下几个步骤：

第 1 步： 用户向 YARN 中提交应用程序，其中包括 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。
第 2 步： ResourceManager 为该应用程序分配第一个 Container，并与对应的 NodeManager 通信，要求它在这个 Container 中启动应用程序的 ApplicationMaster。
第 3 步： ApplicationMaster 首先向 ResourceManager 注册，这样用户可以直接通过 ResourceManage 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤 4~7。
第 4 步： ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和领取资源。
第 5 步： 一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求它启动任务。
第 6 步： NodeManager 为任务设置好运行环境（包括环境变量、 JAR 包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
第 7 步： 各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当前运行状态。
第 8 步： 应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己。

YARN 正是一个资源管理系统，它的出现弱化了计算框架之争，引入 YARN 这一层后，各种计算框架可各自发挥自己的优势，并由 YARN 进行统一管理，进而运行在一个大集群上。

3. HDFS、YARN、MapReduce三者关系

3.1 Hadoop Job提交全过程

Job提交过程之YARN：

Job提交过程之HDFS & MapReduce：

作业提交全过程详解：

作业提交
第 1 步： Client 调用job.waitForCompletion方法，向整个集群提交 MapReduce 作业。
第 2 步： Client 向 RM 申请一个作业 ID。
第 3 步： RM 给 Client 返回该 job 资源的提交路径和作业 ID。
第 4 步： Client 提交 jar 包、切片信息和配置文件到指定的资源提交路径。
第 5 步： Client 提交完资源后，向 RM 申请运行 MrAppMaster。
作业初始化
第 6 步： 当 RM 收到 Client 的请求后，将该 job 添加到容量调度器中。
第 7 步： 某一个空闲的 NM 领取到该 Job。
第 8 步： 该 NM 创建 Container，并产生 MRAppmaster。
第 9 步： 下载 Client 提交的资源到本地。
任务分配
第 10 步： MrAppMaster 向 RM 申请运行多个 MapTask 任务资源。
第 11 步： RM 将运行 MapTask 任务分配给另外两个 NodeManager，另两个 NodeManager 分别领取任务并创建容器。
任务运行
第 12 步： MR 向两个接收到任务的 NodeManager 发送程序启动脚本，这两个 NodeManager 分别启动 MapTask，MapTask 对数据分区排序。
第 13 步： MrAppMaster 等待所有 MapTask 运行完毕后，向 RM 申请容器，运行 ReduceTask。
第 14 步： ReduceTask 向 MapTask 获取相应分区的数据。
第 15 步： 程序运行完毕后，MR 会向 RM 申请注销自己。
进度和状态更新
YARN 中的任务将其进度和状态（包括 counter）返回给应用管理器，客户端每秒（通过mapreduce.client.progressmonitor.pollinterval设置）向应用管理器请求进度更新，展示给用户。
作业完成

除了向应用管理器请求作业进度外，客户端每 5 秒都会通过调用waitForCompletion()来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval来设置。作业完成之后，应用管理器和 Container 会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。