生效日期的两种选择
拉链版本的生效时间可以用两种时间：业务变更时间（由来源系统提供，如客户在 CRM 里改等级的实际时点）或数仓写入时间（维表加载时的系统时间）。业务时间更贴近分析口径，能还原『变更发生在哪一天』，但完全依赖来源变更时间的可靠性；系统时间容易获取且不会缺失，但整体会滞后到加载日，跨期归因会出现偏移。关键原则是同一维度内只选一种并写入文档。
基本信息
| 业务时间 | 口径准确，需要来源提供可靠变更时间 |
|---|---|
| 系统时间 | 易获取且不缺失，分析口径存在偏移 |
| 选择原则 | 同一维度内统一一种，并在文档中标注局限 |
| 常见折中 | 来源可信则用业务时间，否则用系统时间并记录来源时间 |
| 影响面 | 版本区间划分与历史报表口径 |
典型使用场景
- CRM 变更日志可用：用业务变更时间落版本，历史等级口径可精确回放
- 仅提供批量快照：用系统时间落版本，并在文档中说明跨期偏差范围
- 审计场景：业务时间与实际业务动作对齐，追溯过程可被外部验证
- 多来源合并：不同来源时间质量不一，需在集成层统一换算或标记
- 口径切换：从系统时间改为业务时间时，必须评估历史区间是否需要回刷
时间来源判断
时间来源判断
来源提供可靠变更时间（如 CRM 变更日志、CDC 事件时间） # 优先业务时间
-> 版本 start_date = 业务变更时间，分析与业务动作严格对齐
仅有批量全量导出，无变更时间字段 # 只能用系统时间
-> 版本 start_date = 加载日期，文档中标注口径局限
两种来源混用同一维表 # 高风险
-> 版本区间可能重叠或倒退，必须统一为一种或明确字段标记两种时间对照
| 判断项 | 业务时间 | 系统时间 |
|---|---|---|
| 准确性 | 贴合业务实际动作 | 滞后到加载日 |
| 可用性 | 依赖来源提供且质量可控 | 几乎总能获取 |
| 跨期分析 | 可按真实时点还原口径 | 存在整体偏移 |
| 实现成本 | 需处理时区与乱序 | 直接取加载时间，实现简单 |
同一维度内混用两种时间是最隐蔽的问题：表面数据都在，但版本区间可能出现重叠或倒退，区间唯一性校验会以失败告终，而修复要重新回刷整张维表。
用业务时间时还要统一时区与精度：来源用 UTC、数仓按本地日期分区时，跨零点的变更会被归到前一天，日粒度报表口径随之偏移。