Schedulerx2.0支持应用级别资源管理和任务优先级-阿里云开发者社区

开发者社区> 阿里分布式任务调度> 正文

Schedulerx2.0支持应用级别资源管理和任务优先级

简介: 1. 前言 Schedulerx2.0是一套分布式的任务调度+计算框架。作为一套分布式计算引擎,用户经常需要资源管理的需求,当前schedulerx仅仅支持单个任务实例的管控(比如单机子任务并发数、拉模型全局子任务并发数等),这一点是远远不够的。

1. 前言

Schedulerx2.0是一套分布式的任务调度+计算框架。作为一套分布式计算引擎,用户经常需要资源管理的需求,当前schedulerx仅仅支持单个任务实例的管控(比如单机子任务并发数、拉模型全局子任务并发数等),这一点是远远不够的。比如某一时刻大量任务要触发,用户资源不够,当前是无法管控的。
业内任务调度系统一般都focus在任务调度上,资源管理会借助第三方系统(比如mesos, yarn),这类系统的执行单元worker都是由调度平台管控的。这一点和schedulerx还是不一样的,schedulerx的计算worker都是各个用户自己的应用程序接入的,无法通过统一的第三方资源管理系统来管理。

2. 应用级别资源管理

1) 新建应用分组的时候,高级配置可以打开流控开关(默认关闭)
image
打开开关后,可以配置应用级别的任务队列(即任务实例并发数)。该队列表示一个应用最多同时运行的任务实例个数,超过并发数的任务实例不会丢弃,会放在队列中等待执行。

2) 在该分组下新建3个任务,分别手动运行一次
image

3) 会发现,第一个触发的任务hello_jobA在运行中,hello_jobB和hello_jobC在池子中排队
image

4) 等hello_jobA运行完,hello_jobB会进入执行队列
image

3. 任务优先级

任务支持优先级,同一个应用下,调度时间一样,优先级高的任务优先调度
image

用户1:“我把自己的任务全部设置为非常高,是不是能保证自己的任务比其他用户的任务优先调度?”
回答:任务优先级是应用级别的,只会在该应用下生效,不会影响其他应用。

用户2:“客户端都有很多台机器,高优先任务和低优先级任务分布式调度到不同的机器,也有可能低优先任务先运行啊,这个功能看起来貌似很鸡肋?”
回答:别急,接着看下一节。

4. 可抢占的优先级队列

熟悉大数据的同学,应该对下面这个图很熟悉。这个是yarn的优先级队列,对不同优先级的任务做资源隔离
image

我们可以来看下,schedulerx如何通过应用级别资源管理+任务优先级,来实现可抢占的任务优先级队列。
1) dts-all.hxm这个应用开启限流,队列大小=1方便观察,新建3个优先级任务如下图。先触发1次中优先级任务,再触发1次低优先级任务,再触发一次高优先级任务
image

2) 因为先触发中优先级任务的时候,队列还是空的,所以中优先任务先跑
image

3) 中优先级任务跑完之后,队列有空闲槽位了,高优先级任务会抢占低优先级任务先执行
image

5. 应用场景

该功能上线后,应用场景非常多,很多业务方都有应用级别资源控制和任务优先级的需求。比如数据平台每天要跑报表,可能会有成千上万的任务在晚上跑,如果没有资源控制,所有任务一起跑会把应用打挂。然后要求kpi报表必须早上9点前产生(老板和运营上班要看),这就需要在资源控制的基础上,高优先级任务优先调度,如果低优先级任务先进入队列,高优先任务也能抢占优先调度。

6. 总结及未来展望

相比较yarn的资源管理来说,yarn能做到vcore, cpu, memory等资源级别的管控。Schedulerx作为通用的任务调度平台,在调度端实现对任务运行实例个数和优先级的管控。
当前Schedulerx无法做到core, cpu, memory级别的资源管控,是因为当前接入方式,是应用自己的worker接入,不是由调度平台提供的机器。未来Schedulerx会和云原生结合,用户接入只需要上传jobProcessor的jar包,由调度平台申请容器运行,大大减少了接入的代价,还能做到细粒度的资源管控,弹性扩缩容等能力。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
官网链接