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

一、为什么我们放弃了 Azkaban？

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

• 社区活跃（当时）

• 部署简单，依赖少（仅需 MySQL + Web Server + Executor）

• 支持 job 文件定义依赖，适合 DAG 场景

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

1. 缺乏任务失败自动重试机制

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

2. 权限粒度粗糙

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

3. 缺乏任务版本管理

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

4. 扩展性差

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

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

二、为什么选择 DolphinScheduler？

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

1. 原生支持丰富的任务类型

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

2. 完善的失败处理机制

• 支持任务级重试（可配置重试次数、间隔）

• 支持失败告警（邮件、钉钉、企业微信）

• 支持“失败后跳过”或“失败后终止整个工作流”

3. 细粒度权限控制

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

4. 可视化 DAG + 版本管理

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

5. 活跃的中文社区

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

三、真实迁移案例：从 Azkaban 到 DolphinScheduler

背景

• 原系统：Azkaban 3.80，约 150 个工作流，日均任务数 800+

• 目标：平滑迁移至 DS 3.1.2，不影响业务数据产出

迁移步骤

1. 任务梳理与分类

2. 对现有的 Azkaban 作业做个盘点。先按任务类型（例如 Shell 脚本、Hive SQL、Spark 作业）分个类，然后重点梳理出它们之间的强依赖关系，把整个任务的上下游链路明确下来。

3. 标记强依赖关系（如 A → B → C）

4. DS 环境搭建与测试

5. 部署 DS 集群（Master + Worker + API Server + Alert Server）

6. 创建租户、用户、项目，配置资源队列（YARN）

7. 任务重构与验证

8. 将 Azkaban 的 .job 文件转换为 DS 的工作流定义

9. 重点处理：参数传递（Azkaban 用 ${}，DS 用${} 但语法略有不同）；依赖逻辑（Azkaban 用 dependencies，DS 用 DAG 连线）

10. 在测试环境跑通全流程，验证数据一致性

11. 灰度切换

• 先迁移非核心报表任务（如运营日报）

• 观察一周无异常后，逐步迁移核心链路（如用户行为日志 ETL）

• 最终全量切换，保留 Azkaban 只读状态 1 个月用于回溯

踩坑记录

• 坑 1：参数传递不一致

Azkaban 中 ${date}会自动注入当前日期，而 DS 需要显式定义全局参数或使用系统内置变量 {system.datetime}。我们写了个脚本自动转换参数语法。

• 坑 2：资源隔离问题

之前我们所有任务都挤在同一个 YARN 队列里，结果那些跑得久的大任务动不动就把资源全占了，搞得其他小任务一直卡着。后来我们给每个业务线都单独开了账户和 YARN 队列，这下总算清净了，大家各跑各的，谁也不耽误谁。

• 坑 3：告警风暴

任务失败动不动就告警，一开始每天狂响上百条，实在头疼。后来我们调整了策略：只给核心任务开实时告警，非核心的就每天汇总一下，发个邮件同步，清爽多了。

四、给后来者的具体建议

1. 不要盲目追求“大而全”

如果你只有几十个 Shell 脚本任务，用 Cron + 简单监控可能效率更高一点。调度系统有运维成本，评估 ROI 再决定。

2. 重视权限与租户设计

从第一天就规划好租户结构（如按业务线划分），避免后期权限混乱。建议开启“任务审批”功能，关键任务变更需 review。

3. 建立任务健康度指标

• 任务失败率

• 平均运行时长波动

• 依赖阻塞次数

我们用 Prometheus + Grafana 监控这些指标，提前发现潜在问题。

4. 善用子流程（SubProcess）

复杂的 DAG 一多，就容易乱得像“一锅粥”。我们可以把那些常用的功能，比如数据质检、日志归档这些，打包成独立的子流程。这样一来，不仅复用起来方便，后期维护也省心多了。

5. 备份与灾备不能少

• 定期备份 DS 元数据库（MySQL/PostgreSQL）

• 配置多 Master 高可用

• 关键任务设置“跨集群容灾”（如主集群挂掉，自动切到备用集群）

五、关键对比速查表

技术选型不是终点，而是持续优化的起点。