【作者主页】Francek Chen
【专栏介绍】$\lceil$大数据技术原理与应用$\rfloor$专栏系统介绍大数据的相关知识，分为大数据基础篇、大数据存储与管理篇、大数据处理与分析篇、大数据应用篇。内容包含大数据概述、大数据处理架构Hadoop、分布式文件系统HDFS、分布式数据库HBase、NoSQL数据库、云数据库、MapReduce、Hadoop再探讨、数据仓库Hive、Spark、流计算、Flink、图计算、数据可视化，以及大数据在互联网领域、生物医学领域的应用和大数据的其他应用。
【GitCode】专栏资源保存在我的GitCode仓库：https://gitcode.com/Morse_Chen/BigData_principle_application。

---

本文首先指出 MapReduce 1.0 的缺陷，然后介绍新一代资源调度管理框架 YARN，包括其设计思路、体系结构和工作流程，并对 YARN 框架和 MapReduce 1.0 框架进行对比分析，最后介绍 YARN 的发展目标。

一、MapReduce 1.0 的缺陷

MapReduce 1.0 采用 Master/Slave 架构设计（见图1），包括一个 JobTracker 和若干个 TaskTracker，前者负责作业的调度和资源的管理，后者负责执行 JobTracker 指派的具体任务。这种架构设计具有一些很难克服的缺陷，具体如下。

（1）存在单点故障。MapReduce 1.0 由 JobTracker 负责所有 MapReduce 作业的调度，而系统中只有一个 JobTracker，因此会存在单点故障问题，即这个唯一的 JobTracker 出现故障就会导致系统不可用。

（2）JobTracker“大包大揽”导致任务过重。JobTracker 既要负责作业的调度和失败恢复，又要负责资源管理分配。JobTracker 执行过多的任务，需要消耗大量的资源，例如当存在非常多的 MapReduce 任务时，JobTracker 需要巨大的内存开销，这也潜在地增加了 JobTracker 失败的风险。正因如此，业内普遍总结出 MapReduce 1.0 支持主机数目的上限为 4000 个。

（3）容易出现内存溢出。在 TaskTracker 端，资源的分配并不考虑 CPU、内存的实际使用情况，而只是根据 MapReduce 任务的个数来分配资源。当两个具有较大内存消耗的任务被分配到同一个 TaskTracker 上时，很容易发生内存溢出的情况。

（4）资源划分不合理。资源（CPU、内存）被强制等量划分成多个“槽”（Slot），槽又被进一步划分为 Map 槽和 Reduce 槽两种，分别供 Map 任务和 Reduce 任务使用，彼此之间不能使用分配给对方的槽。也就是说，当 Map 任务已经用完 Map 槽时，即使系统中还有大量剩余的 Reduce 槽，也不能拿来运行 Map 任务，反之亦然。这就意味着，当系统中只存在单一 Map 任务或 Reduce 任务时，会造成资源的浪费。

图1 MapReduce1.0体系结构

二、YARN 设计思路

为了克服 MapReduce 1.0 版本的缺陷，在 Hadoop 2.0 以后的版本中对其核心子项MapReduce 1.0 的体系结构进行了重新设计，生成了 MapReduce 2.0 和 YARN。YARN 架构设计思路如图2所示，其基本思路就是“放权”，即不让 JobTracker 这一个组件承担过多的功能，对原 JobTracker 三大功能（资源管理、任务调度和任务监控）进行拆分，分别交给不同的新组件去处理。重新设计后得到的 YARN 包括 ResourceManager、ApplicationMaster 和 NodeManager，其中，由 ResourceManager 负责资源管理，由 ApplicationMaster 负责任务调度和监控，由 NodeManager 负责执行原 TaskTracker 的任务。这种“放权”的设计，大大降低了 JobTracker 的负担，提升了系统运行的效率和稳定性。

图2 YARN架构设计思路

在 Hadoop 1.0 中，其核心子项目 MapReduce 1.0 既是一个计算框架，也是一个资源管理调度框架。到了 Hadoop 2.0 以后，MapReduce 1.0 中的资源管理调度功能被单独分离出来形成了 YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架；而被剥离了资源管理调度功能的 MapReduce 框架就变成了 MapReduce 2.0，它是运行在 YARN 之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由 YARN 为其提供资源管理调度服务。

