走进 Yarn 资源管理和调度 | 青训营笔记

这是我参与「第四届青训营」笔记创作活动的的第16天，本篇笔记主要是关于第十六次大数据课程《走进 Yarn 资源管理和调度》的课堂笔记

YARN概述

调度系统演进-调度系统解决的问题：

用有限资源解决有限资源无法满足的需求时就需要调度;
调度系统主要解决资源请求和可用资源间的映射(Mapping)问题;

调度系统预达的目标：

严格的多租户间公平、容量保障
调度过程的高吞吐与低延迟
高可靠性与高可用性保障
高可扩展的调度策略
高集群整体物理利用率
满足上层任务的个性化调度需求
任务持续、高效、稳定运行

资源管理与调度系统范型

集中式调度系统： 中心式调度系统融合了资源管理和任务调度，有一个中心式的 JobTracker 负责进行集群资源的合理分配、任务的统一调度、集群计算节点信息的统计维护、任务执行过程中的状态管理等。
两层调度系统： 将资源管理和任务调度解耦。集群资源管理器负责维护集群中的资源信息并将资源分配给具体的任务，任务管理器负责申请资源并将申请到的资源根据用户逻辑进行细分和具体的任务调度。
共享状态调度系统： 是一个半分布式的架构，通过共享集群状态为应用提供全局的资源视图，并采用乐观并发机制进行资源申请和释放，来提高系统的并发度。
分布式调度系统： 分布式调度器之间没有通讯协作，每个分布式调度器根据自己最少的先验知识进行最快的决策，每个调度器单独响应任务，总体的执行计划与资源分配服从统计意义。
混合式调度系统： 设计两条资源请求和任务调度路径，保留两层调度的优点，同时兼顾分布式调度器的优势。对于没有资源偏好且响应要求高的任务采用分布式调度器，对于资源调度质量要求较高的采用集中式资源管理器进行资源分配。

YARN演化背景：

Hadoop 1.0 时代：由分布式存储系统 HDFS 和分布式计算框架 MapReduce(MR v1) 组成，MR v1 存在很多局限：

可扩展性差：JobTracker 兼备资源管理和任务控制，是系统最大的瓶颈；
可靠性差：采用 master/slave 结构，master 存在单点故障问题；
资源利用率低：基于槽位的资源分配模型，各槽位间资源使用差异大；
无法支持多种计算框架：只支持 MR 任务，无法支持其他计算框架；

Hadoop 2.0 时代：解决了 Hadoop 1.0 时代中 HDFS 和 MR 中存在的问题：

YARN(MR v2) 在 MR v1 的基础上发展而来，将资源管理和任务控制解耦，分别由 Resource Manager 和 ApplicationMaster 负责，是一个两层调度系统；
Hadoop YARN(Yet Another Resource Negotiator) 支持多种计算框架的统一资源管理平台；

离线调度生态介绍

用户逻辑层：数据分析任务、模型训练任务等
作业托管层：管理各种类型上层任务
分布式计算引擎层：各种针对不同使用场景的计算引擎，例如：MR、Spark、Flink 等
集群资源管理层：YARN
裸金属层：众多物理节点组成

YARN 整体架构

系统架构

Resource Manager
- 整个集群的大脑，负责为应用调度资源，管理应用生命周期；
- 对用户提供接口，包括命令行接口，API， WebUI 接口；
- 可以同时存在多个RM、，同一时间只有一个在工作，RM 之间通过 ZK 选主；
Node Manager
- 为整个集群提供资源, 接受 Container 运行；
- 管理Contianer的运行时生命周期, 包括Localization, 资源隔离, 日志聚合等； YARN上运行的作业在运行时会访问外部的数据服务，常见的如 HDFS， Kafka 等；在运行结束后由 YARN 负责将日志上传到 HDFS；

任务运行核心流程

