YARN - 核心原理、特点、以及架构详解

作者：hangge | 2024-08-27 08:38

1，分布式资源管理系统

（1）在传统的 IT 领域中，企业的服务器资源（内存、CPU 等）是有限的，也是固定的。但是，服务器的应用场景却是灵活多变的。例如，今天临时上线了一个系统，需要占用几台服务器；过了几天，需要把这个系统下线，把这几台服务器清理出来。

（2）在大数据时代到来之前，服务器资源的变更对应的是系统的上线和下线，这些变动是有限的。随着大数据时代的到来，临时任务的需求量大增，这些任务往往需要大量的服务器资源。如果此时还依赖运维人员人工对接服务器资源的变更，显然是不现实的。因此，分布式资源管理系统应运而生，常见的包括 YARN、Kubernetes 和 Mesos，它们的典型应用领域如下：

YARN：主要应用于大数据领域
Kubernetes：主要应用于云计算领域
Mesos：主要应用于云计算领域

2，什么是 YARN？

YARN 是一个通用的分布式资源管理系统，可为上层应用提供统一的资源管理和调度，它为集群利用率和资源统一管理带来了巨大好处。

3，YARN 产生的背景

（1）YARN 是 Hadoop 2.x 版本中引入的分布式资源管理系统，主要用于解决 Hadoop 1.x 架构中集群资源管理和数据计算耦合在一起导致的修复维护成本越来越高的问题。

在 Hadoop 1.x 架构中只有 HDFS 和 MapReduce（MR1）组件，此时 MR1 负责集群资源管理和数据计算。
在 Hadoop2.x 架构中，除 HDFS 和 MapReduce（MR2）组件外，还增加了 YARN 这个组件。此时，MR2 组件只负责数据计算，集群资源管理的功能由 YARN 来负责。相当于：MR1 = MR2 + YARN

（2）Hadoop 1.x 架构中的 MR1 组件本身存在以下问题（在 MR1 中存在 JobTracker 和 TaskTracker 组件）。

JobTracker 存在单点故障问题：如果 Hadoop 集群的 JobTracker 宕机，则整个分布式集群都不能使用了。
JobTracker 承受的访问压力比较大，影响系统的稳定性和扩展性。
MR1 只支持 MapReduce，不支持 Storm、Spark 和 Flink 这些计算引擎。

（3）Hadoop2.x 架构中引入了 YARN 组件，YARN 组件是基于 MR1 组件演化而来的。YARN 组件的核心思想是：将 MP1 组件中 JobTracker 的资源管理和作业调度两个功能分开，分别由 ResourceManager 和 ApplicationMaster 进程来实现。

ResourceManager 进程：负责整个集群的资源管理和调度。
ApplicationMaster 进程：负责应用程序相关的事务，例如任务调度、任务监控等。
YARN 使得多种计算引擎可以运行在一个集群当中，便于管理和资源利用。目前，YARN 可以支持 MapReduce、Spark 和 Flink。

注意：Storm 不支持在 YARN 上执行，是因为 Storm 没有实现 ApplicationMaster 的规则。

4，YARN 的特点

YARN 采用了分层的集群框架，它解决了 MR1 的一系列缺陷，具有以下几种优势。

具有向后兼容性：用户在 MR1 上运行的作业，无须进行任何修改即可运行在 YARN 上。
对于资源的表示以“内存”为单位，比之前以“剩余的 Slot 数量”为单位更合理。
YARN 作为平台提供者，可以支持多种计算引擎的运行，进一步巩固了 Hadoop 的地位。
YARN 和计算引擎是解耦的，计算引擎升级更容易。

5，架构分析

（1）YARN 架构中主要包括 ResourceManager 和 NodeManager 组件：

在 NodeManager 组件内会产生 Container 容器。
MapReduce 任务在运行期间产生的具体子任务会运行在 Container 容器中。

（2）各组件说明如下：

ResourceManager：YARN 集群的主节点，可以支持 1 个或者 2 个，主要负责集群资源的分配和管理。
NodeManager：YARN 集群的从节点，可以支持 1 个或者多个，主要负责当前机器资源的管理。
Container：对任务运行环境进行抽象，封装了 CPU 和内存资源、环境变量、启动命令等任务运行信息。YARN 会为每个子任务分配一个 Container，子任务只能使用该 Container 中描述的资源。

（3）YARN 主要负责管理集群中的 CPU 和内存资源。NodeManager 节点在启动时，会自动向 ResourceManager 节点注册，将当前节点上的可用 CPU 和内存信息注册进去。这样所有的 NodeManager 注册完成后，ResourceManager 就知道目前集群的资源总量了，如下图所示：

（4）在 YARN 中可以支持 2 个 ResourceManager，这样就避免单点故障的问题，保证了 YARN 的高可用，如下图所示：

ResourceManager（Active）：处于活跃状态的 ResourceManager，它会正常履行 ResourceManager 的职责。
ResourceManager（Standby）：处于备用状态的 ResourceManager，它会等待 Active 状态的 ResourceManager 出现故障时进行接管。
ZKFC：作为 ResourceManager 的一个进程服务，负责监控 ResourceManager 的健康状况，并定期向 Zookeeper 集群发送心跳。
RMStateStore：ResourceManager 通过 RMStateStore（支持基于内存的、基于文件系统的和基于 Zookeeper 的，此处默认使用基于 Zookeeper 的）来存储内部数据、主要应用数据和标识等。

6，YARN 中的资源调度器

（1）在实际工作中会遇到类似这样的场景：小明同学向集群中提交了一个任务，该任务把集群中 99% 的资源都占用了；其他同事再提交的任务就会处于等待状态，获取不到足够的资源，无法执行。

单纯对集群增加资源解决不了根本问题。理论上来说，集群资源再多也会遇到这种场景。
如果这时有一个非常紧急的线上任务需要执行，应该怎么办?唯一的解决方案就是：将这个消耗资源的任务“杀死”，释放资源。这样虽然解决了问题，但是也不是长久之计，在工作中会遇到很多类似的问题，不可能每次都去“杀死”任务。

（2）要从源头解决这种问题，则需要给 YARN 选择一个合适的资源调度器。YARN 中支持 3 种调度器：

FIFO Scheduler（先进先出调度器）：按照“先进先出”的策略调度任务，所有的任务在提交之后都是排队的。如果提交的任务申请不到足够的资源，则需要等前面的任务执行结束释放了足够资源再执行。这种逻辑在某些场景下是不合理的：有一些任务的优先级比较高，希望任务提交上去之后立刻就被执行。
Capacity Scheduler（容量调度器）：FIFO Scheduler 的多队列版本，表示先把集群中的整块资源按照一定的用途被划分成多个队列，每个队列的资源是相互独立的，每个队列中的任务还是按照“先进先出”的策略。例如，在 queue A 中运行普通的离线任务，在 queue B 中运行优先级比较高的实时任务。
Fair Scheduler（公平调度器）：支持多个队列，每个队列可以配置一定的资源，每个队列中的任务共享其所在队列的所有资源。假设，小明同学向队列中提交了 1 个任务，这个任务默认占用整个队列的资源；当再提交第 2 个任务后，第 1 个任务会释放出其一部分资源给第 2 个任务使用。

（3）在实际工作中，建议使用 Capacity Scheduler 调度器。从 Hadoop 2.x 版本开始，CapacityScheduler 已经是 YARN 集群的默认调度器了。这个调度器中默认只有一个 default 队列，如下图所示：