[Yarn] 一篇文章读懂Yarn：产生背景、核心思想、工作流程、资源模型

朱雀 2022-02-02 18:59 303阅读 0赞

# 一、Yarn：前情概要 #

在Hadoop的世界里，【资源】是：CPU、内存、磁盘、网络等

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70]  
Yarn，集群操作系统（Cluster OS、Data Operating System）

普遍认为，Hadoop 2.0 和Yarn其实是一个东西，只是名字不同而已，提到Yarn，就知道是Hadoop 2.0。因为在2012年5月16日，Hadoop 2.0发布时，Yarn是最大的亮点之一，Yarn是随着Hadoop 2.0一路走来的。

Yarn是Hadoop的一部分，目前（2019-05-13）官网关于Yarn的最新描述Hadoop 2.9.2-Yarn（2018-11-13）。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70 1]

# 二、Yarn：产生背景 #

## 1、Hadoop 1.0 MRv1时代 ##

上图可知，在Hadoop 1.0时代，资源管理（Resource Management）、数据处理（Data Processing）均由MapReduce引擎完成。

**一个Hadoop集群** （基于Master/Slaves模式）可分解为 两个抽象实体：

*  HDFS：提供了一种存储模式，可跨节点复制数据以进行处理。通过定义来支持大型文件（其中每个文件通常为 `64 MB` 的倍数）；
 *  MapReduce：能够在整个集群上执行 Map 和 Reduce 任务并报告结果。具体的是 可进行大规模数据集的并行计算（如文字、图形处理，数据挖掘等）。

**Hadoop 集群**可**从单一节点**(其中所有Hadoop实体都在同一个节点上运行)**扩展到数千个节点**(其中的功能分散在各个节点之间，以增加并行处理活动)，下图演示了一个Hadoop集群的高级组件：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70 2]

\-----简要说明以下名词-----  
**NameNode：**是Master节点，是大领导，是文件系统的主系统，提供元数据服务来执行数据分发和复制。管理数据块映射、处理Client读写请求、配置副本策略、管理HDFS的名称空间等。  
**对应于JobTracker：**是一个Master服务，是MR框架的中心，是一个中央守护进程，软件启动之后JobTracker接收Job，负责调度Job的每一个子任务task运行于TaskTracker上，并监控它们，如果发现有失败的task就重新运行它

**DataNode：**是NameNode的小弟，负责存储Client发来的数据块Block、执行数据块的读写操作  
**对应于TaskTracker：**运行在多个节点上的slave服务，是一个系统的从进程，TaskTracker主动与JobTracker通信，接收作业，并负责直接执行每一个任务

\-----小总结-----  
**NameNode、DataNode**是针对数据存放而言；  
**JobTracker、TaskTracker**是针对MR执行而言。

从【Hadoop 1.0 MapReduce（MRv1）架构图】可看出其设计思路和流程：

*  ①用户程序（JobClient）提交一个Job，其信息会发送到到JobTracker，并由它管理，它会与集群中的机器（节点）定时通信（HeartBeat），管理哪些程序应该跑在哪些机器上、管理所有Job失败、重启等操作。也就是说：JobTracker 与 NameNode 联合将工作分发到离它所处理的数据尽可能近的位置
 *  ②JobTracker 将 Map 和 Reduce 任务安排到一个或多个 TaskTracker 上的可用插槽（基于slot的资源分配模型，同一时间一个slot只可运行一个Task）中。TaskTracker 与 DataNode（分布式文件系统）一起对来自 DataNode 的数据执行 Map 和 Reduce 任务。当 Map 和 Reduce 任务完成时，TaskTracker 会告知（HeartBeat） JobTracker，后者确定所有任务何时完成并最终告知客户作业已完成。

