一、Yarn 产生的背景
Hadoop2 之前是由 HDFS 和 MR 组成的,HDFS 负责存储,MR 负责计算。
一)MRv1 的问题
- 耦合度高:MR 中的 jobTracker 同时负责资源管理和作业控制两个功能,互相制约。
- 可靠性差:管理节点是单机的,有单点故障的问题。
- 资源利用率低:基于 slot 的资源分配模型。机器会将资源划分成若干相同大小的 slot,并划定哪些是 map slot、哪些是 reduce slot。
- 无法支持多种计算框架:限定了只能用于 MapReduce 程序。
二)Yarn 的诞生
由于之前 Hadoop 资源调度的种种问题,新的资源调度框架产生了 —— YARN(Yet Another Resource Negotiator)。
它是一个通用资源管理系统,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
二、Yarn 的基本架构
一)Yarn 三大组件
- ResourceManager
- Nodemanager
- ApplicationMaster
Yarn依然是Master/Slave的结构:
- 在资源架构层面:RM 是 master、NM 是 slave
- 在应用运行期间:AM 是 master、container 是 slave
1、ResourceManager
ResourceManager 主要由两个组件构成:
调度器( Scheduler)和应用程序管理器(Applications Manager,ASM)。
- 调度器(Scheduler):
- 根据容量、队列等限制条件(如每个队列分配一定的资源,最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序。
- 应用程序管理器(Applications Manager):
- 负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动等。
2、NodeManager
NodeManager 是每个节点上的资源和任务管理器。
- 定时地向 RM 汇报本节点上的资源使用情况和各个 Container 的运行状态;
- 接收并处理来自 AM 的 Container启动/停止等各种请求。
3、ApplicationMaster
ApplicationMaster 是一个任务最先启动的容器,用于管理当前任务的调度。
- 与 RM 调度器协商以获取资源(用 Container 表示);
- 将得到的任务进一步分配给内部的任务;
- 与NM 通信以启动 / 停止任务;
- 监控所有任务运行状态,并在任务运行失败时重新为任务申请资源以重启任务。
4、Container
不属于 Yarn 三大组件,但是 yarn 中资源的抽象。
- 封装 NM 上的资源(hadoop2 仅支持 cpu 和内存,hadoop3 扩展网络、硬盘、GPU 等资源);
- 不同于静态的 slot,container 可以根据需要动态划分。
二)Yarn 通信协议
通信协议共有 5 种如下图所示:
- 分布式环境下,需要涉及跨机器跨网络通信,YARN底层使用RPC协议实现通信。
- RPC是远程过程调用(Remote Procedure Call)的缩写形式。基于RPC进行远程调用就像本地调用一样。
- 在RPC协议中,通信双方有一端是Client,另一端为Server,且Client总是主动连接 Server 的。因此,YARN实际 上采用的是拉式(pull-based) 通信模型。
三、Yarn 工作流程
- client 向 YARN 中提交应用程序,其中包括 AM 程序、启动 AM 的命令、用户程序等。
- RM 为该应用程序分配第一个 Container,并与对应的 NM 通信,要求它在这个 Container中启动应用程序的 AM。
- AM 首先向 RM 注册,这样用户可以直接通过 RM 查看应用程序的运行状态,然后它将为各个任务申请资源,并监控它的运行状态,直到运行结束,即重复步骤4~7。
- AM 通过 RPC 协议向 RM 申请和领取资源。
- —旦 AM 申请到资源后,便与对应的 NM 通信,要求它启动任务。
- NM 为任务设置好运行环境(包括环境变量、JAR 包、二进制程序等)后,将任务启动命令写到 一个脚本中,并通过运行该脚本启动任务。
- 各个任务通过 RPC 协议向 AM 汇报自己的状态和进度,以让 AM 随时掌握各个任务的运行状态,从而可以在任务失政时重新启动任务。在应用程序运行过程中,用户可随时通过 RPC 向 AM 查询应用程序的当前运行状态。
- 应用程序运行完成后,AM 向 RM 注销并关闭自己。