三、YARN 体系结构

如图3所示，YARN 体系结构中包含了 3 个组件：ResourceManager、ApplicationMaster 和 NodeManager。YARN 各个组件的功能见表1。

图3 YARN体系结构

表1 YARN各个组件的功能

组件	功能
ResourceManager	- 处理客户端请求 - 启动/监控 ApplicationMaster - 监控 NodeManager - 资源分配与调度
ApplicationMaster	- 为应用程序申请资源，并分配给内部任务 - 任务调度、监控与容错
NodeManager	- 单个节点上的资源管理 - 处理来自 ResourceManager 的命令 - 处理来自 ApplicationMaster 的命令

资源管理器（ResourceManager，RM）负责整个系统的资源管理和分配，主要包括两个组件，即资源调度器（Resource Scheduler）和应用程序管理器（Applications Manager）。资源调度器主要负责资源管理和分配，不再负责跟踪和监控应用程序的执行状态，也不负责执行失败恢复，因为这些任务都已经交给 ApplicationMaster 组件来负责。调度器接收来自 ApplicationMaster 的应用程序资源请求，并根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），把集群中的资源以“容器”（Container）的形式分配给提出申请的应用程序。容器的选择通常会考虑应用程序所要处理的数据的位置，就近进行选择，从而实现“计算向数据靠拢”。在 MapReduce 1.0 中，资源分配的单位是“槽”，而在 YARN 中是以容器作为动态资源分配单位，每个容器中都封装了一定数量的 CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量。同时，在 YARN 中调度器被设计成是一个可插拔的组件，YARN 不仅自身提供了许多种直接可用的调度器，也允许用户根据自己的需求重新设计调度器。应用程序管理器负责系统中所有应用程序的管理工作，主要包括应用程序提交、与资源调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动等。

在 Hadoop 平台上，用户的应用程序是以作业的形式提交的，然后一个作业会被分解成多个任务（包括 Map 任务和 Reduce 任务）进行分布式执行。ResourceManager 接收用户提交的作业，按照作业的上下文信息以及从 NodeManager 收集来的容器状态信息，启动调度过程，为用户作业启动一个 ApplicationMaster 。 ApplicationMaster 的主要功能是：当用户作业提交时，ApplicationMaster 与 ResourceManager 协商获取资源，ResourceManager 会以容器的形式为 ApplicationMaster 分配资源；把获得的资源进一步分配给内部的各个任务（Map 任务或 Reduce 任务），实现资源的“二次分配”；与 NodeManager 保持交互通信，进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，监控所有任务的执行进度和状态，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）；定时向 ResourceManager 发送“心跳”消息，报告资源的使用情况和应用的进度信息；当作业完成时，ApplicationMaster 向 ResourceManager 注销容器，执行周期完成。

NodeManager 是驻留在一个 YARN 集群中的每个节点上的代理，主要负责容器生命周期管理，监控每个容器的资源（CPU、内存等）使用情况，跟踪节点健康状况，并以“心跳”的方式与 ResourceManager保持通信，向ResourceManager汇报作业的资源使用情况和每个容器的运行状态，同时，它还要接收来自 ApplicationMaster 的启动/停止容器的各种请求。需要说明的是，NodeManager 主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务（Map 任务或 Reduce 任务）自身状态的管理，因为这些管理工作是由 ApplicationMaster 完成的，ApplicationMaster 会通过不断与 NodeManager 通信来掌握各个任务的执行状态。

在集群部署方面，YARN 的各个组件是和 Hadoop 集群中的其他组件统一部署的。如图4所示，YARN 的 ResourceManager 组件和 HDFS 的名称节点（NameNode）部署在一个节点上，YARN 的 ApplicationMaster、NodeManager 和 HDFS 的数据节点（DataNode）部署在一起。YARN 中的容器代表了 CPU、内存、网络等计算资源，它也和 HDFS 的数据节点部署在一起。

图4 YARN和Hadoop平台其他组件的统一部署

四、YARN 工作流程