MRv1 实现了一个相对简单的集群管理器来执行 MapReduce 处理、提供了一种分层的集群管理模式，其中大数据作业以单个 Map 和 Reduce 任务的形式渗入一个集群，并最后聚合成作业来报告给用户。但随着互联网业务数据量爆炸式增长、分布式系统集群的规模、工作负荷的增长，MRv1框架问题/缺陷/不足浮出水面，主要呈现如下：

*  ①JobTracker 是 Map-Reduce 的集中处理点，存在单点故障（SPOF，Single Points Of Failure）；
 *  ②JobTracker要完成太多任务时（承受的访问压力大），将会有过多的资源消耗，即 当Map-Reduce job非常多时，会造成很大的内存开销，潜在地增加了JobTracker fail风险。也就是业界所总结的Map-Reduce只能支持4000节点主机的上限；
 *  ③在TaskTracker端，仅以Map/Reduce task数目作为资源的表示过于简单，没有考虑到CPU/内存占用情况，如果两个内存消耗大的task被调度到一起，容易出现OOM；
 *  ④在TaskTracker端，把资源强制划分为Map task slot和Reduce task slot，如果只有Map task或只有Reduce task时，会造成资源浪费；
 *  ⑤源代码分析层面，有的class做了太多事，代码量达3000多行，致使class任务不清晰，增加bug修复、版本维护难度；
 *  ⑥操作层面，bug修复/性能提升时，MRv1框架会强制系统级别的更新，甚至让集群中每一个用户端同时更新，这使得验证之前的程序是否适合更新后的Hadoop版本而浪费大量时间；
 *  ⑦不支持MapReduce之外的计算框架，如Spark/Strom/flink。

## 2、Hadoop 2.0 MRv2（Yarn）时代 ##

如果要修复MRv1的单JobTracker/多TaskTracker机制的可扩展性、内存消耗、线程模型、可靠性、性能等缺陷，将是大规模的调整。。。

为彻底解决MRv1框架缺陷，促进Hadoop长远发展，以Hadoop 0.23.0版本为基础，完全重构Hadoop。新的Hadoop MapReduce框架命名为MRv2（即 Yarn，它将资源管理工作做的更细致了），架构图如下所示：  
![在这里插入图片描述][20190513130209270.png]  
**重构的根本思路：**将原先MRv1的JobTracker两个主要的功能（资源管理 RM、任务调度/监控）分离成单独的组件。

**在MRv2（Yarn）框架中：**主要是4大组件

*  **Resource Manager**（RM，有两个子模块（组件） Applications Manager（资源管理器）、Scheduler（调度器））：是一个中心服务，负责整个系统（所有应用程序）的资源管理和分配，具体点是 调度、启动每一个Job所属的AM、监控AM的存在情况，再具体点是 负责作业与资源的调度，接收JobSubmitter提交的作业，按照作业的上下文（Context）信息，以及从NM收集来的状态信息，启动调度过程，分配一个Contrainer作为AM；
 *  **Application Master**（AM，看作MRv1的JobTracker。从Yarn角度看，是用户代码）：如图每一个AM负责其Job生命周期的所有工作，即 向调度器索要适当的资源容器，任务切割、运行任务，跟踪应用程序的状态和监控它们的进程，（容错）处理任务的失败原因。每个应用程序AM都是一个引导进程；
 *  **Node Manager**（NM，本质上是Yarn的工作守护进程）：是每一台机器框架的代理（单个节点上的资源和任务管理器），管理集群中独立的计算节点，拥有和管理执行应用程序的各种各样的Container（它才是真正干活的），监控应用程序的资源使用情况，并向调度器汇报。功能专一，负责Container状态的维护，并向RM保持心跳。NM的核心功能是管理Container；
 *  **Container**：是Yarn的资源抽象，封装了某个节点上的多维度资源（内存、CPU、磁盘、网络等物理资源的集合）。一个节点可以有一个或多个Container，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示。Yarn会为每一个任务分配一个Container，且该任务只能使用该Container中描述的资源。容器是一个动态划分资源。其中，AM可以看作是一种特殊的Container。Container由NN监控、RM调度。
 *  用RPC（Remote Procedure Call，远程过程调用）实现模块间通信，任意两个模块之间只有一个Protocol，且总是由Client主动去连接Server；
 *  JobHistory机制：MRv1时，JobHistory Server是嵌入在JobTracker中的，当有大量查询时，将会对JobTracker造成很大压力。而Yarn实现了一套单独的JobHistory Server。
 *  另外：数据处理（Data Processing）任务仍交互MapReduce处理，或其他计算框架处理（如Spark）

