Apache DolphinScheduler之有赞大数据开发平台的调度系统演进

前言

在不久前的 Apache DolphinScheduler Meetup 2021 上，有赞大数据开发平台负责人宋哲琦带来了平台调度系统从 Airflow 迁移到 Apache DolphinScheduler 的方案设计思考和生产环境实践。

这位来自浙江杭州的 90 后年轻人自 2019 年 9 月加入有赞，在这里从事数据开发平台、调度系统和数据同步组件的研发工作。刚入职时，有赞使用的还是同为 Apache 开源项目的 Airflow，但经过调研和生产环境测试，有赞决定切换到 DolphinScheduler。

有赞大数据开发平台如何利用调度系统？为什么决定重新选型为 Apache DolphinScheduler ？让我们跟着他的分享来一探究竟。

有赞大数据开发平台（DP平台）

作为一家零售科技 SaaS 服务商，有赞的使命是助力线上商家开店，通过社交营销和拓展全渠道零售业务，搭建数据产品和数字化解决方案，为驱动商家数字增长提供更好的 SaaS 能力。

目前，有赞在数据中台的支撑下已经建立了比较完整的数字产品矩阵：

为了支持日益增长的数据处理业务需求，有赞建立了大数据开发平台（以下简称 DP 平台）。这是一个大数据离线开发平台，提供用户大数据任务开发所需的环境、工具和数据。

有赞大数据开发平台架构

有赞大数据开发平台主要由基础组件层、任务组件层、调度层、服务层和监控层五个模块组成。其中，服务层主要负责作业的生命周期管理，基础组件层和任务组件层主要包括大数据开发平台依赖的中间件及大数据组件等基础环境。DP 平台的服务部署主要采用主从模式，Master 节点支持 HA。调度层是在 Airflow 的基础上进行二次开发，监控层对调度集群进行全方位监控和预警。

调度层架构设计

有赞大数据开发平台调度层架构设计

2017 年，我们团队在17年的时候调研了当时的主流的调度系统，最终决定采用 Airflow（1.7）作为 DP 的任务调度模块。根据业务场景实际需求，架构设计方面，我们采用了Airflow Celery Redis MySQL的部署方案，Redis 作为调度队列，通过 Celery 实现任意多台 worker 分布式部署。

在调度节点 HA 设计上，众所周知，Airflow 在 schedule 节点上存在单点问题，为了实现调度的高可用，DP 平台采用了 Airflow Scheduler Failover Controller 这个开源组件，新增了一个 Standby 节点，会周期性地监听 Active 节点的健康情况，一旦发现 Active 节点不可用，则 Standby 切换为 Active，从而保证 schedule 的高可用。

Worker节点负载均衡策略

另外，由于不同任务占据资源不同，为了更有效地利用资源，DP 平台按照 CPU 密集/内存密集区分任务类型，并安排在不同的 celery 队列配置不同的 slot，保证每台机器 CPU/ 内存使用率保持在合理范围内。

调度系统升级选型

自 2017 年有赞大数据平台 1.0 版本正式上线以来，我们已经在 2018 年 100% 完成了数据仓库迁移的计划，2019 年日调度任务量达 30000 ，到 2021 年，平台的日调度任务量已达到 60000 。伴随着任务量的剧增，DP 的调度系统也面临了许多挑战与问题。

Airflow 的痛点

深度二次开发，脱离社区版本，升级成本高；
Python 技术栈，维护迭代成本高；
性能问题

Airflow 的 schedule loop 如上图所示，本质上是对 DAG 的加载解析，将其生成 DAG round 实例执行任务调度。Airflow 2.0 之前的版本是单点 DAG 扫描解析到数据库，这就导致业务增长 Dag 数量较多时，scheduler loop 扫一次 Dag folder 会存在较大延迟（超过扫描频率），甚至扫描时间需要 60-70 秒，严重影响调度性能。

稳定性问题：

Airflow Scheduler Failover Controller 本质还是一个主从模式，standby 节点通过监听 active进程是否存活来判断是否切换，如之前遇到 deadlock 阻塞进程的情况，则会被忽略，进而导致调度故障发生。在生产环境中发生过类似问题后，我们经过排查后发现了问题所在，虽然 Airflow 1.10 版本已经修复了这个问题，但在主从模式下，这个在生产环境下不可忽视的问题依然会存在。

考虑到以上几个痛点问题，我们决定对 DP 平台的调度系统进行重新选型。

在调研对比过程中，Apache DolphinScheduler 进入了我们的视野。同样作为 Apache 顶级开源调度组件项目，我们性能、部署、功能、稳定性和可用性、社区生态等角度对原调度系统和 DolphinScheduler 进行了综合对比。

以下为对比分析结果：

Airflow VS DolphinScheduler

