第 2 篇｜Apache DolphinScheduler 的核心抽象模型

点击蓝字 关注我们

本文为《深入理解 Apache ：从调度原理到 实战》系列专栏第 2 篇，从源码与调度模型视角，解析 DolphinScheduler 的核心抽象设计，重点说明 Workflow、TaskDefinition 与实例对象的职责边界，并结合 DAG 示意图解释调度系统如何基于依赖判断驱动复杂任务编排。

上文回顾：调度系统，不只是一个“定时器”

在真正使用 DolphinScheduler 一段时间之后，很多人都会产生一个疑问：为什么系统里会同时存在流程定义、流程实例、任务定义、任务实例这么多对象？是不是“设计过度”了？

如果从源码和调度系统的运行方式来看，答案恰恰相反——这些抽象是为了压住复杂性而被刻意拆开的。

在 DolphinScheduler 的设计中，Workflow（源码中对应 ProcessDefinition）从一开始就被定义为纯静态结构。

它描述的内容非常克制：流程里有哪些任务、任务之间如何依赖、是否存在条件分支或子流程。这些信息共同组成了一张 DAG，但这张 DAG 永远不会自己执行。

从源码角度看，Workflow 更像是一个结构化配置对象，而不是调度对象。

你可以在数据库里看到，它不记录成功、失败、开始时间，也不关心某次运行发生了什么。

这背后其实是一条很重要的设计原则：

结构和执行必须彻底分离，否则状态会污染定义。

在 DolphinScheduler 里，DAG 的职责非常单一：判断“某个任务现在能不能被调度”。

它不关心任务如何执行，也不关心任务执行结果的业务含义，只关心依赖是否满足。

 这里放一张 DAG 的 PNG 示意图，展示了一个典型的多父依赖结构。节点是否被调度，并不取决于执行路径的先后顺序，而取决于其所有上游依赖是否已经完成。这正是 DolphinScheduler 在运行时对 DAG 进行动态判断的核心逻辑。

在源码实现中，DAG 会在流程实例启动时被解析成内存结构，用来驱动后续的调度决策。

当某个 TaskInstance 状态发生变化时，调度器并不是“继续往下跑”，而是重新判断 DAG 中哪些节点被解锁了。

这也是为什么 DolphinScheduler 可以天然支持并行、条件分支和失败阻断。

这些能力并不是“写死的逻辑”，而是 DAG 推理的自然结果。

如果说 Workflow 是流程的蓝图，那么 TaskDefinition 就是单个任务的模板。

在源码中，TaskDefinition 保存的是“如果这个任务被调度，它应该如何被执行”的信息，比如：

• 任务类型（Shell、SQL、Spark、Flink 等）
• 参数、脚本内容
• 失败策略、超时配置、资源参数

但有一点非常关键：
TaskDefinition 是完全无状态的。

你在 TaskDefinition 里永远看不到“这次执行是否成功”之类的字段，因为这类信息从语义上就不属于“定义”。

这一点在代码中体现得很明显，例如（示意）：

