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

Rainbow_Sea
248 阅读6分钟

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

今天是大数据专场基础班的第十六次课，主要内容是走进 YARN 资源管理和调度，主要分为下面四个板块。

一、 YARN 概述

1. 初识调度系统

1.1 初识调度系统–场景导入

  • 学校为改善学生生活新建了一所美食餐厅，餐厅座位有限且只能堂食
  • 各学院需缴纳一定管理费用后学生才能在该餐厅用餐，缴纳费用与分配的座位数成正比
  • 因餐厅物美价廉、环境干净，来该餐厅就餐的人络绎不绝

1.2 初识调度系统–一种简易分配模型

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

image.png

1.3 初识调度系统–优化的分配模型

  • 保障公平性
    • 学院间:低分配座位满足率优先
    • 学院内:先来先服务
  • 保障高效性
    • 配备餐厅助手
    • 用餐小组负责人
  • 保障高可用
    • 配置备用经理

image.png

2. 调度系统演进

2.1 调度系统演进–调度系统发展的背景

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

image.png

2.2 调度系统演进–调度系统解决的问题

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

image.png

2.3 调度系统演进–调度系统预达的目标

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

image.png

3. YARN设计思想

3.1 YARN设计思想–面临挑战

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

4. YARN整体架构

4.1 YARN整体架构–系统架构

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

image.png

4.2 YARN整体架构–-任务运行生命周期核心流程

image.png

二、 核心模块

1. Resource Manager

  • 整体架构
  • 主要职责
  • 状态机管理
  • 调度器分析

1.1 Resource Manager-整体架构

image.png

1.2 Resource Manager -主要职责

  • RM负责集群所有资源的统一管理和分配，接收各节点汇报信息并按照一定策略分配给各个任务
  • 与客户端交互
  • 启动和管理所有AM
  • 管理所有NM
  • 资源管理与调度
    • 组织资源(资源池)
    • 接收资源请求
    • 分配资源

image.png

1.3 Resource Manager状态机管理-RMApp状念机

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

image.png

1.4 Resource Manager状态机管理-RMAppAttempt

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

image.png

1.5 Resource Manager状态机管理- RMContainer

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

image.png

1.6 Resource Manager状态机管理-RMNode

  • DECOMMISSIONED:节点下线后的状态
  • UNHEALTHY:节点处于不健康状态，健康检测脚本异常或磁盘故障
  • LOST:节点超过一定时间(默认10分钟)未与RM发生心跳后所处的状态

image.png

1.7 Resource Manager调度器分析–任务/资源组织

  • 任务按队列组织
  • 节点按Label组织

image.png

1.8 Resource Manager调度器分析–调度流程

  • AM 与 RM心跳: 记录资源请求
  • 触发时机: 节点心跳
  • 找Label: 获取所有队列
  • 找队列: 最“饥饿”队列优先
  • 找任务: 优先级高的任务优先
  • 找资源请求: 优先级高的请求优先

image.png

1.9 Resource Manager调度器分析–典型调度器

image.png

2. Node Manager

  • 整体架构
  • 主要职责
  • 状态机管理
  • 节点健康检测机制

2.1 Node Manager -整体架构

image.png