Client 获取 ApplicationID，调用 ApplicationClientProtocol #getNewApplication。
RM 返回 GetNewApplicationResponse，其中主要包括：ApplicationID、最大可申请资源以及相关配置。
Client 将任务运行所需的资源上传至HDFS的指定目录下，并初始化AM配置，主要构造 ApplicationSubmissionContext （应用ID、应用名称、所属队列、应用优先级、应用类型、应用尝试次数、运行AM所需要的资源等）和 ContainerLaunchContext（容器运行所需的本地资源、容器持有的安全令牌、应用自有的数据、使用的环境变量、启动容器的命令行等）。
Client 将 AM 提交至 RM，调用 ApplicationClientProtocol #submitApplication。
RM 根据一定的分配策略为 AM 分配container，并与 NM 通信。
NM 启动 AM。
AM 从 HDFS 下载本任务运行所需要的资源并进行初始化工作。
AM 向 RM 注册和申请资源。ApplicationMasterProtocol # registerApplicationMaster，注册信息包括：AM所在节点的主机名、AM的对外RPC服务端口和跟踪应用状态的Web接口；ApplicationMasterProtocol # allocate，相关信息封装在 AllocateRequest中包括：响应ID、申请的资源列表、AM主动释放的容器列表、资源黑名单、应用运行进度。
RM 接受 AM 请求后，按照调度算法分配全部或部分申请的资源给 AM，返回一个 AllocateResponse 对象，其中包括：响应ID、分配的container列表、已完成的container状态列表、状态被更新过的节点列表、资源抢占信息（强制收回部分和可自主调配部分）等。
AM 获取到资源后与对应的 NM 通信以启动 container， ContainerManagementProtocol # startContainers
NM 启动container。
Container 从 HDFS 下载任务运行必要的资源。
Container 在运行过程中与AM通信及时汇报运行情况。
任务运行完成后 AM 向 RM 注销，ApplicationMasterProtocol # finishApplicationMaster()。

YARN核心模块

Resource Manager

整体架构

主要职责

总的来说，RM 负责集群所有资源的统一管理和分配，接收各节点汇报信息并按照一定策略分配给各个任务；

与客户端交互，处理来自客户端的请求
启动和管理 AM，运行失败时自动重试
管理所有 NM，接收 NM 的汇报信息并下达管理指令
资源管理与调度
- 将资源按照一定方式组织起来，例如：资源池
- 将任务按照一定方式组织起来，例如：队列
- 接收来自各个 AM 的资源请求
- 按照一定分配策略将资源分配给 AM

状态机管理

RMApp 状态机

NEW_SAVING: 收到提交的应用程序后，创建 RMAppImpl 对象并将基本信息持久化；
ACCEPTED：调度器接受该应用程序后所处的状态，任务等待被分配资源；
RUNNING：任务成功获取到资源并在节点运行

RMAppAttempt 状态机

SCHEDULED: 通过 Scheduler 合法性检查后所处的状态，开始为该 App 分配资源；
ALLOCATED_SAVING：收到分配的 Container 后，在持久化完成前所处的状态；
ALLOCATED：信息持久化完成后所处的状态；
LAUNCHED：RM 的 ApplicationMasterLauncher 与 NM 通信以启动 AM 时所处的状态；

RMContainer 状态机

RESERVED: 开启资源预留时，当前节点不能满足资源请求时所处的状态；
ALLOCATED：调度器分配一个 Container 给 AM；
ACQUIRED：AM 获取到分配的 Container 后所处的状态；
EXPIRED: AM 获取到 Container 后，若在一定时间内未启动 Container，RM 会强制回收该 Container;

RMNode 状态机

DECOMMSIONED: 节点下线后的状态；
UNHEALTHY：节点处于不健康状态，健康检测脚本异常或磁盘故障；
LOST：超过一定时间（默认 10 分钟）未与 RM 发生心跳后所处的状态； 调度流程： YARN 调度流程由心跳触发：
AM 定期与 RM 保持心跳，并将资源请求记录在 RM 中；
触发时机: 由节点心跳触发针对此节点的调度；
找 Label: 根据节点 Label 找到对应 Lable 下的所有队列；
找队列: 将队列进行 DRF 排序, 找到当前最“饥饿”的队列；
找应用: 将此队列内所有应用按照优先级进行排序(优先级由用户提交时指定), 找到优先级最高的应用, 优先级相同时按DRF 算法排序；
找资源请求: 将此应用内的所有资源请求按照优先级排序(优先级由计算引擎指定), 找到优先级最高的资源请求进行资源分配；

典型调度器对比

Node Manager

整体架构

主要职责

