本文为 《深入理解 Apache DolphinScheduler：从调度原理到 DataOps 实战》 系列专栏第五篇，将以 Apache DolphinScheduler 为例，解析调度系统中的失败重试、手动重跑与补数回填机制，澄清调度语义中的 Exactly Once 含义，并总结常见误用场景与实践建议，帮助构建稳定可靠的数据调度体系。

在数据平台的日常运行中，任务失败几乎是不可避免的。网络抖动、资源不足、下游依赖异常、代码 Bug……都可能导致调度任务执行失败。面对失败，很多团队通常依赖 自动重试、手动重跑或补数回填 来恢复数据。

但一个经常被忽视的问题是：

调度系统中的失败重试、手动重跑与补数回填，其语义其实完全不同。

如果理解不清，很容易导致 重复数据、数据错位甚至数据污染。本文将结合 Apache DolphinScheduler 的设计机制，深入解析调度系统中最常见但也最容易被误解的三种能力： 失败重试、手动重跑与补数回填，并进一步探讨 调度系统中 “Exactly Once” 的真实含义。

一、失败重试 vs 手动重跑：两种完全不同的恢复机制

在调度系统中，失败任务通常有两种恢复方式：

1. 自动重试（Retry）
2. 手动重跑（Rerun）

很多人认为两者只是触发方式不同，但实际上它们在 执行语义 上有本质差异。

1 自动重试：同一次实例的再次执行

在 Apache DolphinScheduler 中，每一次调度都会生成一个 Workflow Instance（流程实例），实例中包含多个 Task Instance（任务实例）。

当某个任务失败时，如果配置了 Retry Times，系统会在同一个任务实例下触发自动重试。

其特点是：

• 属于同一次工作流实例
• 保持相同的调度时间（Schedule Time）
• 依赖关系不会改变
• 仅重新执行失败任务

执行流程示意：

自动重试的设计目标是：

解决瞬时失败（Transient Failure）

例如：

• 网络波动
• 临时资源不足
• 外部系统短暂不可用

在这种情况下，自动重试通常可以快速恢复任务。

2 手动重跑：创建新的实例

与自动重试不同， 手动重跑会生成新的实例。

在 Apache DolphinScheduler 中，用户可以选择：

• 重跑失败节点
• 从当前节点开始重跑
• 从头重跑整个流程

这时系统会生成一个新的 Workflow Instance。

示意：

这意味着，两个实例 可能处理同一时间的数据，下游任务 可能重复写入数据。

如果任务不是 幂等（Idempotent） 的，就可能导致 重复数据问题。

二、补数与回填：调度系统中的时间重建

在数据仓库场景中，补数（Backfill）是一项非常常见的操作。例如：

• 新建任务后需要补历史数据
• 某天任务失败，需要补跑
• 上游数据延迟，需要回填

在 Apache DolphinScheduler 中，补数通常通过 Backfill Run 实现。

1 补数的本质：生成多个历史实例

假设一个任务是 每日调度。

补数区间：

2025-03-01 → 2025-03-05

系统会创建多个实例：

Instance (2025-03-01)
Instance (2025-03-02)
Instance (2025-03-03)
Instance (2025-03-04)
Instance (2025-03-05)

每个实例都有：

• 独立执行状态
• 独立依赖关系
• 独立参数

调度时间会被设置为历史时间。

2 补数的关键：调度时间 vs 执行时间

在调度系统中，有两个非常重要的概念：

调度时间（Schedule Time）

数据逻辑时间

执行时间（Execution Time）

任务实际运行时间

例如：

Schedule Time : 2025-03-01
Execution Time: 2025-03-10

如果 SQL 使用的是：

WHERE dt = ${schedule_time}

补数是安全的。

但如果使用：

WHERE dt = today()

补数就会产生 错误数据。

这也是很多数据问题的根源。

三、调度系统中的 Exactly Once：真实含义是什么？

在流处理系统中，例如 Apache Flink，Exactly Once 通常意味着：

每条数据只被处理一次。

但在调度系统中， Exactly Once 的含义完全不同。

调度系统并不能保证任务不会被重复执行，也无法保证数据不会被重复写入。这是因为自动重试可能重复执行，手动重跑可能重复执行，以及补数会重复执行历史逻辑。

因此，调度系统中的 Exactly Once 更接近于：

同一个调度时间只生成一个逻辑实例。

但任务本身仍然可能执行多次。

因此真正的 Exactly Once 需要 任务逻辑保证幂等。

常见实现方式包括：

1 覆盖写入

INSERT OVERWRITE TABLE

2 基于分区写入

partition dt='${schedule_time}'

3 去重写入

MERGE INTO

四、常见误用场景

很多数据事故其实都来自于对调度语义的误解。

1 使用当前时间作为数据日期

错误示例：

dt = today()

正确方式：

dt = ${schedule_time}

2 非幂等写入

例如：

INSERT INTO table

如果任务重跑：

数据会重复

3 手动重跑整个流程

很多用户习惯：

失败 → 从头重跑

但实际上更安全的方式是：

只重跑失败节点

五、最佳实践建议

结合 Apache DolphinScheduler 的使用经验，可以总结出几个重要实践：

1 任务必须设计为幂等

所有任务都应该允许：

重复执行

不会影响数据正确性。

2 数据逻辑必须基于调度时间

避免使用：

now()
today()

统一使用：

${schedule_time}

3 合理使用重试策略

建议配置：

Retry Times: 1~3
Retry Interval: 1~5 min

避免无限重试。

4 补数要控制并发

补数区间过大时：

一次性生成大量实例

可能导致：

• 调度队列阻塞
• 集群资源耗尽

建议：

分批补数

结语

在数据平台中，调度系统往往被认为只是“任务触发器”。但实际上，它承担着 时间管理、依赖控制和故障恢复 的核心职责。

通过理解 失败重试、手动重跑与补数回填 的真实语义，我们才能真正构建 稳定、可靠的数据生产系统。

像 Apache DolphinScheduler 这样的现代调度系统，已经提供了非常完善的机制。但最终决定数据质量的，仍然是：

正确理解调度语义 + 设计幂等的数据任务。

只有这样，数据平台才能在面对失败时依然保持 可恢复、可追溯、可重建。

• 前文回顾：

第 1 篇 | 调度系统，不只是一个“定时器”   第 2 篇｜Apache DolphinScheduler 的核心抽象模型   第 3 篇｜调度是如何“跑起来”的？   第 4 篇｜状态机：调度系统真正的灵魂

• 下篇预告：

第 6 篇｜Apache DolphinScheduler 多租户与资源隔离设计