2.2 Node Manager主要职责

  • NM是节点代理，从AM接受命令(启停Container）并执行，通过心跳方式向RM汇报节点状态并领取命令(清理Container)。
  • 与 RM 交互
    • 心跳汇报节点状态
    • 领取RM下达的命令
  • 与 AM 交互
    • 启动容器
    • 停止容器
    • 获取容器状态

image.png

2.3 Node Manager状态机管理- Application

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

image.png

2.4 Node Manager状态机管理- Container

  • LOCALIZING:正在从 HDFS下载依赖的资源
  • EXITED WITH_SUCCESS: Container运行脚本正常退出执行
  • CONTAINER CLEANUP AFTER_KILL:Container被kill后所处的状态

image.png

2.5 Node Manager状态机管理- LocalizedResource

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

image.png

2.6 Node Manager节点健康检测机制

  • 节点健康检测机制可时刻掌握NM健康状况并及时汇报给RM，RM根据NM是否健康决定是否为其调度新任务
  • 自定义Shell
    • NodeHealthScriptRunner服务周期性执行节点健康状况检测脚本
    • 若输出以"ERROR”开头则不健康
  • 检测磁盘损坏数目
    • 判断磁盘损坏标准:若一个目录具有读、写和执行权限，则目录正常
    • LocaIlDirsHandlerService 服务周期性检测NM本地磁盘好坏，坏盘数超过阈值则不健康

三、 重要机制

1. 调度策略

1.1 调度策略–Fair Share 调度策略背景

  • 为什么需要Fair Share调度策略?
    • 实现队列间资源共享，提高资源利用率
    • 缓解繁忙队列压力
  • 什么是 Fair Share调度策略?
    • 队列空闲时按照一定策略将资源分配给其他活跃队列
  • Fair Share类型
    • Steady Fair Share
    • Instantaneous Fair Share

image.png

1.2 调度策略– Instantaneous Fair Share定义

  • lnstantaneous 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

1.3 调度策略- Instantaneous Fair Share计算逻辑

  • 计算Total Resource
  • 初始化R上限 RMax
    • 获取所有non-fixed Schedulable的maxShare
    • 初始化R为1，每次翻倍
    • 直到所有Schedulable分完所有资源
  • 通过二分法寻找R[O,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

1.4 调度策略–DRF(Dominant Resource Fair)调度策略

  • 为什么需要 DRF 调度策略?
    • 在保证公平性的前提下进行资源降维
  • 什么是DRF调度策略?
    • DRF是最大最小公平算法在多维资源上的具体实现
    • 旨在使不同用户的“主分享量”最大化的保持公平
  • 最大最小公平算法:最大化最小资源需求的满足度
    • 资源按照需求递增顺序分配
    • 获取的资源不超过自身需求
    • 未满足用户等价分享剩余资源

image.png

1.5 调度策略–DRF调度策略计算逻辑

  • R表示总资源量，有m个维度
  • C已经使用的资源量
  • si 用户i的“主分享量”
  • Ui分配给用户i的资源量
  • 选择最小“主分享量”用户i
  • Di用户i下一个任务资源需求量
  • 若资源充足
    • 更新已使用资源量
    • 更新用户i的已分配资源量
    • 更新用户i的“主分享量”

image.png

2. 事件机制

2.1 事件机制–状态机管理

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

image.png

2.2 事件机制–事件处理模型

  • 所有处理请求都会作为事件进入系统
  • AsyncDispatcher负责传递事件给相应事件调度器
  • 事件调度器将事件转发给另一个事件调度器或带有有限状态机的事件处理器
  • 处理结果以事件形式输出，新事件会再次被转发，直至处理完成
  • YARN采用了基于事件驱动的并发模型，具有很强的并发性可提高系统性能

image.png

3. 容错机制--高可用性

  • RM高可用
    • 热备方案:Active Master提供服务、Standby Master作为备节点
    • 基于共享存储的HA解决方案:关键信息写入共享存储系统（ZK)
    • 两种切换模式:
      • 手动模式:“yarn rmadmin”命令手动操作
      • 自动模式:ZK的ActiveStandbyElector进行选主操作，ZK中有一个锁节点，所有RM竞争写一个子节点，ZK保证最终只有一个RM能够创建成功，创建成功的为Active Master
    • Client 、AM、NM自动重试:切主时各组件采用round-robin方式尝试连接RM
  • NM高可用
    • 关键信息存储至leveldb 数据库
    • 重启时从 yarn-nm-recovery 下的leveldb 数据库加载数据

四、 公司实践

1. Gang调度器

1.1 Gang调度器–为什么需要开发Gang调度器?

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

  • 调度缺乏全局视角

  • 单App调度过慢

  • App间存在资源互锁

image.png

1.2 Gang调度器– Gang调度器有什么典型特点?

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

image.png

1.3 Gang调度器– Gang调度器调度流程

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

image.png

2. 反调度器

2.1 反调度器–为什么需要开发反调度器?

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

image.png

2.2 反调度器–反调度流程

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

image.png

2.3 反调度器–反调度器与Gang调度器关系

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

  • 不同点:

    • 发挥作用时机不同
    • 处理机制完全相反

  • 相同点:

    • 反调度器是 Gang调度器的补充
    • 共同保障资源持续合理分配

image.png

3. 单集群规模突破50K

3.1 单集群规模突破50K-为什么需要提升单集群规模?学判跳动

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

image.png

3.2 单集群规模突破50K- RPC瓶颈

  • RPC层:接收请求、处理请求、返回结果
    • RPC处理时间5ms，handler 默认80线程
    • 消费吞吐瓶颈约16K/s，RPC Server Queue易打满

image.png

3.3 单集群规模突破50K - Dispatcher 瓶颈

  • Dispatcher层:将事件传递给对应的事件调度器
    • 生产速率过大，AsyncDispatcher Queue容易 Pending
    • 消费速率过低，NODE_UPDATE 事件处理过慢，2K/s瓶颈

image.png

3.4 单集群规模突破50K - Scheduler瓶颈

  • Scheduler层:真正调度
    • FSLeafQueue单Container 分配延迟高，存在空转

image.png

3.5 单集群规模突破50K-心跳反压机制

  • 心跳动态调整: 将NM节点心跳周期改为根据RM的压力动态调整

image.png

3.6 单集群规模突破50K-多线程调度

  • 多线程调度: 对节点按hashcode 放到对应的Scheduler Queue

image.png

3.7 单集群规模突破50K-其他优化

  • 事件精简: 对内部事件梳理调整,精准修改了一些事件处理逻辑
  • 空转优化: 调度时过滤不需要资源的App，减少空转
  • 内存单位优化: 修改内存单位(int -> long)突破单集群21亿MB限制
  • 切主优化: 通过对切主过程深度优化,将切主时间控制在秒级

引用参考

内容主要参考了邵凯阳老师在「走进 YARN 资源管理和调度」课程里所教授的内容，同时也参考了学员手册里第二节的内容，图片来自于老师的PPT，链接如下：

  1. 【大数据专场 学习资料六】第四届字节跳动青训营 - 掘金 (juejin.cn)
  2. 走进 YARN 资源管理与调度 - 邵凯阳 -ppt.pptx - 飞书文档 (feishu.cn)
avatar
文章
阅读
粉丝