YARN 架构设计

最新推荐文章于 2024-08-20 07:30:00 发布

郭朝阳@

最新推荐文章于 2024-08-20 07:30:00 发布

阅读量1.4k

点赞数

分类专栏： Hadoop 文章标签：大数据

本文链接：https://blog.csdn.net/weixin_43588586/article/details/117638699

版权

Hadoop 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

YARN 架构设计

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

一、Hadoop MRv1 不足
二、Hadoop YARN 架构演进
三、Hadoop YARN 概述
四、Hadoop YARN（MRv2）优势
五、YARN 核心组件功能特性分析

一、Hadoop MRv1 不足

原 MapReuce 框架也称 MRv1，它是一个主从式的架构。主节点 JobTracker 负责集群的资源管理和处理 Client 请求，从节点 TaskTracker 负责管理资源和执行任务。不仅存在 JobTracker 的 SPOF 问题，而且 JobTracker 的负载非常高，集群的资源管理也非常粗暴不合理。
在这里插入图片描述

1、单点故障，可靠性低：JobTracker 采用了 master/slave 结构，是集群事务的集中处理点，存在单点故障
2、单点瓶颈，扩展性差：JobTracker 需要完成的任务太多，Jobtracker 兼顾资源管理和作业控制跟踪功能跟踪任务，启动失败或迟缓的任务，记录任务的执行状态，维护计数器），压力大，成为系统的瓶颈
3、资源管理和任务执行强耦合：在 TaskTracker 端，用 Map/Reduce Task 作为资源的表示过于简单，没有考虑到 CPU、内存等资源情况，当把两个需要消耗大内存的 Task 调度到一起，很容易出现 OOM
4、资源利用率低：基于槽位的资源分配模型，槽位是一种粗粒度的资源划分单位，通常一个任务不会用完一个槽位的资源，hadoop1把资源强制划分为Map/Reduce 两种Slot，当只有 MapTask 时，Teduce Slot 不能用；当只有 Reduce Task 时，Map Slot 不能用，容易造成资源利用不足。
5、不支持多种分布式计算框架。

二、Hadoop YARN 架构演进

从 Hadoop-2.x 开始，Hadoop 的架构发生了变化：将原来的 MapReduce（资源的管理调度和数据的处理计算）集群一分为二：MapReduce 和 YARN

MapReduce：仅仅只是一套用来编写分布式计算应用程序的 API
YARN：是一个 master/slave 架构的分布式集群，用来进行集群的资源管理和调度工作，提供了 job 调度规范，除了能运行MapReduce 应用程序

之外，还可以支持 Spark，Flink 等分布式计算应用程序。在这里插入图片描述
这样拆分的目的，大大的提高了 Hadoop 平台的通用性，逐渐演变成一个大数据基础平台，甚至可以理解成用来解决大数据问题的分布式操作系统。

Hadoop-2.x 分为四个部分： common, hdfs，mapreduce, yarn

三、Hadoop YARN 概述

YARN，Yet Another Resource Negotiator，是 Hadoop-2.x 版本中的一个新特性，它为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。它的出现其实是为了解决第一代 MapReduce 编程框架的不足，提高集群环境下的资源利用率，这些资源包括内存，磁盘，网络，IO等。Hadoop-2.X 版本中重新设计的这个 YARN 集群，具有更好的扩展性，可用性，可靠性，向后兼容性，以及能支持除 MapReduce 以外的更多分布式计算程序。YARN 负责将系统资源分配给在 Hadoop 集群中运行的各种应用程序，并调度要在不同集群节点上执行的任务。它相当于一个分布式的操作系统平台，而 MapReduce 等运算程序则相当于运行于操作系统之上的应用程序。
YARN 的核心特性：

YARN 并不清楚用户提交的程序的运行机制，只是提供了一套资源管理和调度的规范。
YARN 只提供运算资源的调度（用户程序向 YARN 申请资源，YARN 就负责分配资源，具体的计算执行逻辑完全由用户程序决定）
YARN 是一个 master/slave 的主从机构，依靠 ZooKeeper 实现 HA，主节点叫做ResourceManager，从节点叫做 NodeManager
YARN 被设计成一个通用的资源管理和作业调度平台，Spark、Flink 等运算框架都可以整合在 YARN 上运行，只要满足 YARN 规范的资源请求机制即可

四、Hadoop YARN（MRv2）优势

