真实迁移案例：从 Azkaban 到 DolphinScheduler 的选型与实践

最新推荐文章于 2025-11-21 15:38:22 发布

原创最新推荐文章于 2025-11-21 15:38:22 发布 · 417 阅读

CC 4.0 BY-SA版权

文章标签：

49 篇文章

订阅专栏

我们最早选择用 LinkedIn 开源的 Azkaban 做调度，主要是看中它两个特点：一是界面清爽，操作简单；二是它用“项目”来管理任务，非常直观。那时候团队刚开始搭建数据平台，这种轻量又清晰的工具，正好符合我们的需要。其他还有其他原因：

但随着业务规模扩大，Azkaban 的短板逐渐暴露：

Azkaban 的重试策略极其原始：要么手动点击重跑，要么通过外部脚本轮询状态后触发。我们曾因一个 Hive 任务因临时资源不足失败，导致下游 20+ 个任务全部阻塞，运维不得不半夜手动干预。

Azkaban 的权限模型只有“项目级别”的读写权限，无法做到“用户A只能编辑任务X，不能动任务Y”。在多团队共用一个调度平台时，权限混乱导致误操作频发。

每次修改 job 文件都会覆盖历史版本，无法回滚。我们曾因一次错误的参数修改，导致整个 ETL 流水线跑出错误数据，花了两天才定位到是哪个版本的 job 出了问题。

Azkaban 的插件机制确实不太给力，想接个企业微信告警、对一下内部的 CMDB，或者让它支持 Spark on K8s，基本都得去改源码。而且官方社区更新也慢，GitHub 上面一堆 issue 挂着，经常没人理。

反思： Azkaban 用在小团队、任务不复杂的时候还行，一旦数据平台规模上来了、团队变多了，就会发现它的架构有点跟不上了，各种限制就冒出来了。

2022 年底，我们开始评估替代方案，对比了 Airflow、XXL-JOB、DolphinScheduler 等主流调度系统。最终选择 DolphinScheduler（以下简称 DS），主要基于以下几点：

DS 内置 Shell、SQL、Spark、Flink、DataX、Python 等十几种任务类型，且支持自定义任务插件。我们无需再为每个任务类型写 wrapper 脚本。

在DS平台里，权限管理做得很细致。从租户、项目、工作流到具体任务，层层都可以设置不同人员的操作权限。这样既保证了安全，又让不同团队能够顺畅协作，特别实用。

拖拽式 DAG 编辑，支持任务依赖、条件分支、子流程
工作流每次发布自动保存版本，支持回滚到任意历史版本

作为 Apache 顶级项目，DS 在国内有大量用户和贡献者，文档完善，问题响应快。我们遇到的几个生产问题，都在社区群中 24 小时内得到解答。

任务梳理与分类
- 对现有的 Azkaban 作业做个盘点。先按任务类型（例如 Shell 脚本、Hive SQL、Spark 作业）分个类，然后重点梳理出它们之间的强依赖关系，把整个任务的上下游链路明确下来。
- 标记强依赖关系（如 A → B → C）
DS 环境搭建与测试
- 部署 DS 集群（Master + Worker + API Server + Alert Server）
- 创建租户、用户、项目，配置资源队列（YARN）
任务重构与验证
- 将 Azkaban 的 .job 文件转换为 DS 的工作流定义
- 重点处理：参数传递（Azkaban 用 ${}，DS 用${} 但语法略有不同）；依赖逻辑（Azkaban 用 dependencies，DS 用 DAG 连线）
- 在测试环境跑通全流程，验证数据一致性
灰度切换