![在这里插入图片描述][201905132208347.png]  
一个应用程序，可理解为 一个单独的传统的MapReduce任务或一个DAG（有向无环图）任务。每一个应用程序的AM 从RM获得资源，并与NM协同工作来运行、监控任务。

> Scheduler主要负责对整个集群的资源进行分配调度。  
> 分配资源 以Container的形式分发到各个应用程序中（如MapReduce作业），应用程序与资源所在节点的Node Manager协作利用Container完成具体的任务（如Reduce Task）。  
> 注意：Scheduler是个纯粹的调度器，意思是它不参与任何监控跟踪应用状态的工作，也不会保证在任务失败后重新启动任务。

从某种意义上，RM是一个纯粹的调度器，支持分层级的应用队列，享有集群一定比例的资源。在执行过程中，不会对 应用程序进行监控和状态跟踪，也不能重启失败的任务。

RM是基于应用程序对资源的需求进行调度的，而每一个应用程序可能需要不同类型的资源，因此就需要不同的容器（Container）。这与固定类型的资源使用模型有显著区别。

RM提供一个调度策略的插件（Sheduler），它负责将集群资源分配给多个队列和应用程序，并基于现有的能力公平调度。

> Container是Yarn框架的计算单元，是具体执行应用task（如map task、reduce task）的基本单位。  
> Container和集群节点的关系是：一个节点会运行多个Container，但一个Container不会跨节点。  
> 既然一个Container指的是具体节点上的计算资源，这就意味着Container中必定含有计算资源的位置信息：计算资源位于哪个机架的哪台机器上。  
> 所以我们在请求某个Container时，其实是向某台机器发起的请求，请求的是这台机器上的CPU和内存资源。

## 3、总结：MRv1和MRv2（Yarn）对比、Yarn优势 ##

MRv2（Yarn）对比MRv1：

*  Client不变，其调用API大部分保持兼容，让开发者不必对原有代码做大的改变；
 *  MRv1核心的JobTracker、TaskTracker不见了，取代它们的是RM、AM、NM。

MRv2（Yarn）优势：

*  大大减小了JobTracker（MRv1-RM）的资源消耗，并让监控每一个Job子任务（tasks）状态的程序分布式化，更安全、优美；
 *  MRv2（Yarn）中，AM是一个可变更部分，用户可以对不同的编程模型写自己的AM，让更多类型的编程模型（包括图形处理、迭代式处理、机器学习和一般集群计算）能够跑在Hadoop集群上；
 *  对资源的表示以内存为单位，比之前以剩余slot数目更合理。内存决定生死，CPU决定快慢；
 *  容错率更高。MRv1-JobTracker一个很大的负担是监控job下tasks运行状况，MRv2中这个工作给AM了，而RM中有一个模块（Applications Masters，注意不是Application Master）监测AM运行情况，若出现问题，会将其在其他机器上重启；
 *  Container是Yarn为资源隔离提出的框架，借鉴了Mesos，提供java虚拟机内存的隔离，将资源表示成内存量，避免了MRv1的Map slot和Reduce slot分开造成集群资源闲置的尴尬。

运行在Yarn上的计算框架：

*  离线计算框架：MapReduce
 *  DAG计算框架：Tez
 *  流式计算框架：Storm
 *  内存计算框架：Spark
 *  图形计算框架：Giraph、Graphlib

