YARN：分布式资源管理框架

同期文章：HDFS知识体系（知其然，知其所以然） - 掘金 (juejin.cn)

一、YARN是什么

根据官方官网：Apache Hadoop 3.3.6 -- Apache Hadoop YARN

注：本文加入了自己的理解，与官网有部分不一致。且本人也只是在学习的路上，不是布道者，可先参阅官网，对照解读。

1.Yarn简介

YARN的基本思想是将资源管理和作业调度/监视的功能拆分为单独的守护进程。通过YARN，来获得一个全局的资源管理器ResourceManager （RM ） 和每个应用程序的应用程序管理器ApplicationMaster （AM）。其中应用程序可以是单个作业，也可以是作业的有向无环图DAG。

守护进程，也就是通常说的Daemon进程，可以类比Linux中的后台服务进程。 它是一个生存期较长的进程，通常独立于控制终端并且周期性地执行某种任务或等待处理某些发生的事件。

2.Yarn任务执行框架

如上图，资源管理器ResourceManager和节点管理器NodeManager构成了Yarn任务执行框架。

ResourceManager拥有系统中所有应用程序之间资源的最终分配权限。

NodeManager是每台机器中管理容器container的单个节点的代理，监控其资源使用情况（CPU、内存、磁盘、网络）并向资源管理器ResourceManager报告。（具体应该是向资源管理器中的调度器Scheduler报告）

每个应用程序的 ApplicationMaster 是一个特定计算框架的库（每种计算框架都有自己独特的ApplicationMaster。mapreduce和spark就是两种不同的计算框架），负责与ResourceManager协商资源，并和NodeManager协同来执行和监控任务。

注意，NodeManager是每台机器中管理容器container的单个节点的代理。所以我的理解是，NodeManager其实是对应着dataNode节点的，ResourceManager每多分配一个容器，就会通知NodeManager创建一个容器，并且和ApplicationMaster协同管理监控他们。

我的理解中，这里协同管理可能意味着，NodeManager更侧重资源分配，ApplicationMaster侧重任务监控。

3.ResourceManager的两个主要组件

资源管理器ResourceManager有两个主要组件：调度器Scheduler和应用程序管理器ApplicationsManager。（注意不是Master）

在我的理解中Scheduler承载了资源管理的能力，ApplicationsManager承载作业调度/监控的能力。

Scheduler

其中调度器Scheduler负责资源管理，也就是根据常见的容量大小、队列顺序等限制将资源分配给各种正在运行的应用程序。

调度器Scheduler是纯调度程序，因为它不对应用程序的状态执行监视或跟踪。此外，它不保证由于应用程序故障或硬件故障而重新启动失败的任务。

调度器根据应用程序的资源需求执行其调度功能;它基于资源容器container的抽象概念，其中包含内存、CPU、磁盘、网络等元素。

调度器有一个可插拔的策略，负责在各种队列、应用程序等之间对集群资源进行分区。

ApplicationsManager

ApplicationsManager则负责作业监控调度，它的功能包括：

1. 接受作业提交请求，协商用于执行特定于应用程序的ApplicationMaster的第一个容器
2. 提供在失败时重新启动ApplicationMaster容器的服务。
3. 每个应用程序的 ApplicationMaster负责与Scheduler协商获取适当的资源容器，跟踪其状态并监视进度。

4.Yarn的资源预留和联合功能

Yarn的资源预留

YARN通过ReservationSystem支持资源预留的概念，该组件允许用户指定资源随时间变化和时间限制（例如，截止日期）的配置文件，并预留资源以确保重要作业的可预测执行。预留系统跟踪一段时间内的资源，对预留执行准入控制，并动态指示基础计划程序确保预留得到满足。

以上是官方的原文，但是我实际工作中完全没接触过这部分的内容，可以说是完全搞不懂，但是我查到了以下资料：

在分布式计算中，资源调度器需要选择合适的资源保证机制,当应用程序申请的资源暂时无法保证时:

1.优先为应用程序预留一个节点上的资源直到累计释放的空闲资源满足应用程序需求（称为"增量资源分配"）

2.暂时放弃当前资源直到出现一个节点剩余资源一次性满足应用程序需求（称为"一次性资源分配"）

这两种机制均存在优缺点，对于增量资源分配来说，资源预留会导致资源浪费，降低集群资源利用率；而一次性资源分配则会产生饿死现象，即应用程序可能永远等不到满足资源需求的节点出现。

YARN采用了增量资源分配机制 ，尽管这种机制会造成浪费，但不会出现饿死现象 。我理解这个增量资源分配可能就是这里介绍的资源预留的概念。当然，原文这句预留资源以确保重要作业的可预测执行，可能意味着当我们知道了重要任务的任务id时，可以指定优先级，优先为这个任务预留资源。

Yarn的联合功能

为了将 YARN 扩展到几千个节点以上，YARN 通过 YARN Federation支持集群联合的概念。联合功能允许将多个YARN（子）集群透明地连接在一起成为单个大型集群。