YARN 的工作流程如图5所示，在 YARN 框架中执行一个 MapReduce 程序时，从提交到完成需要经历如下 8 个步骤。

（1）用户编写客户端应用程序，向 YARN 提交应用程序，提交的内容包括 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。

（2）YARN 中的 ResourceManager 负责接收和处理来自客户端的请求。接到客户端应用程序请求后，ResourceManager 里面的调度器会为应用程序分配一个容器。同时，ResourceManager 的应用程序管理器会与该容器所在的 NodeManager 通信，为该应用程序在该容器中启动一个 ApplicationMaster（即图5中的“MR App Mstr”）。

（3）ApplicationMaster 被创建后会首先向 ResourceManager 注册，从而使得用户可以通过 ResourceManager 来直接查看应用程序的运行状态。接下来的步骤（4）～（7）是具体的应用程序执行步骤。

（4）ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请资源。

（5）ResourceManager 以“容器”的形式向提出申请的 ApplicationMaster 分配资源，一旦 ApplicationMaster 申请到资源，就会与该容器所在的 NodeManager 进行通信，要求它启动任务。

（6）当 ApplicationMaster 要求容器启动任务时，它会为任务设置好运行环境（包括环境变量、JAR 包、二进制程序等），然后将任务启动命令写到一个脚本中，最后通过在容器中运行该脚本来启动任务。

（7）各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，让 ApplicationMaster 可以随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。

（8）应用程序运行完成后，ApplicationMaster 向 ResourceManager 的应用程序管理器注销并关闭自己。若 ApplicationMaster 因故失败，ResourceManager 中的应用程序管理器会监测到失败的情形，然后将其重新启动，直到所有的任务执行完毕。

图5 YARN的工作流程

五、YARN 框架与 MapReduce 1.0 框架的对比分析

从 MapReduce 1.0 框架发展到 YARN 框架，客户端并没有发生变化，其大部分调用 API 及接口都保持兼容。因此，原来针对 Hadoop 1.0 开发的代码不用做大的改动，就可以直接在 Hadoop 2.0 平台上运行。

在 MapReduce 1.0 框架中的 JobTracker 和 TaskTracker，在 YARN 框架中变成了 3 个组件，即ResourceManager、ApplicationMaster 和 NodeManager。ResourceManager 要负责调度、启动每一个作业所属的 ApplicationMaster，监控 ApplicationMaster 运行状态并在失败时重新启动，而作业里面的不同任务的调度、监控、重启等，不再由 ResourceManager 负责，而是交给与该作业相关联的 ApplicationMaster 来负责。ApplicationMaster 要负责一个作业生命周期内的所有工作。也就是说，它承担了 MapReduce 1.0 中 JobTracker 的“作业监控”功能。

总体而言，YARN 相对 MapReduce 1.0 具有以下优势。

（1）大大减少了承担中心服务功能的 ResourceManager 的资源消耗。MapReduce 1.0 中的 JobTracker 需要同时承担资源管理、任务调度和任务监控等三大功能，而 YARN 中的 ResourceManager 只需要负责资源管理，需要消耗大量资源的任务调度和监控重启工作则交由 ApplicationMaster 来完成。由于每个作业都有与之关联的独立的 ApplicationMaster，因此，系统中存在多个作业时，就会同时存在多个 ApplicationMaster，这就实现了监控任务的分布化，不再像 MapReduce 1.0 那样监控任务只集中在一个 JobTracker 上。

（2）MapReduce 1.0 既是一个计算框架，又是一个资源管理调度框架，但是它只能支持 MapReduce 编程模型。而 YARN 是一个纯粹的资源调度管理框架，在它上面可以运行包括 MapReduce 在内的不同类型的计算框架，默认类型是 MapReduce 。因为 YARN 中的 ApplicationMaster 是可变更的，针对不同的计算框架，用户可以采用任何编程语言自己编写服务于该计算框架的 ApplicationMaster。比如用户可以编写一个面向 MapReduce 计算框架的 ApplicationMaster，从而使得 MapReduce 计算框架可以运行在 YARN 框架之上。同理，用户还可以编写面向 Spark、Storm 等计算框架的 ApplicationMaster，从而使得 Spark、Storm 等计算框架也可以运行在 YARN 框架之上。