# 三、Yarn：核心思想 #

将JobTracker的两个功能（资源管理、作业调度/监控）分离，主要方法是创建一个全局的RM、若干个针对应用程序的AM。

Yarn由下方4大构成组件：

*  RM：负责为集群的所有应用程序分配资源
 *  NM：每个节点代理NodeManager
 *  AM：每个应用对应一个Application Master
 *  Container：一个Application Master拥有多个Container，Container在NodeManager上运行

运行在独立节点上的RM和NM一起组成了Yarn的核心，且构成了这个平台；  
AM和相应的Container一起组成了一个Yarn的应用程序。

从Yarn角度看，所有用户通过提交应用程序，然后利用该平台提供的资源来进行交互；  
从最终用户角度看，是直接在Yarn平台上通过应用程序和Yarn进行交互。

# 四、Yarn：工作机制概述 #

运行在Yarn上的 应用程序主要分为两类：

*  短应用程序：指一定时间（可能是秒级、分钟级、小时级，天级别或更长时间的也存在，但很少）内可运行完成，并退出的应用程序，如MapReduce作业、Tez DAG作业等
 *  长应用程序：指不出意外，永不停止地运行的应用程序，通常是一些服务，如HBase Server（包括Hmaster、RegionServer两类服务）、Storm Server（包括Nimbus、Supervisor两类服务）等，而它们本身作为一个框架提供了编程接口 供用户使用

尽管这两类应用程序 作用不同，一类直接运行数据处理程序、一类用于部署服务（服务之上再运行数据处理程序），但运行在Yarn上的流程是相同的。

当用户向Yarn提交一个应用程序后，Yarn将分两个阶段运行该应用程序：

*  第一阶段：启动Application Master；
 *  第二阶段：由Application Master创建应用程序，为它申请资源，并监控它的整个运行过程，直至运行完成。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70 3]  
根据上图，可将Yarn的工作流程分为如下几个步骤：

步骤1：用户向Yarn中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等；

步骤2：ResourceManager为该应用程序分配第一个Container，并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster；

步骤3：ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复图中的步骤4～7；

步骤4：ApplicationMaster采用轮询的方式通过RPC协议向ResourceMaster申请和领取资源；

步骤5：一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务；

步骤6：NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务；

步骤7：各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可以随时通过RPC向ApplicationMaster查询应用程序的当前运行状态；

步骤8：应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。

# 五、Yarn：资源模型 #

资源：CPU、内存、网络带宽、磁盘等  
![在这里插入图片描述][20190514144053650.png]  
**1、客户端资源请求：**

第一步：客户发送一个即将要提交程序的请求

第二步：RM在应答中给出一个ApplicationID，以及有助于客户端请求资源的容量信息

**2、Container分配：**

客户端在第三步中使用“ Application Submission Context”发出响应，Application Submission Context，包括ApplicationID、用户名、队列以及其他启动 Application Master所需(内存、CPU)、作业文件、安全令牌、以及在节点上启动 Application Master 需要的其他信息。

应用程序被提交后,客户端也可以向 Resource Manager请求杀死这个应用程序，或者提供该应用程序的状态报告

当Resource Manager收到来自客户端的应用程序提交的上下文，它就会为Application Master调度一个可用 Container，这个Container通常称为 `Container0`，因为它是Application Master，必须请求其他的 Container。如果没有适用的 Container，这个请求必须等待。如果找到了合适的 Container，Resource Manager就会联系相应的 Node Manager并启动 Application Master(图第四步)。作为此步骤的一部分，将建立 Application Master的RPC端口和用于跟踪的URL，用来监控应用程序的状态。

在注册请求的响应中，Resource Manager会发送关于集群的最小和最大容量信息(第五步)。在这一点上，Application Master须决定如何使用当前可用的资源。与一些客户端请求硬限制的资源调度系统不同，Yarn允许应用程序适应当前的集群环境(如果可能的话)。基于来自 Resource Manager的可用资源报告，Application Master会请求一定量的Container(图第六步)。该请求可以非常具体，包括最小资源整数倍的 Container(如 额外的内存)。

