时间口径必须统一
维度版本的生效时间取源端变更时间还是批处理时间，全仓必须统一。事实按业务发生时间对齐维度版本，补数与重放才可复现；若用处理时间做生效时间，同一天重跑会得到不同的版本，报表数字会随重跑而变化。
基本信息
| 生效时间 | 优先取源端业务变更时间 |
|---|---|
| 事实解析 | 按业务发生时间落在维度区间内 |
| 补数要求 | 重放同一批次结果必须可复现 |
| 常见偏差 | 用处理时间当生效时间，补数结果漂移 |
| 验证方式 | 同一批重跑两次结果完全一致 |
典型使用场景
- 事实关联：订单按下单时间匹配当时的客户等级
- 历史回溯：任何时点查询都能还原当时的维度状态
- 补数重跑：重放历史数据时结果与首次执行一致
- 口径审计：证明报表数字与业务发生时间一致
- 迟到变更：明确是否回写历史版本及回写后的重算范围
按业务时间解析版本
按业务时间解析版本
-- 区间左闭右开：业务时间落在起始与结束之间
SELECT o.order_id, c.customer_sk, c.tier
FROM fact_order o
JOIN dim_customer c
ON o.customer_id = c.customer_id
AND o.dt >= c.start_date
AND o.dt < c.end_date;三种时间的用途
| 时间类型 | 来源 | 用途 |
|---|---|---|
| 业务发生时间 | 源系统单据时间 | 事实与维度对齐的基准 |
| 生效时间 | 源端变更时间或批次日 | 维度区间的边界 |
| 处理时间 | 任务执行时间 | 仅用于审计，不参与口径 |
用处理时间会在补数与重跑时得到不同版本：同一批数据两次运行落在不同的生效区间，口径不可复现，问题极难定位。
迟到变更回写历史版本后要重算对应事实：维度改了而事实仍指向旧代理键，回溯查询会出现前后矛盾的结果。
生效时间的精度要统一到日或秒：维度按天生效而事实按秒对齐时，同一天内的多笔业务可能匹配到不同版本，结果无法解释。