两个容易混淆的日期
业务日期（bizdate）指数据归属哪一天；运行时间指任务实际在几点执行。日批任务通常运行在 T+1 的凌晨，处理的是 T 这一天的数据，两者永远差一天。调度平台通过参数把业务日期注入任务，任务内部不再自己算日期。
为什么必须区分
补数是暴露问题最集中的场景：任务里写「当前日期减一天」的写法，在补跑一个月前的数据时会去读昨天的分区，要么读不到数据、要么写到错误的分区覆盖了别的日期。用调度参数注入业务日期，补数时只需改参数，不用改代码。
两种日期对照
| 概念 | 含义 | 示例 |
|---|---|---|
| 业务日期（bizdate） | 数据归属的日期 | 2026-10-11 的数据 |
| 运行时间 | 任务实际触发的时刻 | 2026-10-12 凌晨 02:00 |
| 数据区间 | 本次任务处理的时间范围 | [2026-10-11 00:00, 2026-10-12 00:00) |
| 参数注入 | 由调度平台传入，任务不自己计算 | ${bizdate} 或 {{ ds }} |
基本信息
| 业务日期 | 数据归属日期，日批通常为昨天 |
|---|---|
| 运行时间 | 调度实际触发的时刻 |
| 传递方式 | 调度参数（如 ${bizdate}、{{ ds }}）注入 SQL |
| 补数影响 | 参数化后改参数即可回填历史，不需要改代码 |
| 跨天任务 | 需要明确约定归属哪一天，并在链路上保持一致 |
典型使用场景
- 日批读取：按业务日期读取当天分区，写入对应日期的结果分区
- 补数：把业务日期设为历史某天，重跑当天的链路
- 跨天任务：23:50 开始、次日 00:20 结束的任务，明确归属哪一天
- 多时区业务：统一以某个时区确定业务日期边界
- 对账核对：确认上下游任务使用的是同一个业务日期口径
参数传递示例
参数传递示例
-- 每天 02:00 执行的 SQL：dt 取业务日期，而不是运行日期
SELECT * FROM ods_orders
WHERE dt = '${bizdate}'; -- 例如 2026-10-11，实际运行在 10-12 凌晨
-- 写入时同样使用业务日期，保证分区与数据归属一致
INSERT OVERWRITE TABLE dwd_order_di PARTITION (dt = '${bizdate}')
SELECT order_id, amount FROM ods_orders WHERE dt = '${bizdate}';调度平台参数差异
调度平台参数差异
# 不同平台的内置参数名称不同，迁移时需要逐条核对
# 常见形式：
# ${bizdate}、${yyyymmdd} 部分平台的业务日期参数
# {{ ds }} Airflow：数据区间开始日期（周期内）
# ${system.biz.date} DolphinScheduler：业务日期
# 通用原则：任务里只引用平台参数，绝不写“当前日期减一天”Airflow 的周期语义是把「运行时间」放在数据区间结束之后：一个标记为 10 月 12 日运行的日任务，处理的是 10 月 11 日的数据区间。理解这一点，才不会把两条链路的日期参数对齐错。
时区不一致会让业务日期整体偏移一天：本地时间与 UTC 混用时，边界时刻的任务可能算到相邻日期，写入错误分区并覆盖已有数据。