4. 任务调度触发机制：定时调度、依赖触发、手动触发、事件驱动触发、数据触发
调度触发，说白了就是回答一个问题：这个任务什么时候该跑？
我见过不少团队，上来就写 Cron 表达式，结果跑着跑着发现数据对不上。为什么？因为触发方式选错了。今天咱们就把五种触发机制掰开揉碎讲清楚。
核心观点：没有万能的触发方式。一个成熟的数据平台，往往是多种触发机制的组合使用。选对触发方式，比调优执行参数更重要。
4.1 定时调度（Cron 表达式）
这是最基础、最常用的触发方式。你写一个 Cron 表达式，系统到点就执行。简单粗暴，但坑也不少。
我个人习惯把 Cron 表达式拆成五段来记：分 时 日 月 周。从左到右，精度到分钟。
| 位置 | 含义 | 取值范围 | 特殊字符 |
|---|---|---|---|
| 1 | 分钟 | 0-59 | , - * / |
| 2 | 小时 | 0-23 | , - * / |
| 3 | 日 | 1-31 | , - * ? / L W |
| 4 | 月 | 1-12 | , - * / |
| 5 | 周 | 0-7（0和7都代表周日） | , - * ? / L # |
常用示例：
0 0 2 * * ?— 每天凌晨 2 点执行0 0/30 8-18 * * ?— 每天 8 点到 18 点，每 30 分钟执行一次0 0 0 1 * ?— 每月 1 号零点执行
我曾经踩过一个坑：用 0 0 0 * * 1 想表达「每周一零点执行」，结果发现每月 1 号也触发了。为什么？因为「日」和「周」同时有值时，是 或 的关系。正确写法应该是 0 0 0 ? * 1，用 ? 把「日」置为无意义。
避坑指南：
- 避免在整点前后 5 分钟集中调度，容易造成资源洪峰
- 夏令时切换日，Cron 可能跳过一次或重复执行一次
- 分布式环境下，注意同一 Cron 表达式可能被多个调度器同时触发
4.2 依赖触发
你想想看，一个数据报表任务，上游是 ETL 清洗任务。ETL 没跑完，报表跑出来也是错的。依赖触发就是解决这个问题的。
依赖触发有两种常见模式：
- 任务级依赖：等待上游某个任务执行成功（或失败）
- 分区级依赖：等待某个数据分区就绪（比如 Hive 分区
dt=2024-01-01）
我在项目中遇到过最头疼的场景：A 依赖 B，B 依赖 C，C 依赖 A——循环依赖。调度器直接死锁。解决方案是引入 虚拟节点 或 数据就位标记 来打破循环。
最佳实践：依赖触发不要超过 3 层。超过 3 层时，建议拆分为子工作流，用子工作流的状态作为依赖条件。
4.3 手动触发
手动触发，说白了就是「人肉点一下」。听起来简单，但设计不好会出大问题。
我见过一个平台，手动触发按钮没有任何权限校验，实习生点了一下，把生产环境的全量数据重跑了一遍……嗯，那天晚上整个数据团队都没回家。
手动触发应该满足三个条件：
- 权限控制：只有运维和负责人能操作
- 幂等性：同一个任务手动触发多次，结果应该一致
- 审计日志：谁、什么时间、为什么手动触发，都要记录
使用场景：
- 数据回溯：补跑历史数据
- 故障恢复：修复后重新执行失败任务
- 调试测试：验证新逻辑是否正确
4.4 事件驱动触发
事件驱动触发，就是「当某件事发生时，自动触发任务」。这件事可以是：
- Kafka 消息到达某个 Topic
- Webhook 回调
- 文件上传到指定目录
- API 接口调用
我个人比较喜欢事件驱动，因为它 实时性高，而且能解耦。比如实时数仓场景，一条订单消息过来，立刻触发数据清洗、聚合、写入——全程不需要人干预。
但要注意：事件驱动容易引发 风暴。我曾经遇到一个场景，上游系统一秒发了 10 万条消息，调度器直接被打挂。后来加了 限流 和 去重 才稳住。
关键设计点：
- 事件丢失怎么办？——需要消息队列的持久化机制兜底
- 重复事件怎么办？——任务本身要支持幂等
- 事件积压怎么办？——设置最大并发数，避免雪崩
4.5 数据触发
数据触发和依赖触发有点像，但更「数据驱动」。它不是等任务完成，而是等 数据本身满足条件。
常见的判断条件：
| 条件类型 | 说明 | 示例 |
|---|---|---|
| 分区存在 | 检测某个 HDFS 分区目录是否存在 | /user/hive/warehouse/orders/dt=2024-01-01 |
| 数据量达标 | 检测表记录数是否超过阈值 | SELECT COUNT(*) > 10000 |
| 数据质量通过 | 检测数据质量规则是否全部通过 | 空值率 < 5%，唯一性校验通过 |
| 时间窗口关闭 | 等待某个时间窗口的数据全部到达 | 等待 5 分钟窗口内的所有日志到达 |
数据触发有一个经典问题：轮询 vs 回调。轮询就是每隔几分钟去查一下数据状态，回调是数据就绪时主动通知调度器。我个人建议：
- 数据延迟可控的场景用 轮询，实现简单
- 数据延迟不确定、对实时性要求高的场景用 回调，但需要数据源支持
我的经验：数据触发最适合「上游不可控」的场景。比如第三方数据源，你不知道它几点送数据来。用数据触发，数据到了就自动跑，不到就不跑，省心省力。
4.6 混合触发策略
实际生产中，很少只用一种触发方式。我给大家看一个典型的混合触发配置：
任务：每日营收报表
触发方式：
1. 定时调度：每天 08:00 尝试触发（Cron: 0 0 8 * * ?）
2. 数据触发：等待「订单表当日分区」数据量 > 0
3. 依赖触发：等待「ETL 清洗任务」执行成功
4. 手动触发：运维人员可随时补跑
执行逻辑：
- 08:00 到达时，先检查数据触发条件
- 条件满足，再检查依赖触发条件
- 都满足，开始执行
- 如果 08:00 条件不满足，每 5 分钟重试一次，最多重试 12 次
- 超过 12 次仍未满足，发告警通知人工介入这种设计的好处是：既保证了时效性，又保证了数据正确性，还有兜底机制。
设计原则：
- 定时调度做「保底」，确保任务最终会跑
- 依赖触发和数据触发做「校验」，确保数据正确
- 手动触发做「兜底」，应对异常情况
- 事件驱动做「加速」，提升实时性
嗯，触发机制就讲到这里。记住一句话：触发方式没有好坏，只有合不合适。选对了，调度系统稳如老狗；选错了，天天半夜起来修数据。