总的来说，NM 是节点代理，从 AM 接受命令（启停 Container）并执行，通过心跳方式向 RM 汇报节点状态并领取命令（清理 Container）。

与 RM 交互
- 心跳汇报节点健康状况和 Container 运行状态；
- 领取 RM 下达的命令；
与 AM 交互
- 启动容器
- 停止容器
- 获取容器状态

状态机管理

Application

INITING: Application 初始化状态，创建工作目录和日志目录；
FINISHING_CONTAINERS_WAIT：调等待回收 Container 所占用的资源所处的状态；
APPLICATION_RESOURCE_CLEANINGUP：Application 所有 Container 占用的资源被回收后所处的状态；

Container

LOCALIZING: 正在从 HDFS 下载依赖的资源；
EXITED_WITH_SUCCESS：Container 运行脚本正常退出执行；
CONTAINER_CLEANUP_AFTER_KILL：Container 被 kill 后所处的状态；

LocalizedResource

DOWNLOADING: 资源处于下载状态；
LOCALIZED：资源下载完成；
FAILED：资源下载失败；

节点健康检查机制

节点健康检测机制是 NM 自带的健康状况诊断机制。通过该机制 NM 可时刻掌握自己健康状况并及时汇报给 RM，RM 根据 NM 健康情况决定是否为其分配新任务。

自定义 Shell
- NodeHealthScriptRunner 服务周期性执行节点健康状况检测脚本；
- 若输出以 “ERROR”开头，节点处于 unhealthy 状态并随心跳上报给 RM，RM 拉黑节点并停止分配新任务；
- 脚本一直执行，一旦节点变为 healthy 状态，RM 会继续为该节点分配新任务；
检测磁盘损坏数目
- LocalDirsHandlerService 服务周期性检测 NM 本地磁盘好坏，一旦发现正常磁盘比例低于一定阈值则节点处于 unhealthy 状态；
- NM 判断磁盘好坏的标准：如果一个目录具有读、写和执行权限，则目录正常；

重要机制

公平性保障

Fair Share 调度策略

什么是 Fair Share 调度策略？

队列配置 minShare 和 maxShare，当队列空闲时按照一定策略将资源分配给其他活跃队列；

为什么需要 Fair Share 调度策略？

保障公平的前提下实现队列间资源共享，提高资源利用率，缓解繁忙队列压力；

两种类型 Fair Share

Steady Fair Share: TotalResource * S.weight
Instantaneous Fair Share:
- 定义
  - 所有队列 Fair Share 之和 <= TotalResource;
  - S.minShare <= Fair Share <= S.maxShare；
- 目标
  - 找到一个 R 使其满足：
  - R * （All S.wieght）<= TotalResource;
  - S.minShare <= R * S.weight <= S.maxShare;
- 结果
  - 若 S.minShare > R * S.weight， Fair Share = S.minShare
  - 若 S.maxShare < R * S.weight，Fair Share = S.maxShare
  - 其他 Fair Share = R * S.weight

Fair Share 计算逻辑

计算 Total Resource
初始化 R 上限 RMax
- 获取所有 non-fixed Schedulable 的 maxShare
- 初始化 R 为 1，每次翻倍
- 直到所有 Schedulable 分完所有资源
通过二分法寻找 R [0,RMax]
- mid = (left + right) / 2.0
- 若 plannedResourceUsed == totalResource，right = mid；
- 若 plannedResourceUsed < totalResource，left = mid；
- 若 plannedResourceUsed > totalResource，right = mid；
计算 Fair Share
- 若 S.minShare > right * S.weight, Fair Share = S.minShare;
- 若 S.maxShare < right * S.weight, Fair Share = S.maxShare;
- 其他情况 Fair Share = right * S.weight

DRF 调度策略

为什么需要 DRF 调度策略？

在保证公平性的前提下进行资源降维，以达到更好的分配效果；

什么是 DRF 调度策略？

DRF 是最大最小公平算法在多维资源上的具体实现；
旨在使不同用户的“主分享量”最大化的保持公平；

最大最小公平算法：最大化最小资源需求的满足度

资源按照需求递增的顺序进行分配；
用户获取的资源不超过自身需求；
对未满足的用户，等价分享剩余资源；