走进 Yarn 资源管理和调度

这是我参与「第四届青训营」笔记创作活动的第十六天

1.Yarn概述

Apache Hadoop YARN是一种新的 Hadoop，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处

1.调度系统演进

1.调度系统发展的背景

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

2.调度系统解决的问题

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

3.调度系统预达的目标

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

4.调度系统范型

集中式：融合资源管理调度和任务控制
两层式：资源管理调度和任务控制解耦
共享状态式：多个调度茄最于乐观并发共享全局资源视图
分布式：多个调度茄基于先验知识进行最快调度决策
混合式：多种类型调度器共存,共同分配

2.Yarn设计思想

1.演化背景

Hadoop 1.0时代:
- 可扩展性差
- 可靠性差
- 资源利用率低
- 无法支持多种计算框架
Hadoop 2.0时代:
- 资源管理和任务控制解耦
- YARN(Yet Another Resource Negotiator)支持多种计算框架的统一资源管理

2.离线生态

3.面临挑战

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

4.系统架构

Resource Manager
- 资源管理和调度
- 任务生命周期管理
- 对外进行交互
Node Manager
- 提供集群资源
- 管理Container运行

2.Yarn核心模块

1.Resource Manager

1.整体架构

2.主要职责

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

与客户端交互
启动和管理所有AM
管理所有NM
资源管理与调度
- 组织资源(资源池)
- 组织任务(队列)
- 接收资源请求
- 分配资源

3.状态机管理

RMApp状态机

NEW SAVING:收到任务后，创建RMApplmpl对象并将基本信息持久化
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 4 RMNode状态机
DECOMMSIONED: 节点下线后的状态
UNHEALTHY：节点处于不健康状态，健康检测脚本异常或磁盘故障
LOST：超过一定时间（默认 10 分钟）未与 RM 发生心跳后所处的状态

4.调度分析

调度流程：YARN调度流程由心跳触发

AM 定期与 RM 保持心跳，并将资源请求记录在 RM 中
触发时机: 由节点心跳触发针对此节点的调度
找 Label: 根据节点 Label 找到对应 Lable 下的所有队列
找队列: 将队列进行 DRF 排序, 找到当前最“饥饿”的队列
找应用: 将此队列内所有应用按照优先级进行排序(优先级由用户提交时指定), 找到优先级最高的应用, 优先级相同时按DRF 算法排序
找资源请求: 将此应用内的所有资源请求按照优先级排序(优先级由计算引擎指定), 找到优先级最高的资源请求进行资源分配

5.典型调度器对比

2.Node Manager

1.整体架构

2.主要职责

NM是节点代理，从AM接受命令(启停Container) 并执行，通过心跳方式向RM汇报节点状态并领取命令(清理Container)

与RM交互
- 心跳汇报节点状态
- 领取RM下达的命令
与AM交互
- 启动容器
- 停止容器
- 获取容器状态

3.状态机管理

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：资源下载失败

4.节点健康检查机制

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

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

3.重要机制

1.公平性保障——调度策略

1.Fair Share 调度策略

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

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

2.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

3.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

4.DRF 调度策略

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

DRF 是最大最小公平算法在多维资源上的具体实现；
旨在使不同用户的“主分享量”最大化的保持公平；最大最小公平算法：最大化最小资源需求的满足度
资源按照需求递增的顺序进行分配；
用户获取的资源不超过自身需求；
对未满足的用户，等价分享剩余资源；例如下面场景：A B C D 四个用户的资源需求分别是 2、2.6、4、5份，现在总共有 10 份资源，首先将所有资源均分，每个用户得到 2.5 份资源。对于 A 用户多分配 0.5 份，继续将这 0.5 份资源平均分配给 B C D，B 用户得到 2.666 份资源。会继续将 B 多分配的 0.066 份资源平均分配给 C 和 D。

5.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

6.核心算法说明

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

C 已经使用的资源量

si 用户 i 的“主分享量”

Ui 分配给用户 i 的资源量

选择最小“主分享量”用户 i
Di 用户 i 下一个任务资源需求量
若资源充足
- 更新已使用资源量
- 更新用户 i 的已分配资源量
- 更新用户 i 的“主分享量”

2.高性能保障——事件机制

1.状态机管理

状态机由一组状态（初始状态、中间状态和最终状态）组成，状态机从初始状态开始运行，接收一组特定事件，经过一系列中间状态后，到达最终状态并退出
每种状态转换由一个四元组表示：转换前状态、转换后状态、事件和回调函数
YARN 定义了三种状态转换方式如下所示

