【大数据技术干货】阿里云伏羲(fuxi)调度器FuxiMaster功能简介(二) 调度模型

简介: 转载自xingbao各位好,这是介绍阿里云伏羲(fuxi)调度器系列文章的第二篇,今天主要介绍调度模型和FIFO\FAIR调度策略 一、FuxiMaster简介 FuxiMaster和Yarn非常相似,定位于分布式系统中资源管理与分配的角色:一个典型的资源分配流程图如下所示: 作为调度器,目前F

免费开通大数据服务:https://www.aliyun.com/product/odps

转载自xingbao

各位好,这是介绍阿里云伏羲(fuxi)调度器系列文章的第二篇,今天主要介绍调度模型和FIFO\FAIR调度策略

一、FuxiMaster简介

FuxiMaster和Yarn非常相似,定位于分布式系统中资源管理与分配的角色:一个典型的资源分配流程图如下所示: 




作为调度器,目前FuxiMaster支持的功能主要有:

1、多租户管理

2、支持FIFO/FAIR调度策略(本文)

3、 针对在线服务保持资源强稳定

4、 支持NodeLabel动态划分集群

5、支持多机房调度

6、支持基于优先级的交互式抢占

7、支持AllOrNothing调度

8、支持基于硬件ID化的调度

9、单Master目前支持2w台机器的规模

10、......

二、基本调度单元与基于拓扑的调度语义.

1、基本调度单元:

在fuxi系统内,基本的调度单元称作ScheduleUnit,它的概念和Yarn的Container是不同的: 举个例子,假设一个MR的作业,规模是1000*1000, 那么在Yarn的调度器中,对应就有100,000个调度单元;而在fuxi系统里,只有2个调度单元(ScheduleUnit), 每一个SchedsuleUnit的SlotNumber是1000。在调度层面上,ScheduleUnit是同一类Slot的集合

2、基本调度语义:

在fuxi系统内,目前线上存在3种基于拓扑的调度语义:LT_MACHINE\LT_ENGINEROOM\LT_CLUSTER, 分别对应着指定机器、指定机房、全集群任选集群;且调度的优先级是LT_MACHINE > LT_ENGINEROOM > LT_CLUSTER; 一个典型的资源申请请求为: SchduleUnit{SlotNum:5, M1 *1, M2 * 1, M3 *1, M4 *1, M5 * 1, C * 5}, 这个ScheduleUnit理解为:总共需要5个slot,优先在M1\M2\M3\M4\M5上分配资源,如果这些机器资源不满足的话,也可以退而其次在其他机器上(LT_CLUSTER)上分配资源

三、主动调度策略:

作业第一次将SchduleUnit发送到调度器时,调度器会遍历ScheduleUnit的拓扑语义在对应机器上进行调度,对应LT_MACHINE的语义,会直接到指定机器上尝试分配资源;如果是LT_ENGINEOOM\LT_CLUSTER的语义,则在一组满足条件的机器列表内进行RoundRobin的分配( roundrobin);

除此之外,还有一些额外的分配限定:

1、ScheduleUnit如果是属于某个QuotaGroup的,那么会首先根据这个QuotaGroup的剩余可用Quota / ScheduleUnit体积 得出一个从Quota层面可以分配的slot数目,与ScheduleUnit的desireNum取一个min;

2、ScheduleUnit可以定义在同一台机器上分配的最大worker数目,主要防止相同类型的worker扎堆在同一台机器上;

3、如果机器处于ScheduleUnit的黑名单中,那么这台机器也不会被分配;黑名单的来源有2种,一种是集群中PE加入的全局黑名单,这个对所有SscheduleUnit都是不可用的;一种的ScheduleUnit自己的黑名单,通常是一台机器多次出现slot运行失败,则作业会通知调度器暂时不调度新的slot到这台机器上;

主动调度策略从全局来说是一种贪心的调度策略,尽量对ScheduleUnit进行调度,如果ScheduleUnit没有被完全满足,则ScheduleUnit携带剩余的DesireNum进入到排队队列,等待被动调度策略触发调度

四、被动调度策略:

