本文主要是介绍Schedulerx2.0应用级别资源管理和任务优先级,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
1. 前言
Schedulerx2.0是一套分布式的任务调度+计算框架。作为一套分布式计算引擎,用户经常需要资源管理的需求,当前schedulerx仅仅支持单个任务实例的管控(比如单机子任务并发数、拉模型全局子任务并发数等),这一点是远远不够的。比如某一时刻大量任务要触发,用户资源不够,当前是无法管控的。
业内任务调度系统一般都focus在任务调度上,资源管理会借助第三方系统(比如mesos, yarn),这类系统的执行单元worker都是由调度平台管控的。这一点和schedulerx还是不一样的,schedulerx的计算worker都是各个用户自己的应用程序接入的,无法通过统一的第三方资源管理系统来管理。
2. 应用级别资源管理
1) 新建应用分组的时候,高级配置可以打开流控开关(默认关闭)
打开开关后,可以配置应用级别的任务队列(即任务实例并发数)。该队列表示一个应用最多同时运行的任务实例个数,超过并发数的任务实例不会丢弃,会放在队列中等待执行。
2) 在该分组下新建3个任务,分别手动运行一次
3) 会发现,第一个触发的任务hello_jobA在运行中,hello_jobB和hello_jobC在池子中排队
4) 等hello_jobA运行完,hello_jobB会进入执行队列
3. 任务优先级
任务支持优先级,同一个应用下,调度时间一样,优先级高的任务优先调度
用户1:“我把自己的任务全部设置为非常高,是不是能保证自己的任务比其他用户的任务优先调度?”
回答:任务优先级是应用级别的,只会在该应用下生效,不会影响其他应用。
用户2:“客户端都有很多台机器,高优先任务和低优先级任务分布式调度到不同的机器,也有可能低优先任务先运行啊,这个功能看起来貌似很鸡肋?”
回答:别急,接着看下一节。
4. 可抢占的优先级队列
熟悉大数据的同学,应该对下面这个图很熟悉。这个是yarn的优先级队列,对不同优先级的任务做资源隔离
我们可以来看下,schedulerx如何通过应用级别资源管理+任务优先级,来实现可抢占的任务优先级队列。
1) dts-all.hxm这个应用开启限流,队列大小=1方便观察,新建3个优先级任务如下图。先触发1次中优先级任务,再触发1次低优先级任务,再触发一次高优先级任务
2) 因为先触发中优先级任务的时候,队列还是空的,所以中优先任务先跑
3) 中优先级任务跑完之后,队列有空闲槽位了,高优先级任务会抢占低优先级任务先执行
5. 应用场景
该功能上线后,应用场景非常多,很多业务方都有应用级别资源控制和任务优先级的需求。比如数据平台每天要跑报表,可能会有成千上万的任务在晚上跑,如果没有资源控制,所有任务一起跑会把应用打挂。然后要求kpi报表必须早上9点前产生(老板和运营上班要看),这就需要在资源控制的基础上,高优先级任务优先调度,如果低优先级任务先进入队列,高优先任务也能抢占优先调度。
6. 总结及未来展望
相比较yarn的资源管理来说,yarn能做到vcore, cpu, memory等资源级别的管控。Schedulerx作为通用的任务调度平台,在调度端实现对任务运行实例个数和优先级的管控。
当前Schedulerx无法做到core, cpu, memory级别的资源管控,是因为当前接入方式,是应用自己的worker接入,不是由调度平台提供的机器。未来Schedulerx会和云原生结合,用户接入只需要上传jobProcessor的jar包,由调度平台申请容器运行,大大减少了接入的代价,还能做到细粒度的资源管控,弹性扩缩容等能力。
这篇关于Schedulerx2.0应用级别资源管理和任务优先级的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!