YARN/MRv2 最基本的想法是将原 JobTracker 主要的资源管理和 Job 调度/监视功能分开作为两个单独的守护进程。有一个全局的ResourceManager(RM) 和每个Application 有一个 ApplicationMaster(AM)，Application 相当于 MapReduce Job 或者 DAG jobs。ResourceManager和 NodeManager(NM) 组成了基本的数据计算框架。ResourceManager 协调集群的资源利用，任何 Client 或者运行着的 ApplicatitonMaster 想要运行Job 或者 Task 都得向 RM 申请一定的资源。ApplicatonMaster 是一个框架特殊的库，对于 MapReduce 框架而言有它自己的 AM 实现，用户也可以实现自己的 AM，在运行的时候，AM 会与 NM 一起来启动和监视 Tasks。
在这里插入图片描述
1、极大减小了 JobTracker 的资源消耗。每个应用程序的 ApplicationMaster 都分布式在分布式在整个集群的所有 NodeManager 中了。
2、YARN 中的 ApplicationMaster 只是一个规范。用户可以把自己的分布式计算应用程序部署到 YARN 上运行，只要满足 ApplicationMaster 的规范
3、YARN 中的 Container 的资源抽象比 Slot 更合理。老版本的 Slot 分为 mapslot 和 reduceslot，不能混合使用，资源利用率低。
4、借用 ZooKeeper 解决 RM 的 SPOF 问题。老版本的 JobTracker 是存在 SPOF 的问题的。

五、YARN 核心组件功能特性分析

YARN 采用 C/S 架构，主要有一下几大组件。

1.YARN Client

YARN Client 提交 Application 到 ResourceManager，它会首先创建一个 Application 上下文件对象，并设置 ApplicationMaster 必需的资源请求信息，
然后提交到 ResourceManager。YARN Client 也可以与 ResourceManager 通信，获取到一个已经提交并运行的 Application 的状态信息等。

2.ResourceManager

管理者（主节点：做管理工作） + 工作者（提供计算或者存储资源的，用来解决实际问题的）

ResourceManager 是一个全局的资源管理器，集群只有一个，有 SPOF 问题，可以通过 ZooKeeper 实现 HA 机制，它主要负责整个系统的资源管理和分配，响应用户提交的不同类型应用程序的解析，调度，监控等工作，启动和监控 ApplicationMaster，监控 NodeManager 等。
整体职责解析：

处理客户端请求
启动和监控 ApplicationMaster
监控 NodeManager
负责资源的分配与调度

内部组成结构如下：
在这里插入图片描述
所有的这些 Service 都会经历三个步骤：

Service 实例的创建，创建好了之后，放在 CompositeService 的 serviceList 这个成员变量集合中
然后遍历这个 serviceList 集合，取出每个 service 调用 serviceInit() 方法
然后遍历这个 serviceList 集合，取出每个 service 调用 serviceStart() 方法

关于上述图中的 ResourceManager 的主要成员的工作职责解析：

2.1、用户交互模块

ClientService：是为普通用户提供的服务，它会处理来自客户端各种 RPC 请求，比如提交应用程序、终止应用程序，获取应用程序运行状态等。

AdminService：YARN 为管理员提供了一套独立的服务接口，以防止大量的普通用户请求使管理员发送的管理命令饿死，管理员可通过这些接口管理集群，比如动态更新节点列表，更新 ACL 列表，更新队列信息等。

2.2、NodeManger 管理

NMLivelinessMonitor：监控 NM 是否活着，如果一个 NodeManager 在一定时间（默认10min）内未汇报心跳信息，则认为它死掉了，会将其从集群中移除。

NodesListManager：维护正常节点和异常节点列表，管理 exlude（类似于黑名单）和 inlude（类似于白名单）节点列表，这两个列表均是在配置文件中设置的，可以动态加载。

ResourceTrackerService：处理来自 NodeManager 的请求，主要包括两种请求：注册和心跳。其中，注册是 NodeManager 启动时发生的行为，请求包中包含节点ID，可用的资源上限等信息，而心跳是周期性行为，包含各个 Container 运行状态，运行的 Application 列表、节点健康状况（可通过一个脚本设置)，而ResourceTrackerService 则为 NM 返回待释放的 Container 列表、Application 列表等。

2.3、ApplicationMaster 管理

AMLivelinessMonitor：监控 AM 是否活着，如果一个 ApplicationMaster 在一定时间（默认为10min）内未汇报心跳信息，则认为它死掉了，它上面所有正在运行的Container 将被认为死亡，AM本身会被重新分配到另外一个节点上（用户可指定每个 ApplicationMaster 的尝试次数，默认是1次）执行。

ApplicationMasterLauncher：与 NodeManager 通信，要求它为某个应用程序启动 ApplicationMaster。

ApplicationMasterService：处理来自 ApplicationMaster 的请求，主要包括两种请求：注册和心跳。其中，注册是 ApplicationMaster 启动时发生的行为，包括请求包中包含的所在节点，RPC 端口号和 tracking URL 等信息；而心跳是周期性行为，包含请求资源的类型描述、待释放的 Container 列表等，而 AMS 则为之返回新分配的 Container、失败的 Container 等信息。