通过联合可实现更大的规模YARN集群，对于在所有集群上都有容量的租户，可以使得多个独立群集能够一起联合起来执行非常大的作业，

二、YARN为什么出现

1.MapReduce自身的瓶颈

在早期Hadoop 1.x版本中是没有YARN的，仅有分布式文件管理系统（HDFS）和分布式计算框架（MapReduce）。MapReduce作业就直接运行在HDFS存储层之上,需要自己处理资源调度和作业管理。久而久之，MapReduce会遇到经常以下几个问题:

1. 缺乏资源管理和调度能力。MapReduce没有统一的资源管理和作业调度机制,并由此导致以下问题：

1. 资源利用率低：由于没有统一的资源管理和调度机制，作业的执行可能会因为资源不足而等待，而其他资源却可能处于空闲状态。这会导致资源利用率低下，无法实现资源的最大化利用。

2. 优先级混乱：由于没有根据优先级及资源状况调度作业的机制，高优先级的作业可能会因为资源不足而等待，而低优先级的作业却可能优先执行。这会导致优先级混乱，影响整体的作业执行效率。

3. 作业执行时间不可预测：由于没有统一的作业调度机制，作业的执行时间不可预测。这会导致作业执行的不确定性，影响系统的可预测性和稳定性。

4. 无法处理大量并发请求：由于没有统一的资源管理和调度机制，当有大量并发请求时，作业的执行可能会受到影响，甚至出现系统崩溃的情况。

5. 无法实现负载均衡：由于没有统一的资源管理和调度机制，作业的执行可能会集中在某些节点上，而其他节点却处于空闲状态。这会导致负载不均衡，影响系统的性能和稳定性。

2. 不支持非MapReduce作业。MapReduce框架仅支持MapReduce类型的作业,不支持Spark,Hive等其他计算框架,但是MapReduce本身限制了计算框架的选择。

3. 可扩展性差。 MapReduce使用Master/Slave架构, Master节点作为job tracker和task tracker的 bottle neck,不易水平扩展。

因为以上的痛点，Hadoop生态里，急需一个能够统一进行资源管理，作业调度的平台，来最大化的利用资源，进行作业调度管理，并提供更大的开放性和扩展性。

因此，Hadoop 2.x版本中引入了YARN。

2.引入YARN带来的好处

YARN将资源管理和作业调度功能从MapReduce中分离出来, 形成了一个通用的资源管理和作业调度平台，因为其任务的重要性，被作为Hadoop的三大基础模块（HDFS、MapReduce、YARN）之一。

YARN提供的功能包括:

1. 资源管理(Resource Management)- 管理和分配集群的CPU,内存,磁盘等资源给不同的应用/作业。

2. 作业调度(Job Scheduling) - 将作业任务调度到集群的节点上运行。

3. 作业监控(Job Monitoring) - 监控作业的运行状态和进度。

4. 高可用性(High Availability) - 当资源管理器失败时,可以快速启动新的资源管理器,保证服务的高可用性。

这样MapReduce就可以脱离这些功能,只需要提交作业和业务计算。它将作业提交给YARN,由YARN完成集群资源分配、作业调度等功能。

而且YARN提供了比原先MapReduce更加全面和高效的集群资源管理能力,使得Hadoop不仅可以支持MapReduce作业,还可以支持Spark,Hive等其他计算框架和编程模型，大大的提升了Hadoop的开放性。

三、YARN架构

YARN的主要组件及其功能

> 对照这张图来看，看组件间的关系会更清晰一点。

1. ResourceManager - 处理客户端请求,启动/监控ApplicationMaster,监控NodeManager,资源分配与调度。其中包含了作业调度的Scheduler和应用程序管理的ApplicationsManager。Yarn中只有一个ResourceManager。

2. NodeManager - 每个节点上运行,管理该节点上的资源使用情况,处理来自ResourceManager的命令。 当ResourceManager每向NodeManager分配一个任务，NodeManager就会为这个任务对应的分配一个Container。Yarn中有多个NodeManager，与ResourceManager是多对一的关系。

3. ApplicationMaster - 负责作业的调度和执行,为应用程序申请资源,并监控任务的运行状况。ApplicationMaster向ResourceManager申请Container运行指定的任务Task，并进行监控管理。ApplicationMaster与ResourceManager是多对一的关系，但是与NodeManager没有对应关系，与作业Job是一对一的关系。

4. Container - 封装了任务运行所需的资源,如CPU,内存等。ApplicationMaster向ResourceManager申请Container,然后在Container上运行任务。Container与ApplicationMaster和NodeManager都是多对一的关系，与任务Task通常是一对一关系，也可以一对多。

在Hadoop内部用"作业"（Job）来表示MapReduce程序。一个MapReduce程序可对应若干个作业，每个作业会被分解成若干个Map/Reduce任务（Task）。

YARN接受并执行任务的全流程

