DolphinScheduler——奇富科技的调度实践

原创

已于 2024-02-29 23:05:08 修改 · 1.9k 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#科技

于 2024-02-29 00:04:16 首次发布

原文大佬的这篇调度系统案例有借鉴意义，这里直接摘抄下来用作学习和知识沉淀。

一、技术架构

在我们公司的大数据离线任务调度架构中，调度平台处于中间层，通过数据集成平台、数据开发平台将工作流提交给调度平台。

二、业务挑战

2.1 调度任务量大

目前每天调度的工作流实例在3万多，任务实例在14万多。每天调度的任务量非常庞大，要保障这么多任务实例稳定、无延迟运行，是一个非常大的挑战。

2.2 运维复杂

因为每天调度的任务实例非常多，经历了几次调度机器扩容阶段，目前2个调度集群有6台Master、34台Worker机器。

2.3 SLA要求高

由于业务的金融属性，如果调度服务稳定性出问题，导致任务重复调度、漏调度或者异常，损失影响会非常大。

三、调度优化实践

我们在过去一年，对于调度服务稳定，我们做了如下2个方向的优化。第一，调度服务稳定性优化。第二、调度服务监控。

3.1 重复调度

用户大规模迁移工作流时，遇到了工作流重复调度问题。现象是同一个工作流会在同一个集群同一时间，生成2个工作流实例。经过排查，基于从A项目迁移到B项目的需求，在工作流上线时，用户通过提交工单，修改了调度数据库中工作流的项目ID，进行迁移。这么做会导致该工作流所对应的quartz（分布式调度器）元数据产生2条数据，进而导致该工作流重复调度。如图3所示，JOB_NAME为’job_1270’的记录，有2条数据，而JOB_GROUP不一样。查询源码job_name对应工作流的定时器ID，JOB_GROUP对应项目ID。因此修改工作流对应的项目ID，会导致quartz数据重复和重复调度。正确迁移工作流项目的方式是，先下线工作流，然后再修改项目ID。

SELECT count(1)FROM     (SELECT TRIGGER_NAME,        count(1) AS num    FROM QRTZ_TRIGGERS    GROUP BY  TRIGGER_NAME    HAVING num > 1

最低0.47元/天解锁文章