写点什么

快手超大规模集群调度优化实践

  • 2021-03-11
  • 本文字数:4366 字

    阅读完需:约 14 分钟

快手超大规模集群调度优化实践

随着公司业务的快速发展,离线计算集群规模和提交的作业量持续增长,如何支撑超大规模集群,如何满足不同场景的调度需求成为必须要解决的问题。基于以上问题,快手大数据团队基于 YARN 做了大量的定制和优化,支撑了不同场景下的资源调度需求。

今天的介绍会围绕下面四点展开:

  • 调度相关背景及快手数据规模与场景

  • 快手调度器 Kwai scheduler 介绍

  • 多调度场景优化介绍

  • 其他工作 &未来规划

快手数据规模场景

1. 快手数据规模

目前快手离线计算单集群数万台机器,每日处理数百 P 数据量,百万级别作业,对大数据存储,计算,调度有非常大的挑战。首先介绍下快手大数据架构体系技术栈。

2. 快手大数据体系架构介绍


快手大数据架构底层采用 hdfs/hbase 构建数据存储层,用于支撑海量数据的存储;上层是 YARN 资源调度层,实现百万级别的作业和任务调度;再上层是各种计算引擎构成的执行层,如 Flink、MR、SPARK,PRESTO,TensorFlow 等计算框架用于执行业务的计算任务,最上层属于应用层如 FLink 作业托管平台,机器学习平台,以及 SQL 提交平台,面向用户提供服务。本次分享的 YARN 属于资源调度层,用于把计算引擎的 Task 快速调度到合适的机器上。

3. YARN 资源调度系统介绍

YARN 背景介绍:


YARN 是 Apache Hadoop 旗下的顶级项目,Hadoop 2.0 发布时引入,主要用于解决 hadoop1.0 面临的集群调度性能和扩展性问题。通过把集群资源管理和作业资源管理拆分成 ResourceManager 和 ApplicationMaster 两个组件,实现调度架构从单级架构向二级架构的转变,提升了集群性能。YARN 专注于集群资源管理和调度,包含 ResourceManager 和 NodeManager 两个核心组件;ResourceManager 负责集群资源管理和分配;NodeManager 在每台机器上部署,负责管理所在机器上资源。


YARN 调度器演进过程:


原生 YARN 在调度过程中,先选择一个节点,并对队列进行排序,递归从 root 队列找到最优的叶子队列,再对叶子队列中运行的 app 进行排序,选出 app 在这个节点上调度资源。随着集群规模增长和队列数目的增加,调度耗时越来越长,调度吞吐成为制约集群规模的主要瓶颈。为提升调度吞吐,调度器的发展经历了三个阶段:第一阶段通过心跳触发调度过程,实现比较简单,但心跳处理逻辑和调度逻辑在同一个线程,调度和心跳处理逻辑会相互影响。第二阶段将调度逻辑剥离到单独的线程以降低调度和心跳逻辑耦合性,从而提升了调度性能;但调度逻辑和心跳处理共享一把大锁,并且调度过程中对队列排序占据大量时间,整体性能提升有限。第三阶段引入全局调度器的概念,可以并发对队列资源进行调度,最终通过统一的 commit 过程保证调度结果一致性。多线程并发调度可以提升调度性能,但没有解决调度过程中排序耗时过多问题,并且引入的多线程调度,会损害调度结果的公平性。


快手基于 fair scheduler 单线程调度版本,不断优化单线程调度的性能,但由于单线程调度的局限性,在集群节点接近万台规模时,集群性能出现瓶颈;上线自研的 kwai scheduler 调度器后,在集群调度性能上有极大的提升,目前单集群规模已达数万台,同时在调度策略方面,支持可插拔的调度架构,方便扩展新的调度策略。

Kwai scheduler 调度器介绍

