3、回填触发机制：手动触发、上游失败自动触发、数据质量告警触发、定时扫描触发
回填任务什么时候开始跑？这是个很实际的问题。
我见过不少团队，上来就把所有回填都做成定时扫描。结果呢？数据没到齐就开始补，补完又被覆盖，白白浪费计算资源。说白了，触发时机选不对，整个回填策略就是空中楼阁。
这一章，我们把这四种触发机制掰开揉碎了讲。每种机制适合什么场景、有什么坑、怎么搭，我都会结合项目经验说清楚。
核心观点：没有万能的触发机制。好的调度系统，应该支持四种机制自由组合，甚至在一个回填任务里混合使用。
3.1 手动触发：最原始也最可靠
手动触发，就是人直接点按钮或者调接口，让回填任务跑起来。听起来很土，对吧？但说实话，这是我最常用的方式。
为什么？因为回填本身就不是高频操作。数据出问题了，你第一反应肯定是先查原因，而不是让系统自动去补。手动触发给了你一个「确认」的环节。
我的习惯：所有核心回填任务，我都会保留手动触发的入口。哪怕已经配了自动触发，手动通道也必须开着。这是最后的保险。
手动触发一般有两种形式：
- Web UI 操作：在调度系统页面上选择任务、填写回填时间范围、点击执行。适合非技术人员或紧急情况。
- API 调用：通过 REST API 或 CLI 工具触发。适合脚本化、批量操作或集成到运维平台。
举个例子，我们之前有个离线数仓任务，每天凌晨 3 点跑。某天凌晨 2 点源系统挂了，数据没过来。等修复完已经早上 8 点了。这时候我直接登录调度系统，选中这个任务，回填时间范围选「2024-01-15」，点执行。10 分钟后数据补完，业务没受任何影响。
注意：手动触发虽然灵活，但容易出错。我见过有人把回填时间范围填错，补了三个月的数据，把线上表撑爆了。所以，手动触发一定要加「二次确认」和「范围校验」。
3.2 上游失败自动触发：依赖链的自我修复
数据任务之间是有依赖关系的。A 任务产出表 T1，B 任务依赖 T1 产出 T2。如果 A 失败了，B 自然跑不了。但问题来了：A 修复之后，B 怎么办？
这就是上游失败自动触发的场景。
它的核心逻辑很简单：
- 监控上游任务的完成状态
- 如果上游任务失败后重跑成功
- 自动触发下游任务对失败时间段进行回填
我在项目中遇到过一种情况：某个上游任务因为数据倾斜，每天都会失败一两次。运维同学每天手动重跑，累得够呛。后来我配了自动触发：上游失败后，系统自动重试 3 次，如果还失败就发告警，但一旦重跑成功，自动触发下游所有依赖任务回填。从那以后，运维同学终于能睡个安稳觉了。
| 参数 | 说明 | 推荐值 |
|---|---|---|
| 重试次数 | 上游失败后自动重试的最大次数 | 3 次 |
| 重试间隔 | 每次重试之间的等待时间 | 5 分钟 |
| 回填范围 | 自动回填的时间窗口 | 上游失败影响的时间段 |
| 并发控制 | 同时回填的任务数量上限 | 5 个 |
关键点：自动触发不是无脑重跑。一定要结合「影响范围分析」，只回填真正受影响的时段。否则，一个上游失败可能引发下游几十个任务全部重跑，集群直接被打满。
3.3 数据质量告警触发：让数据自己说话
前面两种触发机制，都是基于「任务状态」来判断的。但有时候任务跑成功了，数据却是错的。怎么办？
数据质量告警触发，就是来解决这个问题的。
它的工作流程是这样的：
- 数据产出后，质量监控模块对数据进行校验（空值率、波动率、一致性等）
- 如果校验不通过，触发告警
- 告警信息中包含「受影响的数据时间段」
- 调度系统根据告警信息，自动发起回填任务
我曾经踩过一个坑：某个报表任务每天跑完都显示成功，但连续一周的数据都是错的。原因是上游源表结构变了，但任务没报错。后来我加了数据质量监控，配置了「行数波动超过 20% 触发告警并自动回填」。当天就发现了问题，数据在 10 分钟内被修复。
建议：数据质量告警触发，最好配合「人工确认」环节。自动回填之前，先发一条通知给值班人员，给他 5 分钟确认时间。如果没人驳回，再自动执行。这样既快又稳。
3.4 定时扫描触发：兜底方案
前面三种机制，都是「事件驱动」的。但总有一些情况会被漏掉：
- 手动触发忘了点
- 上游失败自动触发没覆盖到
- 数据质量告警阈值设得太宽
这时候就需要定时扫描触发来兜底。
定时扫描触发，说白了就是一个后台守护进程，每隔一段时间扫描一次数据表，检查有没有「时间空洞」——也就是应该被覆盖但实际没被覆盖的数据区间。如果发现了，就自动发起回填。
它的核心参数有这几个：
| 参数 | 说明 | 典型配置 |
|---|---|---|
| 扫描周期 | 多久扫描一次 | 每 30 分钟 |
| 扫描窗口 | 每次扫描检查多长的时间范围 | 过去 24 小时 |
| 空洞判定规则 | 什么样的区间算「未覆盖」 | 连续缺失超过 1 小时 |
| 最大回填批次 | 一次扫描最多触发多少个回填任务 | 10 个 |
注意：定时扫描触发是兜底方案，不是主力方案。扫描周期不要太短，否则集群压力大。我一般设 30 分钟到 1 小时。另外，扫描窗口要跟数据延迟时间匹配——如果数据本身就有 2 小时延迟，扫描窗口设 1 小时就没意义。
3.5 四种机制如何选型？
你可能会问：这么多机制，我到底用哪个？
我的建议是：按场景分层使用。
- 核心链路、高优先级任务：手动触发 + 定时扫描兜底。确保任何时候都能补，而且有人确认。
- 普通依赖任务：上游失败自动触发 + 数据质量告警触发。让系统自己处理大部分情况，减少人工干预。
- 低优先级、批量任务：只用定时扫描触发。每天扫一次，发现空洞就补，不占用太多资源。
嗯，这里要注意：不管用哪种机制，一定要有「熔断」机制。我曾经遇到过，某个数据质量问题导致回填任务反复触发，一晚上跑了 50 多次，把下游系统打挂了。后来我加了「同一任务同一时间段 24 小时内最多触发 3 次」的限制，问题才解决。
总结一句话：触发机制不是越多越好，而是越「准」越好。选对机制，回填效率翻倍；选错了，集群天天报警。