走进 YARN 资源管理与调度|青训营笔记YARN 概述 YARN 概述：从食堂分配座位场景导入，初识调度系统；介绍调度

YARN 概述

YARN 概述：从食堂分配座位场景导入，初识调度系统；介绍调度系统发展的背景、解决的问题、目标和范型；Hadoop YARN 的设计思想和整体架构。

场景描述

首先考虑如下虚拟场景，如何进行调度在保障就餐公平性的前提下让尽可能多的学生都能够在该餐厅就餐、尽可能多的座位被有效使用？

学校为改善学生生活新建了一所美食餐厅，餐厅座位有限且只能堂食；

各个学院需要缴纳一定管理费用后其学生才能在该餐厅用餐，缴纳费用与分配的座位数成正比；

因餐厅物美价廉、环境干净，来该餐厅就餐的人络绎不绝；

简易分配模型

各个学院:获得座位数
学院学生:按照学院组织餐厅经理:分配餐厅座位
餐厅座位:有序排列放置

保障公平性
- 学院间按照分配座位满足率排序；
- 学院内先来先服务、后来后服务；

保障高效性
- 餐厅经理有很多助手以辅助其派发，助理可以统计就餐信息、学院排序、引导等；
- 餐厅经理做决策，助手异步同步信息；

保障高可用
- 两个备用经理，随时可以工作；

如何满足 “尽可能多”？
- 座位超售：所有学院分配座位大于总座位数
- 学院超用：有座位时学院可以超分配座位
- 座位超发：“允许一个座位坐两个人”
- 鼓励快餐：鼓励大家快速就餐离开

就餐学生有个性化需求
- 同用餐小组必须坐一个桌子
- 同用餐小组必须坐不同桌子
- 用餐小组必须要坐靠窗位置
- 有重要活动同学需靠前就餐

调度系统演进

IT到DT时代的变革，注重数据价值;
数据计算方式的变革，注重计算效率;
企业对外服务需数以万计的硬件资源;
灵活调度、提高利用率是降本增效的关键问题;

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

集群资源管理与调度系统的核心目标是： 设计出更好的资源管理与调度策略，使得整个集群在保障任务SLA的前提下能够实现更高的资源利用率、更快的计算任务完成速度。

严格的多租户间公平、容量保障

调度过程的高吞吐与低延迟

高可靠性与高可用性保障

高可扩展的调度策略

高集群整体物理利用率

满足上层任务的个性化调度需求

任务持续、高效、稳定运行

We want to have all of them… However…

资源管理与调度系统范型

YARN 设计思想

演化背景

离线调度生态介绍

YARN 面临的挑战

公平性：各租户能够公平的拿到资源运行任务
高性能：高调度吞吐、低调度延迟，保障资源快速流转
高可用：集群要具备很强的容错能力
单集群规模提升：原生 YARN 单集群仅支持 5K
高集群资源利用率
高任务运行质量保障

YARN 整体架构

系统架构

上图为 YARN 架构，主要包含两大角色：

Resource Manager
- 整个集群的大脑，负责为应用调度资源，管理应用生命周期；
- 对用户提供接口，包括命令行接口，API， WebUI 接口；
- 可以同时存在多个RM、，同一时间只有一个在工作，RM 之间通过 ZK 选主；

Node Manager
- 为整个集群提供资源, 接受 Container 运行；
- 管理Contianer的运行时生命周期, 包括Localization, 资源隔离, 日志聚合等；

任务运行核心流程

核心模块

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 是最大最小公平算法在多维资源上的具体实现；

旨在使不同用户的“主分享量”最大化的保持公平；

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

资源按照需求递增的顺序进行分配；

用户获取的资源不超过自身需求；

对未满足的用户，等价分享剩余资源；

DRF 调度策略示例

场景：系统有 <9CPU, 18G>，A 每个任务需要 <1CPU，4G>，B 每个任务需要 <3CPU，1G>，对于 A 因为：1/9 < 4/18，所以 A 任务的主资源是内存，B 任务的主资源是 CPU；