kwai scheduler 主要用于解决调度性能问题以及调度策略扩展性问题。性能方面,传统的调度器一次只能调度一个 task,并且在调度过程中需要对所有队列以及 APP 进行排序,有很大的资源开销;kwai scheduler 采用多线程并发批量调度模式,一轮可以调度数十万个 task。在调度策略方面,传统的调度器先选择节点再选择 APP,难以扩充新调度策略。kwai scheduler 先选择 APP 再选择节点,从而 APP 可以看到所有节点信息,通过对节点进行过滤与打分排序,可以针对不同场景扩展不同的调度策略。

1. 基于集群状态做全局批量调度


Kwai scheduler 整体架构如上图所示,ResouceManager 中 RPC 层和事件处理层基本保持不变,主要改动点是将调度逻辑做一个整体的剥离替换原先的 fair scheduler 调度。每次调度过程中拉取集群状态做镜像,基于集群镜像并发批量调度,调度完成后,将调度结果推送回去。App 可以通过原有的心跳接口获取调度 container。

2. Kwai scheduler 调度流程


Kwai scheduler 基于集群镜像(节点的资源使用情况;队列的最小资源和最大资源量,以及当前资源使用量,APP 资源使用量和资源需求量等)进行资源的预分配,计算出每个 APP 可以在这一轮调度中分配多少资源。APP 根据预先分配到的资源量,并发去竞争节点上的空闲资源,如果竞争成功,完成 APP 的资源调度过程。


APP 资源调度过程中,可以根据不同场景为 APP 配置不同的调度策略,根据调度策略过滤节点并计算每个节点分数,选出分数最高节点尝试进行资源分配。调度过程中基本都是 CPU 密集操作,避免了锁的干扰(不同 APP 竞争节点资源时有轻量的自旋锁),有非常高的性能。并且不同的 APP 可以多线程并发调度,具备很好的扩展性。

3. Kwai scheduler 调度策略


Kwai scheduler 调度策略主要实现 filter 和 score 接口。filter 接口用于过滤节点,score 根据节点信息,为节点进行打分,然后选出最优节点进行调度。比如 APP task 打散策略,根据每个节点分配的 APP 资源量,对节点进行打分,节点上分配的 APP 资源量越多,节点分数越低,从而把 APP 的 task 在集群范围内打散到不同的节点。

4. Kwai scheduler 调度线上效果

Kwai scheduler 上线后,支撑单集群数万台机器,1 万+作业同时运行,每天调度吞吐量峰值 5w/s+,资源分配率 93%+,同时支持不同的调度场景。

多调度场景优化

1. 离线 ETL 场景

离线场景下如何保障核心作业的 SLA 是比较核心的问题。在快手,核心作业和普通作业在同一个队列中,通过完善作业分级保障能力和异常节点规避能力,保障核心作业的 SLA。


离线 ETL 场景中经常会遇到以下情况以及相应的优化方案:


① 其他队列作业大量占据资源不释放

通过优化队列间资源抢占来解决这个问题。为防止抢占影响过大,默认情况下只有高优先级核心作业触发抢占,并且会限制每轮抢占的最大资源量。抢占过程中根据作业优先级,饥饿等待时间等条件动态计算每个队列可以抢占的资源量,从而把资源倾斜给优先级更高,饥饿等待时间更长的作业。


② 队列内低优先级作业占据大量资源不释放

在生产场景下如果低优先级作业占用大量资源不释放,导致优先级比较高的任务无法获取到足够资源,从而导致产出延迟。为解决这个问题提出基于虚拟队列来保障高优先级作业产出。所谓虚拟队列,是在物理队列下,按照一定逻辑规则(比如优先级)抽象出的逻辑队列。每个虚拟队列有一定的资源配额,并且会触发物理队列内部的抢占,从而解决上面的问题。


③ 低优先级作业占据 app solt 不释放

为方便 AppSlot 资源的管理,抽象出 minApp 概念,如果 App 启动时,队列 running App 小于 minApp,将会立刻启动 App,不会受限于父队列的 maxRunningApp,这样在队列层面保障有可预期的 app slot。但同样存在一个问题,队列内部低优先级作业占据大量 AppSlot 不释放,导致高优先级作业启动延迟。为此提出了 App Slot 抢占功能。如下图所示,如果发现高优先级作业(P0)长时间 pending 不能启动,扫描队列内 runningApp,选择低优先级作业进入睡眠模式(不再调度新 task,极端情况下回收 task)从而释放出 slot 资源,保障高优先级作业能及时启动。


