审计能力从哪来
慢变维度的审计靠两部分：维表内的审计列记录这一版本是哪个加载批次、什么时间、从哪个系统写进来的；独立的变更日志表记录哪个属性从什么值变成了什么值。只有当前快照的维度无法回答历史问题，报表口径出现争议时拿不出证据，质量问题排查只能靠猜。审计数据要按保留期规划时间分区，敏感属性的旧值还要做掩码，否则审计表本身会成为新的合规风险点。
基本信息
| 表内审计列 | load_batch、load_ts、src_sys、change_reason |
|---|---|
| 变更日志 | 按属性记录新旧值与发生时间 |
| 保留策略 | 按审计保留期做时间分区 |
| 脱敏要求 | 手机号、证件号等旧值需掩码存储 |
典型使用场景
- 客户等级调整后历史报表口径变化，需要查清是哪一批、哪天改的
- 内审或监管要求说明数据来源与加工过程
- 质量问题定位：确认某属性在特定日期是否已经正确入库
- 反查异常批量变更：某日新增版本数远超日常水平
- 新同事接手模型时，用审计列与变更日志快速理解属性的加工历史
变更日志建表
变更日志建表
-- 一个属性变化一行，便于按属性追溯
CREATE TABLE dim_customer_changelog (
customer_id string COMMENT '业务主键',
changed_col string COMMENT '变更属性名',
old_value string COMMENT '变更前值',
new_value string COMMENT '变更后值',
changed_at timestamp COMMENT '变更发生时间',
batch_id string COMMENT '加载批次'
) PARTITIONED BY (dt string) STORED AS ORC;审计列读法
| 列名 | 含义 | 异常表现 |
|---|---|---|
| load_batch | 写入该版本的加载批次 | 批次重复说明任务重跑且未做幂等 |
| load_ts | 该版本的入库时间 | 晚于业务生效时间说明链路延迟 |
| src_sys | 属性来源系统 | 空值则无法判断口径来源 |
| change_reason | 变更原因标注 | 长期为空说明审计只剩形式 |
审计列描述的是入库事实，不应被回刷覆盖：重跑任务时按批次覆盖对应分区，而不是整表重写时间列，否则「首次入库时间」会随重跑漂移。
审计与存储要权衡：审计列会加宽维度行，变更日志则随变更次数线性增长。常见做法是审计列常驻主表，变更日志只覆盖需要追溯的属性集合，并按保留期滚动清理分区。