Resource Manager会基于调度策略，尽可能最优的Application Master分配Container资源，作为资源请求的应答发给 Application Master(图第七步)。

随着作业的执行，Application Master将心跳和进度信息通过心跳发给 Resource Manager。在这些心跳中，Application Master还可以请求和释放 Container。当作业结束时，Application Master向 Resource Manager发出一个 Finish消息，然后退出。

**3、ApplicationMaster与Container管理器的通信：**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70 4]  
Resource Manager已经将分配NodeManager的控制权移交给Application Master，AM将独立联系其指定的节点管理器并提供 Container launch Context(CLC，它包括环境变量、远程存储依赖文件、安全令牌、启动实际进程所需的命令)。

当Container启动时，所有的数据文件、可执行文件、必要的依赖文件都被拷贝到节点的本地存储上了。依赖文件可以被运行中的应用程序的Container之间共享。

一旦所有的Container都被启动，Application Master就可以检查它们的状态。

RM不参与应用程序的执行，只处理调度和监控其他资源。

RM可以命令NM杀死Container，在AM通知RM自己完成了、或Resource Manager需要为另一个应用程序抢占资源、或Container超出资源限制时都可能发生杀死 Container事件。当 Container被杀死后，Node Manager会清理它的本地工作目录。

作业结束后，Application Master通知Resource Manager该作业成功完成。

然后Resource Manager通知Node Manager聚集日志并且清理 Container专用的文件。如果Container还没有退出，Node Manager也可以接受指令去杀死剩余的Container(包括Application Master)。

**4、管理应用程序的依赖文件：**

在Yarn中，应用程序通过运行Container来执行它们的工作，这些 Container对应于运行在底层操作系统上的进程。

Container上有执行程序依赖的文件，这些文件在启动时、或应用程序的执行过程中可能需要一次或多次。例如，要在Container中启动一个简单的Java进程，我们需要一组类文件、或更多依赖的Jar文件。

Yarn没有强迫每个应用程序每次都远程访问(大部分是读)这些文件、或让它们自己管理这些文件，而是为应用程序提供了本地化这些文件的能力。

当启动一个Container时，Application Master可以指定该Container需要的所有文件。因此，这些文件都应该被本地化。一且指定了这些文件，Yarn就会负责本地化，并且隐藏所有安全拷贝、管理、以及后续的删除等引入的复杂性。

参考  
1、[Apache Hadoop Yarn官网][Apache Hadoop Yarn]  
2、[MapReduce 2.0 in Apache Hadoop 0.23][]  
3、[hadoop Yarn和版本1的比较][hadoop Yarn_1]  
4、百度

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70]: /images/20220202/6b0eaeeba595477381cf4daed8170a04.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70 1]: /images/20220202/4b55670903ff425b8b4a66aa56245430.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70 2]: /images/20220202/9f8d2bcc0a614d76b31711705051f170.png
[20190513130209270.png]: /images/20220202/13368a08236e4b0f968aa5c34be58146.png
[201905132208347.png]: /images/20220202/0e8170d2ae524e658e584e3731f3b8f9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70 3]: /images/20220202/e37ed3a1d96c495f9b128b539405ce32.png
[20190514144053650.png]: /images/20220202/54c1dcf6911443c2981563f61578fb00.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI1NjQ3NA_size_16_color_FFFFFF_t_70 4]: /images/20220202/436a006db74647399f131f214cb41cc7.png
[Apache Hadoop Yarn]: http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html
[MapReduce 2.0 in Apache Hadoop 0.23]: https://blog.cloudera.com/blog/2012/02/mapreduce-2-0-in-hadoop-0-23/
[hadoop Yarn_1]: https://www.jianshu.com/p/9c298f67c73c