public class TaskDefinition {    private Long id;    private String name;    private TaskType taskType;    private String taskParams;    private int timeout;    private int failRetryTimes;    // 注意：这里没有任何 execution state}

TaskDefinition 的职责只有一个：描述“怎么跑”，而不是“跑得怎么样”。

理解 DolphinScheduler，绕不开“定义”和“实例”的区别。

当一个 Workflow 被真正触发执行时，系统会基于 Workflow 和 TaskDefinition 复制出一整套运行态对象，也就是：

• ProcessInstance
• TaskInstance

ProcessInstance 代表的是：

“这一次流程执行”

TaskInstance 代表的是：

“这一次任务执行”

所有你在 UI 上看到的状态变化、失败重试、运行日志，全部发生在 Instance 层，而不是 Definition 层。

从源码上看，这个边界非常清晰：

public class ProcessInstance {    private Long id;    private Long processDefinitionId;    private ExecutionStatus state;    private Date startTime;    private Date endTime;}

public class TaskInstance {    private Long id;    private Long taskDefinitionId;    private ExecutionStatus state;    private int retryTimes;    private Date startTime;}

定义是可复用的，实例是一次性的。 这正是调度系统能长期稳定运行的关键。

当任务数量上升、流程开始嵌套、失败变得常态化时，如果没有这些抽象拆分，系统很快就会失控。

DolphinScheduler 通过清晰的模型边界，实现了几件非常重要的事情：

• 同一个 Workflow 可以并发跑多个实例而互不干扰
• 失败重试只影响 TaskInstance，不污染定义
• DAG 判断和任务执行彻底解耦
• 调度逻辑可以围绕“状态迁移”而不是“业务逻辑”展开

从这个角度看，DolphinScheduler 并不是在“管理任务”，而是在管理状态和依赖的演进过程。

如果你把 DolphinScheduler 当成一个“高级 Cron”，这些模型看起来确实复杂；但一旦站在系统和源码的视角看，它反而是一套非常克制、非常工程化的设计。

下一篇，我们可以继续顺着这套模型往下拆，聊聊调度器是如何围绕状态流转运转起来的，以及失败是如何被“消化”的。

用户案例

Cisco Webex天翼云Zoom网易邮箱 每日互动 惠生工程作业帮 博世智驾蔚来汽车 长城汽车集度长安汽车思科网讯食行生鲜联通医疗联想新网银行兴业证券唯品富邦消费金融 自如有赞伊利当贝大数据珍岛集团传智教育BigoYY直播  拈花云科太美医疗深圳某智能制造企业

迁移实战

Azkaban   Ooize（当贝迁移案例） （有赞迁移案例）Air2phin（迁移工具）Airflow

最新发版消息

Apache DolphinScheduler 3.3.2 正式发布！性能与稳定性有重要更新

加入社区

关注社区的方式有很多：

• GitHub: https://github.com/apache/dolphinscheduler
• 官网：https://dolphinscheduler.apache.org/en-us
• 订阅开发者邮件：dev@dolphinscheduler@apache.org（向邮箱发送任意内容，收到邮件后回复同意订阅即可）
• X.com：@DolphinSchedule
• YouTube：https://www.youtube.com/@apachedolphinscheduler
• Slack：https://join.slack.com/t/asf-dolphinscheduler/shared_invite/zt-1cmrxsio1-nJHxRJa44jfkrNL_Nsy9Qg

同样地，参与Apache DolphinScheduler 有非常多的参与贡献的方式，主要分为代码方式和非代码方式两种。

非代码方式包括：

完善文档、翻译文档；翻译技术性、实践性文章；投稿实践性、原理性文章；成为布道师；社区管理、答疑；会议分享；测试反馈；用户反馈等。

‍代码方式包括：

查找Bug；编写修复代码；开发新功能；提交代码贡献；参与代码审查等。

贡献第一个PR(文档、代码) 我们也希望是简单的，第一个PR用于熟悉提交的流程和社区协作以及感受社区的友好度。

社区汇总了以下适合新手的问题列表：https://github.com/apache/dolphinscheduler/pulls?q=is%3Apr+is%3Aopen+label%3A%22first+time+contributor%22

优先级问题列表：https://github.com/apache/dolphinscheduler/pulls?q=is%3Apr+is%3Aopen+label%3Apriority%3Ahigh

如何参与贡献链接：https://dolphinscheduler.apache.org/zh-cn/docs/3.2.2/%E8%B4%A1%E7%8C%AE%E6%8C%87%E5%8D%97_menu/%E5%A6%82%E4%BD%95%E5%8F%82%E4%B8%8E_menu

如果你❤️小海豚，就来为我点亮Star吧！

https://github.com/apache/dolphinscheduler

你的好友秀秀子拍了拍你

并请你帮她点一下“分享”