稳定性:频繁出现 mysql 连接不释放、锁超时等问题;数据库压力进一步导致调度性能瓶颈,任务无法及时调度。
可维护性:核心调度器通过 php 开发,代码古老又经历多次交接,外围模块实现时采用了 go java python 多种语言;再加上功能上也存在单点,维护成本很高。
扩展性:业务高速发展,不同任务类型需求越来越多,但是调度作为底层服务在支撑上一直力不从心。
可观测性:由于是定时 nohup 启动任务进程的方式,经常出现任务跑飞了的情况,系统暴露出来的可观测指标几乎为0。
任务类型上:HiveSQL、SparkSQL、DorisSQL、PrestoSQL、部分 shell 任务,均通过
DolphinScheduler 调度;遗留部分 shell 任务在原调度系统。
任务数量上:DolphinScheduler 天级别调度数万工作流实例,数十万任务实例,高峰时期同时运行 4K+ 工作流实例。迁移完成后,预计工作流实例实例数翻倍。
原有调度系统服务多年,用户对于功能设计、系统专有字段名词等都已经养成习惯
2W+工作流的迁移预计耗时较久,涵盖公司众多重要数据流,问题影响程度高
用户覆盖了公司众多业务线(平台、直播课、硬件、图书),问题影响面广
用户能够查看所有任务实例的运行情况,包括一些内部已经习惯的调度名词(run_index、result_ftp、log_ftp、csv_result_path等),这部分信息在
DolphinScheduler 调度里显然没有
任务和任务之间有依赖关系,两个系统间调度任务时,也需要查询对方系统调度的任务实例状态,用于判断当前任务依赖是否就绪。
查询方式、字段、API跟之前一致
任务更新时,如果该任务已经迁移到了新调度系统,则同时更新 DolphinScheduler 里的工作流定义
调度时间是否基本一致:用于验证依赖配置、定时设置等的兼容性
数据库:
QPS: 10000+
-> 500
负载:4.0 -> 1.0
资源使用降低 65%
例行任务、调试能力全部迁移
DolphinScheduler,沉淀线上操作 SOP
结合社区的容器化进度,实现模块 K8S 部署。当前 API 模块已经在生产环境使用,Worker、Master 进行中
全链路的一键数据回溯能力
离线、实时平台打通
也许你还想看