数学模型：一定约束条件下的最优化问题，下面 x 代表 A 任务的个数，y 代表 B 任务的个数
- 最大化资源分配 max(x,y)
- 约束条件：
  - （x+3y）<=9(CPU约束);
  - (4x+y)<= 18（内存约束）;
  - 4x/18 == 3y/9（主资源公平约束）;

最终计算得到： x=3,y=2

核心算法说明

R 表示总资源量，有 m 个维度

C 已经使用的资源量

si 用户 i 的“主分享量”

Ui 分配给用户 i 的资源量

选择最小“主分享量”用户 i

Di 用户 i 下一个任务资源需求量

若资源充足
- 更新已使用资源量
- 更新用户 i 的已分配资源量
- 更新用户 i 的“主分享量”

高性能保障

状态机管理

状态机由一组状态（初始状态、中间状态和最终状态）组成，状态机从初始状态开始运行，接收一组特定事件，经过一系列中间状态后，到达最终状态并退出；

每种状态转换由一个四元组表示：转换前状态、转换后状态、事件和回调函数；

YARN 定义了三种状态转换方式如下所示：

事件处理模型

YARN 采用了基于事件驱动的并发模型，具有很强的并发性可提高系统性能。

RM 中所有处理请求都会作为事件进入系统；

AsyncDispatcher 负责传递事件给相应事件调度器--EventHandler；

事件调度器可能将该事件转发给另外一个事件调度器或带有有限状态机的事件处理器；

处理结果也以事件形式输出，新事件会再次被中央异步调度器转发给下一个事件调度器，直至处理完成。

RM 高可用

热备方案：集群中存在一个对外服务的 Active Master 和若干 Standby Master，一旦 Active Master 故障，立即采取一定策略选取某个 Standby Master 转换为 Active Master 正常对外提供服务；

基于共享存储的 HA 解决方案：Active Master 不断将信息写入共享存储系统（ZK）,故障切换时 Standby Master 从共享存储恢复数据，待信息完全同步后切换至 Active Master;

两种切换模式：

手动模式：使用 “yarn rmadmin”命令将现在的 Active Master 切换为 Standby 并选择一个 Standby 切换为 Active Master；

自动模式：使用 ZK 的 ActiveStandbyElector 进行选主操作，ZK 中有一个 /yarn-leader-election/yarn1 的锁节点，所有 RM 在启动时去竞争写一个 Lock 子节点：/yarn-leader-election/yarn1/ActiveBreadCrumb，该节点是临时节点。ZK 保证最终只有一个 RM 能够创建成功，创建成功的为 Active Master;

Client 、 AM、NM 自动重试：切主时各组件基于配置文件中的所有 RM 采用 round-robin 轮询方式不断尝试连接 RM 直到命中 Active Master；

NM 高可用

相关信息存储至 leveldb 数据库；

NM 重启时加载 yarn-nm-recovery 下的 leveldb 数据库；

公司实践

Gang 调度器

为什么要开发 Gang 调度器？

流式作业和训练作业的调度需求与批处理有很大的不同:批处理强调高吞吐,而流式/训练类型作业更强调低延迟和全局视角;

调度缺乏全局视角
单App调度过慢
App间存在资源互锁

Gang 调度器有什么典型特点？

全局视角
- 作业可自定义配置强弱约束;
- 强约束:必须要满足的条件，
- 弱约束:尽量满足的约束;
低调度延迟
- RM维护所有节点状态信息;
- 资源请求同步分配，毫秒级返回;
Gang性资源交付
- 提供All-or-Nothing语义;
- 可满足的请求全部分配，否则返回失败;

Gang 调度流程

强约束阶段：过滤掉不符合条件的节点
弱约束阶段：选择合适的节点分配资源（不排序，时间复杂度 O(n)）
- Quota 平均：分配后节点已使用资源尽可能平均。总请求资源为 V1，总节点数为 N，已用资源为 U，节点目标资源为：S = (V1 + U)/N，遍历所有节点，每个节点分配 S - Un 即可；
- 跳过高 load 节点：优先往低 load 节点调度。满足 load 阈值节点 N1，不满足 N2，优先把 N1 剩余资源分配完，分配后未满足资源量为 V2，每个节点分配 V2/N2;
- 兜底分配