被动调度策略顾名思义,是处于waitingQueue中的SchduleUnit被动的被调度器挑选中分配资源;触发被动调度策略的条件有2个:一个是跑完的作业归还资源;一个是机器的资源增加;即当有额外的可用资源时,就会触发被动调度策略,在内部有一个更形象的名字,称为”OnResourceFree“

1、如何挑选waitingQueue

WaitingQueue是基于QuotaGroup的,每一个QuotaGroup都有自己的waitingQueue,同组的ScheduleUnit只会插入到自己组的waitingQueue中;当有一台机器有剩余资源时,我们挑选哪一个QuotaGroup的waitingQueue进行分配呢? 在FuxiMaster中,QuotaGroup有“Hungry”的概念,Hungry的定义是:usdQuota/maxQuota(概念参见 上一篇),此值越低,表明这个QuotaGroup越饥饿,越应该优先得到满足(这里我们也在讨论是否参考runtimeQuota更合理); 根据Hungry对所有QuotaGroup进行排序后,我们就可以得出一个waitingQueue的分配顺序

2、WaitingQueue的构成及遍历

WaitingQueue存放着没有被满足的ScheduleUnit,SchdeduleUnit排列的顺序是根据ScheduleUnit的优先级决定的: 每一个ScheduleUnit都被作业赋予了一个优先级,优先级越高,表明越应该优先分配资源,故在waitingQueue中的位置就越靠前。

在具体分配过程中,对于每一个ScheduleUnit的分配是贪心的,也收到在主动调度策略中的各种限制,一种典型的分配场景如下图所示:




在上图中,如果我们根据优先级依次对ScheduleUnit尝试分配时,发现处于前4个的ScheduleUnit的体积都比机器的可用资源大,那么总共产生80%的无用遍历,当队列中ScheduleUnit比较多时,这个遍历的代价是比较大的,时间复杂度是O(N), 为此,我们采用了如下的算法,期望能够直接找到从资源维度能够分配的ScheduleUnit,同时满足优先级的约定:


首先,我们根据ScheduleUnit的CPU体积构建子队列,每个子队列的ScheduleUnit CPU体积相同,且根据优先级进行排列;同时根据可用资源取出每个候选队列的对头的ScheduleUnit,构建成堆;



当对第一个元素进行分配并POP后,如果堆头ScheduleUnit的体积大于剩余资源,则直接POP;同时尝试将上一个POP出去的ScheduleUnit所属队列的下一个ScheduleUnitPush进堆;


继续:


直到绿线比最低的虚线还要低,表示无法在分配,算法结束



当然,同一条虚线上的ScheduleUnit虽然在CPU维度满足,但是在MEM维度还是可能不满足,所以还是可能会有很多无用遍历,还有优化的空间:



0、红黑树节点保存ScheduleUnit的指针,排序的key是priority

1、每个节点保存自己左、右子树的ScheduleUnit SlotDesc MEM的最小值;

2、先看左子树,如果左子树的ScheduleUnit SlotDesc MEM的最小值比可用资源MEM的值小,表示左子树中有可分的、高优先级的SU,向左子树递归;

3、如果左子树不满足,则看自己满足不满足

4、如果自己不满足,则看右子树的SU SlotDesc MEM的最小值是否比可用资源, MEM的值小,表示左右子树中有可分的、低优先级的SU,向右子树递归;

5、如果都不满足,则此树上所有节点都不再可能被分配资源,以后就不用在遍历此树了


这样做之后,我们就可以以O(logN)的代价找到优先级最高的、CPU、MEM也满足条件的ScheduleUnit,下面一组实验表明了算法的优越性:




在上述实验中,可分的ScheduleUnit只有一个,剩余的ScheduleUnit的体积全部比剩余资源大。可以看到,优化方案比普通遍历方案在性能上提升非常明显

3、FIFO\FAIR调度策略

FIFO\FAIR调度策略的却别体现在WaitingQueue的排序的Key: 如果ScheduleUnit的优先级不同,那么两者都会优先对高优先级的ScheduleUnit进行分配;当优先级相同时,FIFO是根据ScheduleUnit的提交时间进行排序的,提交时间越早,优先级越高; 而FAIR是根据已经分配到的SlotNum进行排序的,已经分配的slotNum越小,优先级越高。这样对FAIR组而言,基本保证了同优先级ScheduleUnits拿到的资源份数基本是相同的