④ 回溯作业影响生产作业

回溯作业的特点在于大量提交多个作业,如果不加控制可能会影响生产作业的产出。主要方案是限制回溯作业最大资源量和最大运行 APP 数目,将影响控制在一定的范围以内。但是限制最大资源量和运行数目导致大量回溯作业在 yarn 处于 pending 状态,对 yarn 有比较大的压力,通过与上游调度系统打通,反压上层工作流调度系统,阻止新提交的回溯作业,从而减轻了 YARN 负载。对于已经提交到 yarn 上的作业,会限制每个队列最大 pending app 个数,从而保障总体 pending app 数目可控。


⑤ 高优先级作业大块资源请求不能及时满足

原有的 Reserve 机制中,调度器可以 reserve 一批节点,不再调度新 task,等待节点上自然释放资源。如果被 reserve 节点资源长时间不释放,如何处理?针对这个场景开发了 reserve 抢占功能,用于抢占 reserve 节点上的低优先级的 container,从而保障节点上有足够的空闲资源启动高优先级作业。


⑥ 规避异常节点,避免核心作业长尾

通过采集节点物理指标,task 失败率,task 运行速度,以及 shuffle 失败率等,将此节点标记为异常节点,不再调度新 Task。从而尽量减少异常节点的影响范围,规避其导致的 Task 长尾,失败问题。

2. Adhoc 即时查询场景

AdHoc 场景主要着力于提升每个用户的查询体验。


通过虚拟队列技术,从 user 维度来划分虚拟队列,实现基于 user 公平的资源的分配,配合基于 user 的资源抢占,从而避免大量资源被某一个用户占用,导致其他用户长时间得不到资源。


3. 机器学习训练场景

机器学习训练场景下,资源需求呈现 all or nothing 特点,在队列资源紧张时,如果基于 yarn 原生的公平调度方式,为每个 app 分配部分资源,容易产生资源分配死锁问题。为此我们采用 APP 轮转调度策略,采用类似 FIFO 策略,保障头部 APP(头部会动态变化,轮转策略名称的由来)的资源需求,避免死锁问题。

4. Flink 实时作业场景

FLink 实时场景下,主要介绍故障发生时,如何尽量减少故障的影响范围,以及如何快速恢复故障作业:

  • 通过 cpu 均衡调度,避免机器 cpu 热点。

  • 通过 AM 失败节点规避机制,避免调度到 AM 失败机器。

  • NM 挂起(不调度新 Task,介于 RUNNING 和 LOST 状态)机制,防止 NM 异常退出导致 Task 失败。

  • 基于 Hawk 秒级发现节点宕机,快速进行作业恢复。


虽然可以基于 Hawk 秒级发现节点宕机,但作业恢复过程可能需要几分钟(申请资源,下载 jar 包,job recover 等)。我们通过资源冗余分配策略,优化掉其中资源申请和下载 jar 包过程,最终实现秒级作业恢复。

其他工作 &未来规划

支持超大规模集群:

主要目标支撑十万量级的集群规模,目前基于社区的 federation 方案进行改造。

Hadoop 跨 IDC 集群建设:

受限于公司物理集群规划,离线集群会分布在不同的 IDC,如何基于有限的跨 IDC 带宽,对数据和计算进行合理排布,是一个非常有挑战的问题。

在离线资源混合部署:

基于在线机器的空闲资源运行离线任务,在资源调度和隔离方面有很多工作要做,目前已经取得一定收益。

在离线资源统一管理:

目前 YARN 托管离线调度,k8s 托管在线调度,如何让资源更弹性更统一?我们也在做一些尝试。

流 shuffle 服务建设:

shuffle 过程产生大量大量的随机 IO,通过流 shuffle 服务接管 MR 和 SPARK shuffle 过程,将随机 IO 转变成顺序 IO,提升集群算力并减少在离线混部过程中 IO 影响。