DolphinScheduler 价值评估

如上图所示，经过对 DolphinScheduler 价值评估，我们发现其在相同的条件下，吞吐性能是原来的调度系统的 2 倍，而 2.0 版本后 DolphinScheduler 的性能还会有更大幅度的提升，这一点让我们非常兴奋。

此外，在部署层面，DolphinScheduler 采用的 Java 技术栈有利于ops标准化部署流程，简化发布流程、解放运维人力，且支持Kubernetes、Docker 部署，扩展性更强。

在功能新增上，因为我们在使用过程中比较注重任务依赖配置，而 DolphinScheduler 有更灵活的任务依赖配置，时间配置粒度细化到了时、天、周、月，使用体验更好。另外，DolphinScheduler 的调度管理界面易用性更好，同时支持 worker group 隔离。作为一个分布式调度，DolphinScheduler 整体调度能力随集群规模线性增长，而且随着新特性任务插件化的发布，可自定义任务类型这一点也非常吸引人。

从稳定性与可用性上来说，DolphinScheduler 实现了高可靠与高可扩展性，去中心化的多 Master 多 Worker 设计架构，支持服务动态上下线，自我容错与调节能力更强。

另外一个重要的点是，经过数月的接触，我们发现 DolphinScheduler 社区整体活跃度较高，经常会有技术交流，技术文档比较详细，版本迭代速度也较快。

综上所述，我们决定转向 DolphinScheduler。

DolphinScheduler 接入方案设计

决定接入 DolphinScheduler 之后，我们梳理了平台对于新调度系统的改造需求。

总结起来，最重要的是要满足以下几点：

用户使用无感知，平台目前的用户数有 700-800，使用密度大，希望可以降低用户切换成本；
调度系统可动态切换，生产环境要求稳定性大于一切，上线期间采用线上灰度的形式，希望基于工作流粒度，实现调度系统动态切换；
测试与发布的工作流配置需隔离，目前任务测试和发布有两套配置文件通过 GitHub维护，线上调度任务配置需要保证数据整个确性和稳定性，需要两套环境进行隔离。

针对以上三点，我们对架构进行了重新设计。

架构设计

保留现有前端界面与DP API；
重构调度管理界面，原来是嵌入 Airflow 界面，后续将基于 DolphinScheduler 进行调度管理界面重构；
任务生命周期管理/调度管理等操作通过 DolphinScheduler API 交互；
利用 Project 机制冗余工作流配置，实现测试、发布的配置隔离。

改造方案设计

架构设计完成之后，进入改造阶段。我们对 DolphinScheduler 的工作流定义、任务执行流程、工作流发布流程都进行了改造，并进行了一些关键功能补齐。

工作流定义状态梳理

我们首先梳理了 DolphinScheduler 工作流的定义状态。因为 DolphinScheduler 工作的定义和定时管理会区分为上下线状态，但 DP平台上两者的状态是统一的，因此在任务测试和工作流发布流程中，需要对 DP到DolphinScheduler 的流程串联做相应的改造。

任务执行流程改造

首先是任务测试流程改造。在切换到 DolphinScheduler 之后，所有的交互都是基于DolphinScheduler API 来进行的，当在 DP 启动任务测试时，会在 DolphinScheduler 侧生成对应的工作流定义配置，上线之后运行任务，同时调用 DolphinScheduler 的日志查看结果，实时获取日志运行信息。

工作流发布流程改造

其次，针对工作流上线流程，切换到 DolphinScheduler 之后，主要是对工作流定义配置和定时配置，以及上线状态进行了同步。

通过这两个核心流程的改造。工作流的原数据维护和配置同步其实都是基于 DP master来管理，只有在上线和任务运行时才会到调度系统进行交互，基于这点，DP 平台实现了工作流维度下的系统动态切换，以便于后续的线上灰度测试。

功能补全

此外，DP 平台还进行了一些功能补齐。首先是任务类型的适配。

任务类型适配

目前，DolphinScheduler 平台已支持的任务类型主要包含数据同步类和数据计算类任务，如Hive SQL 任务、DataX 任务、Spark 任务等。因为任务的原数据信息是在 DP 侧维护的，因此 DP 平台的对接方案是在 DP 的 master 构建任务配置映射模块，将 DP 维护的 task 信息映射到 DP 侧的 task，然后通过 DolphinScheduler 的 API 调用来实现任务配置信息传递。

因为 DolphinScheduler 已经支持部分任务类型，所以只需要基于 DP 平台目前的实际使用场景对 DolphinScheduler 相应任务模块进行定制化改造。而对于 DolphinScheduler 未支持的任务类型，如Kylin任务、算法训练任务、DataY任务等，DP 平台也计划后续通过 DolphinScheduler 2.0 的插件化能力来补齐。