2.4、Application 管理

ApplicationACLsManager：管理应用程序访问权限，包含两部分权限：查看和修改，查看主要指查看应用程序荃本信息，而修改则主要是修改应用程序优先级、杀死应用程序等。

RMAppManager：管理应用程序的启动和关闭。

ContainerAllocationExpirer：YARN 不允许 AM 获得 Container 后长时间不对其使用，因为这会降低整个集群的利用率。当 AM 收到 RM 新分配的一个 Container 后，必须在一定的时间（默认为10min）内在对应的 NM 上启动该 Container，否则RM 会回收该Container。

3. ApplicationMaster

一个 Application 运行在 YARN 之上：主控程序（AM = TL） + 任务程序（Task = TM）

应用程序管理器 ApplicationMaster 负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动 MRAppMaster、监控MRAppMaster 运行状态并在失败时重新启动它等。

整体职责解析：

每个运行在 YARN 内部的 Application 都会启动一个 ApplicationMaster，负责向
ResourceManger 注册 Application 和申请 Container
ApplicationMaster 就是运行在 YARN 集群中的 NodeManager 中，相较于 MRv1，不会对
ResourceManager 造成较大的负担
负责整个应用程序的管理，跟 NodeManager 通信启动或者停止 Task，监控/收集task执行进度结果，或者进行 Task 的容错

注意 ResourceManager，ApplicationMaster，Task 之间的关系

客户端提交 Job 到 ResourceManager，ResourceManager 会为该 Job 启动一个ApplicationMaster 来负责这个 Job 中的所有的 Task 的执行，所以 ResourceManager 负责管理 ApplicationMaster
启动的 ApplicationMaster 专门负责一个 Job 的所有的 Task 的启动，执行，生命周期管理，状态跟踪，容错等等。

4. MRAppMaster

MRAppMaster 就是 MapReduce 的一个 Application 应用程序运行在 YARN 之上的 ApplicationMaster

MRAppMaster 负责管理 MapReduce 作业的生命周期，当客户端提交一个 MapReduce job 到 YARN 的时候，ResourceManager 会指派一个NodeManager 来启动一个 MRAppMaster 主控程序，来主持这个 MapReduce Job 的所有 Task 的执行。

在这里插入图片描述
流程解析：

步骤1：用户向 YARN 中提交应用程序，其中包括 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。
步骤2：ResourceManager 为该应用程序分配第一个 Container，并与对应的 NodeManager 通信，要求它在这个Container 中启动应用程序的ApplicationMaster。
步骤3：ApplicationMaster 首先向 ResourceManager 注册，这样用户可以直接通过
ResourceManager 查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。
步骤4：ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和领取资源。
步骤5：一旦 ApplicationMaster 申请到资源后，便与对应的 NodeManager 通信，要求它启动任务。
步骤6：NodeManager 为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
步骤7：各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当前运行状态。
步骤8：应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己。

5. Scheduler

YARN 的资源调度服务：根据应用程序需要的资源请求以及集群的资源情况，为应用程序分配对应的资源，他不会关心你拿申请到的 Container 资源去做什么。
调度器就是根据容量、队列一些限制条件，将系统中的资源分配给各个正在运行的应用程序，这里有一句话想说，调度器是一个纯调度器，就是它只管资源分配，不参与具体应用程序相关的工作。

YARN 内部有 3 种资源调度策略的实现：FifoScheduler、FairScheduler、CapacityScheduler，其中默认实现为 CapacityScheduler。

FIFO Scheduler：先进先出，不考虑应用程序本身的优先级和资源使用情况
Capacity Scheduler：将资源分成队列，共享集群资源但需要保证队列的最小资源使用需求。（容量调度中也可以设置队列之间的抢占配置）
Fair Scheduler：公平的将资源分给应用，保证应用使用的资源是均衡的。

CapacityScheduler 实现了资源更加细粒度的分配，可以设置多级队列，每个队列都有一定的容量，即对队列设置资源上限和下限，然后对每一级别队列分别再采用合适的调度策略（如 FIFO）进行调度。

6. NodeManager

NodeManager 是 YARN 集群当中真正资源的提供者，是真正执行应用程序的容器的提供者，监控应用程序的资源使用情况（CPU，内存，硬盘，网络），并通过心跳向集群资源调度器 ResourceManager 进行汇报以更新自己的健康状态。同时其也会监督 Container 的生命周期管理，监控每个Container 的资源使用（内存、CPU 等）情况，追踪节点健康状况，管理日志和不同应用程序用到的附属服（auxiliary service）。

整体职责解析：