调度系统解决什么问题
调度系统负责在正确的时间、按正确的依赖顺序触发任务，并管理任务的状态、重试、告警与补数。与直接在服务器上写 crontab 相比，它把「这个任务今天跑没跑、跑到哪一步、失败了怎么补」变成可查询、可重跑、可审计的对象，而不是靠翻日志猜。
与 cron 的本质差别
cron 只回答「几点执行」，不关心上一次有没有成功、上游数据是否就绪、失败后怎么办。调度平台把任务抽象成节点、依赖抽象成边，于是可以表达「A 成功后才跑 B」「失败重试三次」「补跑 10 月 1 日到 10 月 7 日」这类需求，并留下每次运行的记录。
基本信息
| 核心能力 | 定时触发、依赖编排、失败重试、补数回填、可视化监控 |
|---|---|
| 与 cron 差异 | cron 只管时间点；平台管任务状态、依赖与重跑 |
| 常见平台 | Airflow、DolphinScheduler、XXL-JOB、Azkaban、DataWorks 调度 |
| 关键概念 | 工作流（DAG）、任务节点、调度周期、实例、补数 |
| 边界 | 平台负责「何时跑」，不负责数据正确性 |
能力对照
| 能力 | 裸 cron | 调度平台 |
|---|---|---|
| 触发时间 | 支持 | 支持，且可配置多套周期 |
| 依赖编排 | 靠 sleep 猜时间 | 显式依赖，上游成功才触发下游 |
| 失败处理 | 无状态，靠人发现 | 自动重试并可设置重试上限 |
| 补数 | 手写循环脚本 | 按日期区间一键回填 |
| 可观测 | 翻日志文件 | 界面查看每次运行状态与耗时 |
典型使用场景
- 日批链路：上游抽取成功后依次触发清洗、汇总与导出
- 小时级任务：按窗口产出指标，失败自动重试并在超时后告警
- 补数：按日期区间重跑受影响的任务及其下游
- 跨系统编排：调用数据同步工具、SQL 任务与脚本任务混合编排
- 依赖上游数据就绪：以「分区出现」作为触发条件，而不是固定时间
裸 cron 与平台的差别
裸 cron 与平台的差别
# 裸 cron 的典型写法与它回答不了的问题
0 2 * * * /opt/etl/run.sh >> /var/log/etl.log 2>&1
# 问题：失败没有状态；依赖靠 sleep 猜；补数靠手写循环；告警靠 grep 日志
# 调度平台的模型：任务=节点，依赖=边，状态可查，可一键重跑指定日期
# extract_orders → transform_orders → load_dwd → ads_sales_daily调度平台只能保证触发，不能保证上游数据已经就绪。真正的数据依赖要显式建模：以分区存在、文件落地或水位推进作为条件，而不是把时间往前推半小时。
把重要链路写成 crontab 串脚本，一旦失败没人知道停在哪一步；等到业务发现数据不对，往往已经积压好几天，补数也没有现成的重跑入口。