跟踪列为什么要登记
并非所有属性都值得产生新版本：姓名、等级、手机号这类变化需要历史追溯，而最近登录时间、登录次数这类高频且无历史分析价值的字段只会让版本数量爆炸。把跟踪列与忽略列显式登记进维度设计文档，能防止后续开发悄悄加列，导致全表被判定为变更。
基本信息
| 跟踪列 | 姓名、手机号、等级、地址等有历史价值的属性 |
|---|---|
| 忽略列 | 最近登录时间、登录次数等高频字段 |
| 忽略列处理 | 按类型 1 覆盖，或干脆不落维表 |
| 登记位置 | 维度设计文档与数据字典 |
| 变更要求 | 新增跟踪列前评估对历史指纹的影响 |
典型使用场景
- 维度设计评审：明确哪些属性进入 SCD2 跟踪范围
- 版本数量控制：避免高频字段造成版本爆炸与存储膨胀
- 指纹规则变更：新增跟踪列时评估历史数据是否需要重算
- 开发对照：ETL 按清单生成变更检测语句，不各写一套
- 问题排查：版本异常增多时先核对跟踪列清单是否被改动过
跟踪列清单
跟踪列清单
# 维度跟踪列清单（登记在维度设计文档中）
跟踪列：name, phone, tier, address
忽略列：last_login_ts, login_cnt
忽略列处理：类型 1 覆盖，或只落行为事实表
变更记录：新增跟踪列需评审并重算历史指纹三类列的判断
| 列类型 | 判断依据 | 处理方式 |
|---|---|---|
| 跟踪列 | 变化慢且有历史分析价值 | SCD2 产生新版本 |
| 类型 1 列 | 需要纠正但不影响历史 | 直接覆盖全表 |
| 忽略列 | 高频且无历史价值 | 不落维表或只落行为事实表 |
跟踪列变更要评审：加入新列时需评估对历史指纹的影响，通常按新规则重算全量指纹，否则新旧规则混用会让历史数据全被判为变更。
指纹拼接的字段顺序要固定：同一组字段换个顺序就会算出不同指纹，重跑时全表产生伪变更，排查起来非常费时。