graph TD subgraph ResourceManager B1(ApplicationsManager) B2(Scheduler) end subgraph Node1 C1(NodeManager) C2(Container) C3(Container) end subgraph Node2 D1(NodeManager) D2(Container) D3(Container) end A[用户] -->|1. 提交MapReduce作业| B1 B1 --> |2. 申请资源| B2 B2 -->|3.1. 分配资源| C1(NodeManager) C1 -->|3.2. 创建Container| C2(Container) B1 -->|3.3. 由NodeManager分配Container创建ApplicationMaster| C3(ApplicationMaster) B2 -->|3.1. 分配资源| D1(NodeManager) D1 -->|3.2. 创建Container| D2(Container) D1 -->|3.2. 创建Container| D3(Container) B2 -->|4.1. 发送MapReduce作业和Container信息| C3 C3 -->|4.2. 分解MapReduce作业为Task| D(Task
Map或Reduce任务) C3 -->|4.3. 发送Task| C1 C3 -->|4.3. 发送Task| D1 C1 -->|5. 执行任务Task| C2 D1 -->|5. 执行任务Task| D2 D1 -->|5. 执行任务Task| D3

6、7就不画上去了，这个mermaid的流程图接受不了太多，容易变得很乱，虽然现在已经有点乱了。

1. 用户向YARN提交一个MapReduce作业。 ResourceManager 中的ApplicationsManager接收该请求。
2. ApplicationsManager 根据作业需求，向ResourceManager 申请资源。ResourceManager 为该作业分配资源，通知各个NodeManager ，其中资源是封装成Container形式的。
3. ApplicationsManager 将MapReduce作业和Container 情况发送给ResourceManager 中的Scheduler ，并根据获得的Container 资源,在合适的节点上创建ApplicationMaster。
4. Scheduler 将MapReduce作业和Container 分配给相应的ApplicationMaster 。ApplicationMaster 根据作业需求，将其分解若干个Map/Reduce任务（Task），并发送给NodeManager。
5. NodeManager 根据任务类型启动相应的进程，在Container执行任务（Task）。
6. ApplicationMaster 监控所有任务的执行情况，如果某个任务失败，它会重新向ResourceManager申请资源，并重新调度该任务。
7. 当所有任务都执行成功后，ApplicationMaster 将结果报告给ApplicationsManager ，由 ApplicationsManager将结果报告给用户。

每一个Container就是一个独立的JVM实例。每一个任务都是在Container中独立运行，例如：MapTask、ReduceTask。当scheduler调度时，它会根据任务运行需要来申请Container，而每个任务其实就是一个独立的JVM。

四、其他的资源管理框架

Hadoop 生态系统中的其他管理调度框架

Hadoop 生态系统中除了 YARN 之外,还有一些其他的资源管理和作业调度组件:

1. Mesos:来自 Apache 的资源管理和作业调度平台,可以集群资源管理和进程隔离。Spark、Hadoop 等计算框架可以运行在 Mesos 上。

2. Kubernetes:Google 开源的容器编排系统,也可以用于集群资源管理和作业调度。Spark 等计算框架可以通过 Kubernetes 进行资源调度。

3. Flink:Flink 自身含有简单的资源管理和作业调度功能,可以用于单独的 Flink 集群。

4. Standalone Schedulers:一些计算框架如 Spark 有自己的 Standalone 调度器,可以用于资源调度。

5. YuniKorn:一个通用的 Kubernetes 原生调度器,可以集成到 Kubernetes 平台上,调度各种 workload。

6. Slurm:一个开源的作业调度器,支持多个平台,可以用于 HPC 和大数据作业调度。

7. Livy:Spark 的 REST 接口服务,含有简单的队列调度功能。

除了 YARN,还有 Mesos、Kubernetes、Flink 自身调度器等选择,可以根据使用场景进行选择。但 YARN 在 Hadoop 生态系统中仍然是最常用的资源管理和作业调度平台。

YARN的优势

1. 设计用于 Hadoop,深度整合了 Hadoop 组件如 HDFS、MapReduce。与 Hadoop 安全集成良好,支持 Kerberos 等
2. 资源利用率高,可以充分利用集群资源
3. 支持多种编程框架,不仅支持 MapReduce,还可以运行 Spark、Hive 等作业
4. 成熟稳定,经过产业考验,大规模应用
5. 丰富的调度策略,支持多队列、预留资源等

YARN的劣势

1. YARN只适用于 Hadoop 生态系统,不具有通用性
2. 配置和调优比较复杂
3. 不如 Mesos 和 Kubernetes 原生支持容器
4. 限制作业类型,不适合像 MPI 这样的低延迟作业
5. 不支持作业的预打断和迁移

相比而言: Mesos 更加通用,可以跨平台调度,对容器支持也更好。 Kubernetes 更适合基于微服务架构和容器编排的场景。 Flink 适合仅运行 Flink 作业的简单场景。

总结一下，YARN 的优势在于和 Hadoop 的整合程度更高,适合大数据场景;缺点是不如 Mesos 和 Kubernetes 通用和对容器的支持。需要根据具体使用场景进行选择。