欢迎加入“数加·MaxCompute购买咨询”钉钉群(群号: 11782920)进行咨询,群二维码如下:

96e17df884ab556dc002c912fa736ef6558cbb51 
相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
目录
相关文章
|
2月前
|
存储 人工智能 大数据
云栖2025|阿里云开源大数据发布新一代“湖流一体”数智平台及全栈技术升级
阿里云在云栖大会发布“湖流一体”数智平台,推出DLF-3.0全模态湖仓、实时计算Flink版升级及EMR系列新品,融合实时化、多模态、智能化技术,打造AI时代高效开放的数据底座,赋能企业数字化转型。
717 0
|
4月前
|
数据采集 人工智能 分布式计算
ODPS在AI时代的发展战略与技术演进分析报告
ODPS(现MaxCompute)历经十五年发展,从分布式计算平台演进为AI时代的数据基础设施,以超大规模处理、多模态融合与Data+AI协同为核心竞争力,支撑大模型训练与实时分析等前沿场景,助力企业实现数据驱动与智能化转型。
407 4
|
2月前
|
数据可视化 大数据 关系型数据库
基于python大数据技术的医疗数据分析与研究
在数字化时代,医疗数据呈爆炸式增长,涵盖患者信息、检查指标、生活方式等。大数据技术助力疾病预测、资源优化与智慧医疗发展,结合Python、MySQL与B/S架构,推动医疗系统高效实现。
|
4月前
|
SQL 分布式计算 大数据
我与ODPS的十年技术共生之路
ODPS十年相伴,从初识的分布式计算到共生进化,突破架构边界,推动数据价值深挖。其湖仓一体、隐私计算与Serverless能力,助力企业降本增效,赋能政务与商业场景,成为数字化转型的“数字神经系统”。
|
4月前
|
机器学习/深度学习 人工智能 自然语言处理
Java 大视界 -- Java 大数据机器学习模型在自然语言生成中的可控性研究与应用(229)
本文深入探讨Java大数据与机器学习在自然语言生成(NLG)中的可控性研究,分析当前生成模型面临的“失控”挑战,如数据噪声、标注偏差及黑盒模型信任问题,提出Java技术在数据清洗、异构框架融合与生态工具链中的关键作用。通过条件注入、强化学习与模型融合等策略,实现文本生成的精准控制,并结合网易新闻与蚂蚁集团的实战案例,展示Java在提升生成效率与合规性方面的卓越能力,为金融、法律等强监管领域提供技术参考。
|
4月前
|
存储 人工智能 算法
Java 大视界 -- Java 大数据在智能医疗影像数据压缩与传输优化中的技术应用(227)
本文探讨 Java 大数据在智能医疗影像压缩与传输中的关键技术应用,分析其如何解决医疗影像数据存储、传输与压缩三大难题,并结合实际案例展示技术落地效果。
|
3月前
|
机器学习/深度学习 传感器 分布式计算
数据才是真救命的:聊聊如何用大数据提升灾难预警的精准度
数据才是真救命的:聊聊如何用大数据提升灾难预警的精准度
300 14
|
5月前
|
数据采集 分布式计算 DataWorks
ODPS在某公共数据项目上的实践
本项目基于公共数据定义及ODPS与DataWorks技术,构建一体化智能化数据平台,涵盖数据目录、归集、治理、共享与开放六大目标。通过十大子系统实现全流程管理,强化数据安全与流通,提升业务效率与决策能力,助力数字化改革。
206 4
|
4月前
|
机器学习/深度学习 运维 监控
运维不怕事多,就怕没数据——用大数据喂饱你的运维策略
运维不怕事多,就怕没数据——用大数据喂饱你的运维策略
180 0
|
3月前
|
传感器 人工智能 监控
数据下田,庄稼不“瞎种”——聊聊大数据如何帮农业提效
数据下田,庄稼不“瞎种”——聊聊大数据如何帮农业提效
158 14

相关产品

  • 云原生大数据计算服务 MaxCompute