什么时候要全量重放
当跟踪规则调整、来源补全历史、或者维度表本身被破坏时，需要按源端变更日志从最早变更点逐批执行合并逻辑，重建完整的版本链。前提是源端保留变更日志或 CDC 记录；重放使用的合并代码必须与日常加载完全相同，否则两套逻辑迟早出现差异。
基本信息
| 前提条件 | 源端有变更日志或 CDC 记录 |
|---|---|
| 执行步骤 | 备份维表、逐批重放、逐环对账、切换消费 |
| 代码复用 | 重放与日常加载共用同一套合并逻辑 |
| 校验内容 | 版本区间连续、无重叠、每键单当前行 |
| 主要风险 | 重放期间下游读到中间状态 |
典型使用场景
- 跟踪列变更：新增跟踪属性后按新规则重建历史
- 历史补全：源端补传早期数据后重放生成完整版本
- 损坏修复：维表被误删或写坏后重放恢复
- 逻辑升级：修复合并逻辑缺陷后重建受影响区间
- 环境初始化：新建环境时按变更日志生成维度
全量重放流程
全量重放流程
# 全量重放的四步
1. 备份当前维表，保留可回滚的副本
2. for batch in 变更日志按时间排序:
merge_dimension(batch) # 与日常加载共用同一套逻辑
3. 校验：版本区间连续、无重叠、每键仅一个当前行
4. 切换：校验通过后再让下游切换到重建结果四阶段与风险
| 阶段 | 关键动作 | 风险 |
|---|---|---|
| 准备 | 备份现有维表 | 不备份则无法回滚 |
| 重放 | 按批执行合并逻辑 | 代码与日常加载不一致 |
| 校验 | 区间连续性与唯一当前行 | 跳过校验直接上线 |
| 切换 | 下游改用重建结果 | 重放期间被下游读取 |
重放脚本与日常合并要共用同一份代码：两份实现迟早产生差异，届时无法判断哪一份结果才是正确的。
重放期间要隔离下游读取：中间状态的版本链并不完整，报表会出现同一实体重复计数或缺少当前行。