第 2 篇｜Apache DolphinScheduler 的核心抽象模型
本文为《深入理解 Apache DolphinScheduler：从调度原理到 DataOps 实战》系列专栏第 2 篇，从源码与调度模型视角，解析 DolphinScheduler 的核心抽象设计，重点说明 Workflow、TaskDefinition 与实例对象的职责边界，并结合 DAG 示意图解释调度系统如何基于依赖判断驱动复杂任务编排。 上文回顾：调度系统，不只是一个“定时器” 在真正使用 DolphinScheduler 一段时间之后，很多人都会产生一个疑问：为什么系统里会同时存在流程定义、流程实例、任务定义、任务实例这么多对象？是不是“设计过度”了？ 如果从源码和调度系统的运行方式来看，答案恰恰相反——这些抽象是为了压住复杂性而被刻意拆开的。 在 DolphinScheduler 的设计中，Workflow（源码中对应 它描述的内容非常克制：流程里有哪些任务、任务之间如何依赖、是否存在条件分支或子流程。这些信息共同组成了一张 DAG，但这张 DAG 永远不会自己执行。 从源码角度看，Workflow 更像是一个结构化配置对象，而不是调度对象。 你可以在数据库里看到，它不记录成功、失败、开始时间，也不关心某次运行发生了什么。 这背后其实是一条很重要的设计原则： 在 DolphinScheduler 里，DAG 的职责非常单一： 它不关心任务如何执行，也不关心任务执行结果的业务含义，只关心依赖是否满足。 📌 这里放一张 DAG 的 PNG 示意图，展示了一个典型的多父依赖结构。节点是否被调度，并不取决于执行路径的先后顺序，而取决于其所有上游依赖是否已经完成。这正是 DolphinScheduler 在运行时对 DAG 进行动态判断的核心逻辑。 在源码实现中，DAG 会在流程实例启动时被解析成内存结构，用来驱动后续的调度决策。 当某个 TaskInstance 状态发生变化时，调度器并不是“继续往下跑”，而是重新判断 DAG 中哪些节点被解锁了。 这也是为什么 DolphinScheduler 可以天然支持并行、条件分支和失败阻断。 这些能力并不是“写死的逻辑”，而是 DAG 推理的自然结果。 如果说 Workflow 是流程的蓝图，那么 TaskDefinition 就是单个任务的模板。 在源码中， 但有一点非常关键： 你在 TaskDefinition 里永远看不到“这次执行是否成功”之类的字段，因为这类信息从语义上就不属于“定义”。 这一点在代码中体现得很明显，例如（示意）： TaskDefinition 的职责只有一个：描述“怎么跑”，而不是“跑得怎么样”。 理解 DolphinScheduler，绕不开“定义”和“实例”的区别。 当一个 Workflow 被真正触发执行时，系统会基于 Workflow 和 TaskDefinition 复制出一整套运行态对象，也就是： ProcessInstance 代表的是： TaskInstance 代表的是： 所有你在 UI 上看到的状态变化、失败重试、运行日志，全部发生在 Instance 层，而不是 Definition 层。 从源码上看，这个边界非常清晰： 定义是可复用的，实例是一次性的。 这正是调度系统能长期稳定运行的关键。 当任务数量上升、流程开始嵌套、失败变得常态化时，如果没有这些抽象拆分，系统很快就会失控。 DolphinScheduler 通过清晰的模型边界，实现了几件非常重要的事情： 从这个角度看，DolphinScheduler 并不是在“管理任务”，而是在管理状态和依赖的演进过程。 如果你把 DolphinScheduler 当成一个“高级 Cron”，这些模型看起来确实复杂；但一旦站在系统和源码的视角看，它反而是一套非常克制、非常工程化的设计。 下一篇，我们可以继续顺着这套模型往下拆，聊聊：
Workflow：一张不会“运行”的 DAG 蓝图
ProcessDefinition）从一开始就被定义为纯静态结构。结构和执行必须彻底分离，否则状态会污染定义。
DAG 在 DolphinScheduler 中真正解决的是什么问题
判断“某个任务现在能不能被调度”。
TaskDefinition：任务的“执行模板”
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
}流程定义 vs 流程实例：真正的分水岭
ProcessInstanceTaskInstance“这一次流程执行”
“这一次任务执行”
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;
}这些抽象如何支撑“复杂编排”
小结
调度器是如何围绕状态流转运转起来的，以及失败是如何被“消化”的。
