这是我参与「第四届青训营」笔记创作活动的的第16天
01.YARN概述
1.1 初识调度系统-场景导入
◆学校为改善学生生活新建了一所美食餐厅，餐厅座位有限且只能堂食;
◆各学院需缴纳一定管理费用后学生才能在该餐厅用餐，缴纳费用与分配的座位数成正比;
◆因餐厅物美价廉、环境干净，来该餐厅就餐的人络绎不绝;
如何进行高效座位分配在保障就餐公平性的前提下让尽可能多的学生都能够及时就餐、尽可能多的座位被有效使用?
1.1 初识调度系统一一种简易分配模型
■ 各个学院:获得座位数
■ 学院学生:按照学院组织
■ 餐厅经理:分配餐厅座位
■ 餐厅座位:有序排列放置
这种分配方式是否高效? 是否公平?
1.1 初识调度系统 - 优化的分配模型
■ 保障公平性
1）学院间:低分配座位满足率优先
2）学院内:先来先服务
■ 保障高效性
1） 配备餐厅助手
2）用餐小组负责人
■ 保障高可用
1）配置备用经理
1.1 初识调度系统-优化的分配模型
■ 如何满足尽可能多”?
1）座位超售:分配座位大于总座位数
2）学院超用:学院可以超分配座位
3）座位超发: “一个座位坐两个人”
4）鼓励快餐:鼓励快速就餐离开
■ 如何满足就餐学生个性化需求?
1）用餐小组必须坐一一个桌子
2）用餐小组必须坐不同桌子
3）用餐小组必须靠窗位置坐
4）有重要活动同学需靠前就餐
1.1 调度系统演进 - 调度系统发展的背景
1）IT到DT时代的变革，注重数据价值;
2）数据计算方式的变革，注重计算效率;
3）企业对外服务需数以万计的硬件资源;
4）灵活调度、提高利用率是降本增效的关键问题;
1.2 调度系统演进 一 调度系统解决的问题
1）用有限资源解决有限资源无法满足的需求时就需要调度;
2）调度系统主要解决资源请求和可用资源间的映射(Mapping)问题;
1.2 调度系统演进一调度系统预达的目标
1）严格的多租户间公平、容量保障
2）调度过程的高吞吐与低延迟
3）高可靠性与高可用性保障
4）高可扩展的调度策略
5）高集群整体物理利用率
6）满足.上层任务的个性化调度需求
7）任务持续、高效、稳定运行
8）We want to have all of them ... However...
1.2 调度系统演进 - 调度系统范型
1.3 YARN设计思想 - 演化背景
● Hadoop 1.0时代:
- 可扩展性差
- 可靠性差
- 资源利用率低
- 无法支持多种计算框架
● Hadoop 2.0时代:
-
资源管理和任务控制解耦
-
YARN
(Yet Another Resource Negotiator)支持多种计算框架的统一资源管理平台
1.3 YARN设计思想-离线生态
1.3 YARN设计思想 - 面临挑战
◆ 公平性:各租户能够公平的拿到资源运行任务
◆ 高性能:高调度吞吐、低调度延迟，保障资源快速流转
◆ 高可用:集群要具备很强的容错能力
◆ 大规模:单集群规模提升(原生YARN 5K)
◆ 高集群资源利用率
◆ 高任务运行质量保障
1.4 YARN整体架构 一 系统架构
■ Resource Manager
-
资源管理和调度
-
任务生命周期管理
-
对外进行交互
■ Node Manager
-
提供集群资源
-
管理Container运行
1.4 YARN整体架构任务运行生命周期核心流程
02.YARN核心模块
Resource Manager
◆ 整体架构 ◆ 主要职责 ◆ 状态机管理 ◆ 调度器分析
Node Manager
◆ 整体架构 ◆ 主要职责 ◆ 状态机管理 ◆ 节点健康检测机制
2.1 Resource Manager - 整体架构
2.1 Resource Manager - 主要职责
RM负责集群所有资源的统一管理和分配， 接收各节点汇报信息并按照一定策略分配给各个任务。
➢与客户端交互
➢启动和管理所有AM
➢管理所有NM
➢资源管理与调度
1）组织资源(资源池)
2）组织任务(队列)
3）接收资源请求
4）分配资源
2.1 Resource Manager状态机管理 一 RMApp状态机
NEW_ SAVING: 收到任务后，创建RMApplmpl对象并将基本信息持久化;
ACCEPTED:调度器接受该任务后所处的状态，任务等待被分配资源;
RUNNING:任务成功获取到资源并在节点运行;
2.1 Resource Manager 状态机管理- RMAppAttempt
SCHEDULED:通过合法性检查后所处的状态，开始为该任务分配资源;
ALLOCATED SAVING:收到分配的Container后，在持久化完成前所处的状态;
ALL OCATED:信息持久化完成后所处的状态;
LAUNCHED:RM的ApplicationMasterL auncher与NM通信以启动AM时所处的状态;
2.1 Resource Manager 状态机管理 - RMContainer
RESERVED:开启资源预留时，当前节点不能满足资源请求时所处的状态;
ALLOCATED:调度器分配一-个Container给AM
ACQUIRED:Container 被AM领走后的状态;
EXPIRED: AM获取到Container后，若在一定时间内未启动Container，RM会强制回收该Container;
2.1 Resource Manager状态机管理 - RMNode
DECOMMISSIONED:节点下线后的状态;
UNHEALTHY:节点处于不健康状态，健康检测脚本异常或磁盘故障;
LOST:节点超过一定时间( 默认10分钟)未与RM发生心跳后所处的状态;
2.1 Resource Manager调度器分析-任务/资源组织
1）任务按队列组织
2）节点按Label组织
2.1 Resource Manager调度器分析一调度流程
1）AM与RM心跳:记录资源请求
2）触发时机:节点心跳
3）找Label:获取所有队列
4）找队列:最 “饥饿” 队列优先
5）找任务:优先级高的任务优先
2.1 Resource Manager调度器分析 - 典型调度器
2.2 Node Manager - 整体架构
2.2 Node Manager主要职责
NM是节点代理，从AM接受命令( 启停Container)并执行，通过心跳方式向RM汇报 节点状态并领取命令( 清理Container)
➢ 与RM交互
1）心跳汇报节点状态
2）领取RM下达的命令
➢与AM交互
1）启动容器 2）停止容器 3）获取容器状态
2.2 Node Manager状态机管理- Application
INITING: Application初始化状态，创建工作目录和日志目录;
FINISHING_ CONTAINERS WAIT:调等待回收Container所占用的资源所处的状态;
APPLICATION_ RESOURCE_ CL EANINGUP:Application所有Container占用的资源被回收后所处的状态;
2.2 Node Manager状态机管理- Container
LOCALIZING:正在从HDFS下载依赖的资源;
EXITED_ WITH SUCCESS: Container 运行脚本正常退出执行;
CONTAINER_ CL .EANUP AFTER_ KILL:Container被kill 后所处的状态
2.2 Nоdе Маnаgеr状态机管理 - LосаlіzеdRеѕоurсе
DOWNLOADING:资源处于下载状态;
LOCALIZED:资源下载完成;
FAILED:资源下载失败;
2.2 Node Manager节点健康检测机制
节点健康检测机制可时刻掌握NM健康状况并及时汇报给RM，RM根据NM是否健康决定是 否为其调度新任务。
➢自定义Shell
1）NodeHealthScriptRunner服务周期性执行节点健康状况检测脚本;
2）若输出以“ ERROR”开头则不健康;
➢检测磁盘损坏数目
1）判断磁盘损坏标准:若-一个目录具有读、写和执行权限，则目录正常;
2）LocalDirsHandlerService服务周期性检测NM本地磁盘好坏，坏盘数超过阈值则不健康;
03.重要机制
公平性保障
◆ 为什么需要Fair Share调度策略?
◆ Fair Share调度策略原理
◆ 为什么需要DRF调度策略?
◆ DRF调度策略原理
高性能保障
◆高性能对调度的重要性
◆状态机管理
◆事件处理模型
高可用保障
◆ 高可用对调度的重要性
◆ RM高可用
◆ NM高可用
3.1 调度策略- Fair Share调度策略背景
为什么需要Fair Share调度策略?
1）实现队列间资源共享，提高资源利用率;
2）缓解繁忙队列压力;
什么是Fair Share调度策略?
1）队列空闲时按照一定策略将资源分配给其他活跃队列;
Fair Share类型
1） Steady Fair Share
2） Instantaneous Fair Share
3.1调度策略- Instantaneous Fair Share定义
Instantaneous Fair Share T
1）定义
（1）所有队列 Fair Share ZfA <= TotalResource;
（2）S.minShare <= Fair Share <= S.maxShare;
2）目标
（1）找到一个R使其满足；
（2）R*( All S.wieght) <= TotalResource;
（3）S.minShare <= R * S.weight <= S.maxShare;
3）结果
（1）若 S.minShare> R * S.weight, Fair Share = S.minShare
（2）若 S.maxShare < R * S.weight, Fair Share = S.maxShare
（3）其他 Fair Share- R * S.weight
3.1调度策略 - Instantaneous Fair Share计算逻辑
➢计算Total Resource
➢初始化R上限RMax
1）获取所有non-fixed Schedulable的maxShare
2）初始化R为1，每次翻倍
3）直到所有Schedulable分完所有资源
➢ 通过二分法寻找R [O,RMax]
1） mid= (left + right) / 2.0
2）若plannedResourceUsed == totalResource, right = mid;
3）若plannedResourceUsed < totalResource, left = mid;
4）若plannedResourceUsed > totalResource, right = mid;
➢计算Fair Share
1）若S.minShare > right * S.weight, Fair Share = S.minShare;
2）若S.maxShare < right * S.weight, Fair Share = S.maxShare;
3）其他情况Fair Share = right * S.weight
有了Fair Share后就可以基于此进行排序和抢占操作
3.1调度策略 - DRF(Dominant Resource Fair)调度策略
➢ 为什么需要DRF调度策略?
1）在保证公平性的前提下进行资源降维;
➢什么是DRF调度策略?
1）DRF是最大最小公平算法在多维资源上的具体实现;
2）旨在使不同用户的“主分享量”最大化的保持公平;
➢最大最小公平算法:最大化最小资源需求的满足度
1）资源按照需求递增顺序分配;
2）获取的资源不超过自身需求;
3）未满足用户等价分享剩余资源;
3.1调度策略 - DRF调度策略描述
DRF调度策略示例 ● 场景:系统有<9CPU, 18G>，A每个任务需要<1CPU, 4G>，B每个任务需要<3CPU，1G>，对于A因为: 1/9 < 4/18，所以A任务的主资源是内存，B任务的主资源是CPU;
● 数学模型:一定约束条件下的最优化问题，下面X代表A任务的个数，y代表B任务的个数
1）最大化资源分配max(x,y) 2）约束条件: （1）(x+3y) <= 9 (CPU约束); （2）(4x+y) <= 18 (内存约束) ; （3） 4x/18== 3y/9 (主资源公平约束) ;
● 最终计算得到: x=3， y=2
3.1 调度策略 - DRF调度策略计算逻辑
R表示总资源量，有m个维度
C已经使用的资源量
si用户i的“主分享量
Ui分配给用户i的资源量
● 选择最小 “主分享量” 用户i
● Di用户i下一个任务资源需求量
● 若资源充足
● 更新已使用资源量
● 更新用户i的已分配资源量
● 更新用户i的“主分享量”
3.2事件机制 - 状态机管理
1）状态机由一组状态(初始状态、中间状态和最终状态)组成，状态机从初始状态开始运行，接收一组特定事件，经过一系列中间状态后，到达最终状态并退出;
2）每种状态转换由一个四元组表示:转换前状态、转换后状态事件和回调函数;
3）YARN 定义了三种状态转换方式如下所示:
3.2 事件机制 一 事件处理模型
1）所有处理请求都会作为事件进入系统;
2）AsyncDispatcher负责传递事件给相应事件调度器;
3）事件调度器将事件转发给另一个事件调度器或带有有限状态机的事件处理器;
4）处理结果以事件形式输出，新事件会再次被转发，直至处理完成;
YARN采用了基于事件驱动的并发模型，具有很强的并发性可提高系统性能。
3.3 容错机制 -- 高可用性
➢RM高可用
1）热备方案: Active Master提供服务、Standby Master作为备节点;
2）基于共享存储的HA解决方案:关键信息写入共享存储系统(ZK) ;
3）两种切换模式:
（1）手动模式:“ yarn rmadmin “ 命令手动操作;
（2）自动模式: ZK的ActiveStandbyElector进行选主操作，ZK中有一个锁节点，所有RM竞争写一一个子节点，ZK保证最终只有一一个RM能够创建成功，创建成功的为Active Master;
4）Client 、AM、NM自动重试:切主时各组件采用round-robin方式尝试连接RM ;
NM高可用
1）关键信息存储至leveldb数据库;
2）重启时从yarn-nm-recovery下的leveldb数据库加载数据;
04.公司实践
Gang调度器 ◆ 为什么需要开发Gang调度器?
◆Gang调度器有什么典型特征?
◆Gang调度器调度流程
◆使用场景
反调度器
◆ 为什么需要开发反调度器?
◆ 反调度器调度流程
◆反调度器与Gang调度器间的关系
◆使用场景
单集群规模50K
◆为什么要提升单集群规模?
◆提升单集群规模有哪些瓶颈点?
◆如何解决这些瓶颈点?
◆使用场景
4.1 Gang调度器一什么需要开Gang 调度器?
流式作:业和训练作业的调度需求与批处理有很大的不同:批处理强调高吞吐，而流式/训练类型作业更强调低延迟和全局视角;
1）调度缺乏全局视角
2）单App调度过慢
3）App间存在资源互锁
4.1 Gang调度器-Gang调度器在么典型特点?
➢全局视角
1）作业可自定义配置强弱约束;
2）强约束:必须要满足的条件，
3）弱约束:尽量满足的约束，
➢低调度延迟
1）RM维护所有节点状态信息;
2）资源请求同步分配，毫秒级返回;
➢Gang性资源交付
1）提供All-or-Nothing语义;
2）可满足的请求全部分配，否则返回失败;
4.1 Gang调度器-Gang 调度器调变流程
➢强约束阶段:过滤掉不符合条件的节点
➢弱约束阶段:选择合适的节点分配资源(不排序，时间复杂度O(n))
1）Quota 平均:分配后节点已使用资源尽可能平均
（1）总请求资源为V1,总节点数为N,已用资源为U,节点目标资源为: S= (V1 + U)/N，遍历所有节点，每个节点分配S-Un即可;
2）跳过高load节点:优先往低load节点调度
（1）满足load阈值节点N1,不满足N2，优先把N1剩余资源分配完，分配后未满足资源量为V2,每个节点分配V2/N2;
➢兜底分配
4.1 Gang调度器一字节内部使用场景
1）节点规模1OW+ 2）应用规模7W+
4.2 反调度器一为什么需要开发反调度器?
➢调度器的调度决策受“时空”限制
1）“时”:触发调度时刻;
2）空”:触发调度时集群状态;
➢任务运行和集群状态高动态性
1）任务资源使用随流量变化而不断波动;
2）调度过程持续进行，集群状态持续变化;
➢需要持续保证最初调度决策的正确性
4.2反调度器一反调度流程
1）根据AM请求中的强约束，构造强约束集;
2）遍历强约束集选择不再符合强约束条件的节点;
3）遍历异常节 点下的Container,选择需要进行反调度的Container;
4）将反调度Container列表随心跳返回给AM;
4.2反调度器-反调度器与Gang调度器关系
反调度器是Gang调度器的“伴侣”!
● 不同点:
1）发挥作用时机不同
2）处理机制完全相反
● 相同点:
1）反调度器是Gang调度器的补充
2）共同保障资源持续合理分配;
4.2反调度器 一 字节内部使用场景
▪️ 应用规模7W+
4.3 单集群规模突破50K-为什么要提升单集群规模?
➢更好的资源池化和资源共享
1）资源池更大，利于资源分时复用;
2）资源高效共享，提高集群资源利用率;
➢降低运维成本
1）YARN 原生单集群仅支持5K节点;
2）每多一个集群，运维负担就会加重;
4.3 单集群规模突破50K一RPC瓶颈
➢RPC层:接收请求天返回结果
1）RPC 处理时间5ms，handler 默认80线程;
2）消费吞吐瓶颈约16K/s, RPC Server Queue易打满;
4.3 单集群规模突破50K - Dispatcher瓶颈
➢Dispatcher 层，将事不应的事件调度器
1）生产速率过大， AsyncDispatcher Queue容易Pending
2）消费速率过低，NODE_ UPDATE事件处理过慢，2K/s 瓶颈
4.3单集群规模突破50K - Scheduler瓶颈
Scheduler层：真正调度
1）FSLeafQueue 单 Container 分配延迟高，存在空转
4.3单集群规模突破50K - 心跳反压机制
心跳动态调整:将NM节点心跳周期改为根据RM的压力动态调整
4.3单集群规模突破50K - 多线程调度
多线程调度:对节点按hashcode放到对应的Scheduler Queue
4.3单集群规模突破50K - 其他优化
1）事件精简:对内部事件梳理调整，精准修改了一些事件处理逻辑
2）空转优化:调度时过滤不需要资源的App，减少空转
3）内存单位优化:修改内存单位(int -> long)突破单集群21亿MB限制
4）切主优化:通过对切主过程深度优化，将切主时间控制在秒级
4.3 反调度器一字节内部使用场景
1）50K以上集群5+