2.事件处理模型

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

RM 中所有处理请求都会作为事件进入系统
AsyncDispatcher 负责传递事件给相应事件调度器--EventHandler
事件调度器可能将该事件转发给另外一个事件调度器或带有有限状态机的事件处理器
处理结果也以事件形式输出，新事件会再次被中央异步调度器转发给下一个事件调度器，直至处理完成

3.高可用保障——容错机制

1.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

2.NM 高可用

相关信息存储至 leveldb 数据库
NM 重启时加载 yarn-nm-recovery 下的 leveldb 数据库

4.公司实践

1.Gang 调度器

1.需要开发Gang调度器的原因

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

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

2.Gang调度器典型特点

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

3.Gang调度器调度流程

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

2.反调度器

1.需要开发反调度器的原因

调度器的调度决策受“时空”限制
- “时”:触发调度时刻
- “空”:触发调度时集群状态
任务运行和集群状态高动态性
- 任务资源使用随流量变化而不断波动
- 调度过程持续进行，集群状态持续变化
需要持续保证最初调度决策的正确性

2.反调度流程

根据AM请求中的强约束，构造强约束集
遍历强约束集选择不再符合强约束条件的节点;√遍历异常节点下的Container，选择需要进行反调度的Container
将反调度Container列表随心跳返回给AM

3.反调度与Gang调度器关系

反调度器是Gang 调度器的 “伴侣”

不同点:
- 发挥作用时机不同
- 处理机制完全相反
相同点:
- 反调度器是Gang调度器的补充
- 共同保障资源持续合理分配

3.单集群规模突破50K

1.需要提升单集群规模的原因

更好的资源池化和资源共享
- 资源池更大，利于资源分时复用
- 资源高效共享，提高集群资源利用率
降低运维成本
- YARN原生单集群仅支持5K节点
- 每多一个集群,运维负担就会加重

2.提升单集群规模的瓶颈

RPC 层: 接收请求、处理请求、返回结果
- RPC 处理时间 5ms，handler 默认 80 线程，消费吞吐约 16K/s，RPC server queue 容易打满
Dispatcher 层：将事件传递给对应的事件调度器
- 生产速率过大，AsyncDispatcher queue 容易 pending
- 消费速率过低，Scheduler 的 NODE_UPDATE 事件处理过慢
Scheduler 层：真正调度
- FSLeafQueue 分配单 Container 延迟太高，存在空转

4.心跳反压机制

将 NM 节点的心跳机制改为根据 RM 的压力动态调整，当事件池中的事件超过阈值时调大心跳周期，当事件池中的事件小于阈值时调小心跳周期

多线程调度：收到调度事件后，对节点按 hashcode 放到对应的 scheduler queue 即返回
事件精简：对 YARN 内部事件梳理调整, 精准修改了一些事件处理逻辑
空转优化：调度时过滤不需要资源的 App，减少空转
内存单位优化：修改内存单位 (int->long) 突破单个集群 21亿 MB 限制
切主优化：通过对切主过程进行深度优化, 将切主时间控制在秒级

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

走进 Yarn 资源管理和调度

1.Yarn概述

1.调度系统演进

1.调度系统发展的背景

2.调度系统解决的问题

3.调度系统预达的目标

4.调度系统范型

2.Yarn设计思想

1.演化背景

2.离线生态

3.面临挑战

4.系统架构

2.Yarn核心模块

1.Resource Manager

1.整体架构

2.主要职责

3.状态机管理

4.调度分析

5.典型调度器对比

2.Node Manager

1.整体架构

2.主要职责

3.状态机管理

4.节点健康检查机制

3.重要机制

1.公平性保障——调度策略

1.Fair Share 调度策略

2.Fair Share两种类型

3.Fair Share 计算逻辑

4.DRF 调度策略

5.DRF 调度策略示例

6.核心算法说明

2.高性能保障——事件机制

1.状态机管理

2.事件处理模型

3.高可用保障——容错机制

1.RM 高可用

2.NM 高可用

4.公司实践

1.Gang 调度器

1.需要开发Gang调度器的原因

2.Gang调度器典型特点

3.Gang调度器调度流程

2.反调度器

1.需要开发反调度器的原因

2.反调度流程

3.反调度与Gang调度器关系

3.单集群规模突破50K

1.需要提升单集群规模的原因

2.提升单集群规模的瓶颈

4.心跳反压机制