本文将深入介绍 Apache DolphinScheduler 所采用的数据库模式，此模式主要用于持久化存储工作流定义、执行状态、调度信息以及系统元数据。它具备广泛的兼容性，可支持 MySQL、PostgreSQL 和 H2 等多种数据库，其具体定义存储在 dolphinscheduler - dao/src/main/resources/sql 目录下。

模式架构

DolphinScheduler 的数据库模式分为七个主要功能组：

工作流和任务定义模型

定义与实例分离

DolphinScheduler 严格区分定义（模板）和实例（执行）。这实现了版本控制、并发执行和审计跟踪。

关键设计原则：

• 基于代码的标识：工作流和任务都使用代码（bigint）作为跨版本的稳定标识符。
• 复合键：定义使用（代码，版本）作为复合自然键。
• 版本不可变性：每个版本都是不可变的；更改会创建新版本。
• 实例引用：实例引用特定版本的定义。

核心表参考

工作流定义表

t_ds_workflow_definition

工作流模板的主表。

索引：

• UNIQUE KEY workflow_unique (name, project_code)
• UNIQUE KEY uniq_workflow_definition_code (code)
• KEY idx_project_code (project_code)

t_ds_workflow_definition_log

存储工作流定义所有版本的审计日志。

镜像 t_ds_workflow_definition 的结构，额外列：operator、operate_time，主键：(code, version)。

t_ds_task_definition

可在工作流中重用的任务模板。

t_ds_workflow_task_relation

通过指定任务之间的边来定义 DAG 结构。

注意：pre_task_code = 0 表示根节点（无前驱任务）。

执行状态表

t_ds_workflow_instance

工作流的运行时执行记录。

索引：

• KEY workflow_instance_index (workflow_definition_code, id)
• KEY start_time_index (start_time, end_time)

t_ds_task_instance

单个任务的运行时执行记录。

索引：KEY idx_task_instance_code_version (task_code, task_definition_version)

命令模式与工作流执行

命令队列

t_ds_command 表实现了基于队列的执行模型，其中命令触发工作流实例。

t_ds_command 结构

处理流程：

1. 通过 API、调度程序或重试逻辑将命令插入 t_ds_command。
2. 主服务器的 MasterSchedulerThread 持续扫描该表（按优先级、id 排序）。
3. 主服务器生成 t_ds_workflow_instance 记录。
4. 主服务器分析 DAG 并为就绪任务创建 t_ds_task_instance 记录。
5. 成功处理的命令将被删除；失败的命令将移动到 t_ds_error_command。

版本控制系统

基于代码的版本控制模型

DolphinScheduler 使用复杂的版本控制系统，支持：

• 不同版本的并发执行。
• 安全更新而不影响正在运行的实例。
• 完整的变更审计跟踪。

版本管理规则

• 当前版本表：只有“当前”版本存在于 t_ds_workflow_definition 和 t_ds_task_definition 中。
• 日志表：所有版本保存在 *_log 表中，具有 UNIQUE KEY (code, version)。
• 在线状态：每个代码只能有一个版本的 release_state = 1（在线）。
• 实例锁定：工作流实例在创建时锁定到特定版本。
• 版本不可变性：一旦某个版本被实例引用，其日志记录即为不可变。

调度体系架构

Quartz 集成

DolphinScheduler 集成了 Quartz 调度程序以实现基于 cron 的调度。模式包括标准 Quartz 表以及一个映射表。

t_ds_schedules

Quartz 表要点：

• QRTZ_TRIGGERS.NEXT_FIRE_TIME：已索引，便于高效扫描。
• QRTZ_CRON_TRIGGERS.CRON_EXPRESSION：解析后的 cron 定义。
• QRTZ_SCHEDULER_STATE：跟踪 Quartz 调度程序实例。

资源和配置表

数据源管理

t_ds_datasource

存储 SQL 任务的数据库连接配置。

约束：UNIQUE KEY (name, type) - 防止数据源重复。

文件资源

t_ds_resources（已弃用）

注意：此表在模式中已标记为弃用。资源元数据正在迁移到单独的存储后端。

多租户与管理

项目、用户和租户层次结构

关键管理表

t_ds_tenant

默认租户：系统创建一个默认租户，id = -1，tenant_code = 'default'。

t_ds_user

t_ds_project

JDBC 注册表

对于不使用 ZooKeeper 的部署，DolphinScheduler 提供基于 JDBC 的注册表用于服务协调。

注册表详情

t_ds_jdbc_registry_data

存储类似于 ZooKeeper 节点的注册表项。

t_ds_jdbc_registry_lock

实现分布式锁。

t_ds_jdbc_registry_client_heartbeat

跟踪活动客户端以清理临时数据。

清理逻辑：当客户端的心跳过期时，其临时注册表数据和锁将自动删除。

告警系统

告警表

t_ds_alert

由工作流/任务失败或完成生成的告警记录。

索引：KEY idx_sign (sign) - 实现去重。

t_ds_alertgroup

告警通道组。

索引与查询优化

关键索引

该模式包含针对常见查询模式精心设计的索引：

• 工作流和任务查找

- 按定义查询工作流实例：
  `KEY workflow_instance_index (workflow_definition_code, id)`
  - 按定义查询任务实例：
  `KEY idx_task_instance_code_version (task_code, task_definition_version)`
  - 用于监控的时间范围查询*：
  `KEY start_time_index (start_time, end_time)`

• 命令处理：

基于优先级的命令扫描：
`KEY priority_id_index (workflow_instance_priority, id)`

• DAG 关系查询

- 正向和反向 DAG 遍历：
  `KEY idx_pre_task_code_version (pre_task_code, pre_task_version)`
   正向和反向 DAG 遍历：
   `KEY idx_post_task_code_version (post_task_code, post_task_version)`
  `KEY idx_code (project_code, workflow_definition_code)`

唯一约束

在数据库级别强制执行的关键业务规则：

模式演变与升级

DolphinScheduler 在 dolphinscheduler - dao/src/main/resources/sql/upgrade 中维护用于跨版本模式迁移的升级脚本。

近期模式变更

3.3.0 变更

• 将表和列从“process”重命名为“workflow”。
• 删除数据质量表（t_ds_dq_*）。
• 添加用于替代 ZooKeeper 的 JDBC 注册表。
• 从任务表中删除与缓存相关的列。

3.2.0 变更

• 向工作流定义中添加 execution_type（并行/串行模式）。
• 为串行执行链添加 next_workflow_instance_id。
• 向命令和实例表中添加 tenant_code。
• 创建 t_ds_project_parameter 和 t_ds_project_preference。

数据库交互模式

服务层访问

数据库访问通过 dolphinscheduler - dao 中的 DAO 层进行抽象。 关键服务类：

• ProcessService：工作流/任务定义和实例的 CRUD 操作。
• CommandService：命令队列管理。
• ProjectService：项目和权限管理。
• ResourcesService：资源元数据操作。

事务管理

大多数操作使用 Spring 的 @Transactional 注解实现：

• 原子性地创建工作流实例及其任务实例。
• 消费命令并创建实例。
• 版本更新与日志表同步。

连接池

系统使用 HikariCP 进行连接池，在 application.yaml 中配置：

• 默认池大小：50 个连接。
• 连接超时：30 秒。
• 空闲超时：600 秒。