Apache Hadoop YARN 的架构与运行流程

Feb 10 2022

阿里云代理

分类：linux图文教程阅读次数

已被围观 903 次

YARN 概述

Yarn 是一个资源调度渠道，负责为运算程序供给服务器核算资源，相当于一个分布式的操作系统渠道，而 MapReduce、Spark、Flink 等运转程序则相当于运转于操作系统渠道之上的应用程序。

YARN 产生的布景

Yarn 是 Hadoop2.X 版别中的一个新的特性。它的出现其实是为了处理第一代 MapReduce 编程结构的缺乏，进步集群环境下的资源利用率，这些资源包括了内存、磁盘、网络等等。

Hadoop2.X 版别中从头设计的这个 YARN 集群，具有更好的扩展性，可用性，可靠性，向后兼容性，以及能支持除 MapReduce 以外的更多分布式核算结构。

在 MapReduce 1.x 时的架构图如下：

从上图能够看到，1.x 时也是 Master/Slave 这种主从结构，在集群上的体现便是一个JobTracker 和多个 TaskTracker。

JobTracker：负责资源办理和作业调度
TaskTracker：定时向 JobTracker 报告本节点的健康状况、资源运用情况以及作业履行情况。还能够接收来自JobTracker的指令，例如发动使命或结束使命等。

那么，这种架构会存在哪些问题？

整个集群中只要一个 JobTracker，存在单点故障。
JobTracker 节点压力大，不但要处理Client 的恳求，还得处理 TaskTracker 的心跳等恳求。
因为 JobTracker 是单节点，所以容易成为集群中的瓶颈，不易扩展。
JobTracker 负责的作业太多，基本上所有的作业都需求跟 JobTracker 进行交互。
1.x 的整个集群只支持MapReduce 使命，不支持其他例如 Spark 的使命。

依据上面的种种原因，Hadoop 在 2.x 中对资源调度进行了剥离，形成了独自的组件，也便是 Yarn 。

YARN 的架构

Yarn 的架构图如下：

YARN 的基本思想是将资源办理和作业调度/监视的功能分解为独自的守护进程。它拥有一个大局 ResourceManager（RM）和每个应用程序 ApplicationMaster（AM）。应用程序能够是单个作业，也能够是作业的DAG（有向无环图，能够理解为对作业相互之间的依赖联系的一种描绘）。

ResourceManager

ResourceManager 是依据应用程序对集群资源的需求进行调度的 YARN 集群主控节点，负责协调和办理整个集群（所有 NodeManager）的资源，响应用户提交的不同类型应用程序的解析，调度，监控等作业。ResourceManager 会为每一个 Application 发动一个 MRAppMaster，而且 MRAppMaster 分散在各个 NodeManager 节点　　它主要由两个组件构成：调度器（Scheduler）和应用程序办理器（ApplicationsManager， ASM）

ResourceManager 的责任：

处理客户端恳求　　　　
发动或监控 MRAppMaster　　　　
监控 NodeManager　　　　
资源的分配与调度

NodeManager

NodeManager是每台机器结构署理，负责容器（Container）的办理，监视其资源运用情况（CPU，内存，磁盘，网络）并将其报告给 ResourceManager / Scheduler。

NodeManager 的责任：　　　　

办理单个节点上的资源，敞开容器。
处理来自 ResourceManager 的指令　　　　
处理来自 MRAppMaster 的指令

ApplicationMaster

每个程序都对应一个 ApplicationMaster，它负责向资源调度器申请履行使命的资源容器，运转使命，监控整个使命的履行，跟踪整个使命的状态，处理使命失利以异常情况。

Container

Container 容器是一个笼统出来的逻辑资源单位。容器是由 ResourceManager Scheduler 服务动态分配的资源构成，它包括了该节点上的一定量 CPU，内存，磁盘，网络等信息，MapReduce 程序的所有 Task 都是在一个容器里履行完结的，容器的大小是能够动态调整的。

YARN 履行流程

先上图，以 WordCount 的整个运转流程为例：

整个进程如下：

客户端所在的机器履行 job.submit() ,调用 YarnRunner 去向 ResourceManager 申请提交一个 application。
ReourceManager 回来一个资源提交的地址 hdfs://xxx/.staging/applicationid/ 和 applicationid。因为后续的使命需求履行这些个资源文件，到这个阶段，还不了解每个使命到底会分配到哪台机器上，爽性直接给一个都能访问到的地址，使命到谁那里，就自己去这个方位拉取需求的jar 包和配置信息。
YarnRunner 提交 job 所需求的资源文件到上面的地址。
YarnRunner 提交资源结束，向 ResourceManager 申请发动 MrAppMaster。
ResourceManager 收到恳求，然后封装成一个 task 放入使命行列，等待 NodeManager 获取履行，此行列默认运用FIFO。
NodeManager1 把这次使命下载到本地。
NodeManager1 下载 job 相关的文件，并在本地地发动一个 Container 运转 MrAppMaster ，container 便是一个容器，利用的是 linux 的 cgroup ,现在市面上的虚拟化技能底层也是运用的此技能。
MrAppMaster 依据配置信息，去跟 ResourceManager 申请运转 maptask 的容器，仍是跟第 5 步相同，ReourceManager 拿到后封装成一个task 放到使命行列。
Nodemanager 2 和 3 分别下载上个过程的 task 使命 ,然后在本地发动一个 container 容器。
MrAppMaster 向第9 步新发动的容器发送复制文件、履行 maptask 等使命的指令。maptask 履行完结后，把数据写到自己本地，容器的作业目录。
MrAppMaster 再向 YARN 恳求资源来运转 reducetask 使命。
reducetask 向 map 端获取相应的分区数据进行处理，处理完结后进行输出。
整个 applicetion 履行完结后，MrAppMaster 向 ResourceManager 申请销毁自己。