大家如何有兴趣或者疑问可以随时联系我,也欢迎考虑快手大数据架构的工作机会,一起解决更有挑战的事儿。


嘉宾介绍:

房孝敬

快手 | 大数据架构师

2017 年加入快手,负责快手大数据资源调度方向,包括超大规模分布式资源调度,分布式计算,AI 架构等。此前曾在阿里,腾讯,负责搜索 &大数据系统研发工作,hadoop/spark/k8s 社区的 contributor。


本文转载自:DataFunTalk(ID:dataFunTalk)

原文链接:快手超大规模集群调度优化实践

2021-03-11 08:003507

评论

发布
暂无评论
发现更多内容

香港人工智能营销技术研究院正式揭牌成立

东信营销科技

PET口语APP的开发流程

北京木奇移动技术有限公司

软件外包公司 AI口语学习 PET考试

PET口语练习APP的技术框架

北京木奇移动技术有限公司

软件外包公司 AI口语练习 PET考试

用友签约招商局集团人力资源智慧系统(二期)

用友BIP

白鳝:国产化替换浪潮进行时,信创数据库该如何选型?

TiDB 社区干货传送门

数智焕新| 4月招商局集团、悦达集团等选择用友BIP

用友BIP

国内远程控制安全性天花板?ToDesk、向日葵、UU远程、RayLink深度对比

小喵子

远控工具 向日葵 远控软件 ToDesk

「摩根士丹利」最新人形机器人研报:5万亿美元全球市场和最佳商业模式分析(附报告)

机器人头条

科技 大模型 人形机器人 具身智能

苏州企业等保快速通关小秘诀看这里!

行云管家

等保 等保测评

Elasticsearch Enterprise 9.0 (macOS, Linux, Windows) - 分布式搜索和分析引擎

sysin

elasticsearch

悦达集团与用友战略签约,共启数智发展新纪元!

用友BIP

数智焕新进行时,用友BIP助力企业跨越周期、迈向高质量发展

用友BIP

GreatSQL Hash Join 条件列长度对执行计划的影响

GreatSQL

AI重构人力价值链:从“人效管理”到“智效革命”

用友BIP

迭代器失效:99%的C++程序员都会踩的坑 !

电子尖叫食人鱼

c++

Nexpose 8.6.0 for Linux & Windows - 漏洞扫描

sysin

AI大模型入门(二):不微调的大模型能用吗?

测试人

人工智能

用友BIP再发新品,开启「人+智能体+群」业务协同新模式

用友BIP

启动!华润五丰携手用友推进数智化渠道协同管理

用友BIP

从 SQL Server 到 TiDB:恺恩泰助力 40 + 医院数据平台升级的技术实践

TiDB 社区干货传送门

Head First LLM-开篇

好名字可以让你的朋友更容易记住你

#大模型

【AI聊天机器人】轻松上手,快速配置实战指南

JEECG低代码

AI大模型 AI应用 AIGC AI聊天

区块链ETF软件的功能模块

北京木奇移动技术有限公司

区块链开发 软件外包公司 区块链ETF

签约!杭州金投选择用友BIP推进业财一体化,加强精益化管理

用友BIP

从人工智能到业务落地,低代码搭建智能工作流

天津汇柏科技有限公司

人工智能 低代码

区块链ETF软件的核心功能

北京木奇移动技术有限公司

区块链技术 软件外包公司 区块链ETF

AI+高等教育,和鲸Heywhale上线从通识到“学科+AI”的解决方案2.0

ModelWhale

人工智能 数字化教育 智慧教育

Dell OpenManage Enterprise 4.4 - Dell 服务器、存储和网络设备集中管理软件

sysin

dell

JEB Pro v5.29 (macOS, Linux, Windows) - 逆向工程平台

sysin

JEB

用友携手中展集团,打造会展行业首个AI智能体集群

用友BIP

Elasticsearch Enterprise 8.18 (macOS, Linux, Windows) - 分布式搜索和分析引擎

sysin

elasticsearch

快手超大规模集群调度优化实践_架构_DataFunTalk_InfoQ精选文章