（3）YARN 中的资源管理比 MapReduce 1.0 更加高效。YARN 以容器为单位进行资源管理和分配，而不是以槽为单位，避免了 MapReduce 1.0 中槽的闲置浪费情况，大大提高了资源的利用率。

六、YARN 的发展目标

YARN 的提出，并非仅为了解决 MapReduce 1.0 框架中存在的缺陷，实际上，YARN 有着更加“宏伟”的发展构想，即发展成为集群中统一的资源管理调度框架，在一个集群中为上层的各种计算框架提供统一的资源管理调度服务。

在一个企业当中，会同时存在各种不同的业务应用场景，各自的数据处理需求截然不同。为了满足各种应用场景的不同数据处理需求，就需要采用不同的计算框架，比如使用 MapReduce 实现离线批处理，使用 Impala 实现实时交互式查询分析，使用 Storm 实现流式数据实时分析，使用 Spark 实现迭代计算等。但这些产品通常来自不同的开发团队，具有各自的资源调度管理机制。于是，为了避免不同类型应用之间互相干扰，企业需要把内部的服务器拆分成多个集群，分别安装运行不同的计算框架，即“一个框架一个集群”，一个集群运行 MapReduce，一个集群运行 Spark，还有一个集群运行 Storm 或者其他计算框架。企业内部服务器集群被拆分成不同的独立小集群运行，带来的一个显而易见的问题就是，集群资源利用率低。因为在某个时刻，不同集群的负载水平分布很不均匀，有些小集群可能处于极度繁忙状态，而另外一些小集群可能处于闲置浪费状态，由于各个小集群之间彼此隔离，因此繁忙小集群的负载无法分发到空闲小集群上执行，这就导致了服务器资源的浪费。另外，不同集群之间无法直接共享数据，造成集群间大量的数据传输开销，同时需要多个管理员维护不同的集群，这大大增加了运维成本。

因此，YARN 的目标就是实现“一个集群多个框架”，即在一个集群上部署一个统一的资源调度管理框架 YARN，在 YARN 之上可以部署各种计算框架（见图6），比如 MapReduce、Tez、HBase、Storm、Giraph、Spark、OpenMPI 等，由 YARN 为这些计算框架提供统一的资源调度管理服务，并且能够根据各种计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩。通过这种方式，可以实现一个集群上的不同应用负载混搭，有效提高集群的利用率。同时，不同计算框架可以共享底层存储，在一个集群上集成多个数据集，使用多个计算框架来访问这些数据集，从而避免了数据集跨集群移动。最后，这种部署方式大大降低了企业运维成本。

目前，可以运行在 YARN 之上的计算框架包括离线批处理框架 MapReduce、内存计算框架 Spark、流计算框架 Storm 和 DAG 计算框架 Tez 等。和 YARN 一样提供类似功能的其他资源管理调度框架还包括 Mesos、Torca、Corona、Borg 等。

图6 在YARN上部署各种计算框架

小结

本文从 MapReduce 1.0 的架构缺陷出发，系统介绍了 YARN 的设计与实现。MapReduce 1.0 中 JobTracker 承担资源管理、任务调度和监控等过多职能，导致单点故障、资源消耗大、内存溢出及槽位划分不合理等问题。YARN 通过“放权”思路，将原 JobTracker 功能拆分为 ResourceManager、ApplicationMaster 和 NodeManager 三个组件，分别负责资源全局管理、作业内部调度监控和单节点容器管理，并以容器代替槽位作为动态资源分配单位，显著提升了资源利用率和系统扩展性。YARN 工作流程涵盖客户端提交、RM 启动 AM、AM 申请资源并启动任务、任务汇报进度及最终注销等 8 个步骤。相比 MapReduce 1.0，YARN 不仅减轻了中心节点负担，还支持多种计算框架（如 Spark、Storm）共存于同一集群，实现了“一个集群多个框架”的目标，提高了集群资源利用率并降低了运维成本。

欢迎 点赞👍 | 收藏⭐ | 评论✍ | 关注🤗