调度依赖该怎么设计
调度依赖要表达「数据准备好了没有」，而不是「某个任务跑完了没有」。因此首选表级加分区级的产出依赖：上游分区写入并注册成功后，下游才启动，判据通常是分区存在且行数大于 0。跨引擎链路（Hive 产出、Spark 或 Flink 消费）用就绪文件或元数据事件衔接。依赖设计只需检验两件事：重跑上游时下游能否自动跟随，上游延迟时下游是等待而不是空跑。
基本信息
| 依赖粒度 | 表级加分区级，而不是任务名 |
|---|---|
| 就绪判据 | 目标分区存在且行数大于 0 |
| 跨引擎衔接 | 就绪文件或元数据事件，如 _SUCCESS 标记、分区注册消息 |
| 应避免的做法 | 依赖任务名硬编码、人工等待、固定时间盲跑 |
| 补数要求 | 重跑上游能自动级联下游 |
| 巡检动作 | 定期清理孤儿任务与无人消费的产出表 |
| 常见平台机制 | Airflow 的外部任务传感器与 Dataset、DolphinScheduler 的依赖节点、DataWorks 的跨周期依赖 |
典型使用场景
- 同引擎链路：上游 Hive 表产出当天分区后触发下游作业，靠分区就绪探测
- 跨引擎链路：上游写就绪文件，下游监听到标记文件再启动，避免读半成品
- 补数级联：重跑上游分区后，下游依据依赖自动重跑对应日期
- 上游延迟：下游进入等待而不是按固定时间开跑，减少空跑与人工干预
- 链路巡检：定期找出无人消费的产出任务，及时下线减少维护面
依赖表达方式优先级
依赖表达方式优先级
# 依赖表达方式，从推荐到不推荐
1) 表分区就绪依赖（推荐）：上游注册分区后触发下游
-- 就绪判据：分区存在且行数大于 0
SELECT count(1) FROM ods_order WHERE dt = '2026-10-12';
2) 就绪文件：上游写 _SUCCESS 或 _READY 文件，跨引擎通用
3) 任务名依赖：仅在没有表产出的流程步骤里使用，改动需同步
4) 固定时间等待（不推荐）：上游一旦延迟，整条链路必然出错依赖方式对照
| 方式 | 触发依据 | 可重放性 | 适用场景 |
|---|---|---|---|
| 表分区就绪 | 分区存在且行数大于 0 | 好，补数自动级联 | 有表产出的主要链路 |
| 就绪文件 | 上游写入标记文件 | 好 | 跨引擎或对象存储链路 |
| 任务名依赖 | 上游任务实例状态 | 一般，改名后失效 | 无表产出的流程步骤 |
| 固定时间等待 | 时钟 | 差 | 临时应急，不宜用于生产 |
人工依赖（等某个同事确认、等群里通知）让链路无法重放。补数时每个环节都要人工触发，既慢又容易漏，应尽早改造成数据就绪探测。
只判断上游任务成功是不够的：任务成功但产出空分区的情况很常见，就绪判据里带上行数校验，才能把「跑完」和「有数据」区分开。