清单解决什么问题
维度表一旦被事实表引用并进入报表，粒度、键、跟踪列的任何改动都会牵连下游，所以维度设计评审是上线前拦住口径问题的关卡。清单不只看表结构，还要看特殊成员是否就位、质量规则是否配置、对账方案是否可执行、责任人是否明确。评审通过后记录归档，后续每次变更以此为基线。
基本信息
| 评审时机 | 首次上线 / SCD 类型变更 / 跟踪列增删 |
|---|---|
| 参与角色 | 数据建模、业务方、数据质量 |
| 产出物 | 评审记录、责任人、生效版本号 |
| 阻断条件 | 自然键不唯一或非空约束缺失 |
典型使用场景
- 新建维度表上线前逐项核对，避免「未知成员未建」这类问题拖到事实加载时才暴露
- 现有维度新增跟踪列（客户等级、门店状态）时评估下游报表与缓存影响
- SCD 类型由 1 型调整为 2 型时，评审历史版本的回溯口径与存储代价
- 跨团队共享维度（组织架构、商品类目）变更前做多方口径确认
- 质量问题复盘后把新校验项补进清单，形成可复用经验
评审清单
评审清单
# 维度评审最小清单
1 自然键唯一且非空，粒度与事实可对齐
2 SCD 类型与生效、失效时间列定义一致
3 未知成员与不适用成员已建，代理键固定
4 命名与注释规范，中文名可检索
5 质量规则与告警阈值已配置到监控
6 下游影响面清单与对账方案已确认
# 全部通过才允许发布到生产库评审项对照
| 评审项 | 检查方法 | 不通过的后果 |
|---|---|---|
| 粒度与键 | 抽样比对源系统唯一性 | 事实加载丢行或重复计数 |
| SCD 与跟踪列 | 抽查变更记录的版本区间 | 历史回溯查不到当时属性 |
| 质量规则 | 在测试环境触发异常用例 | 脏数据静默进入下游报表 |
| 变更记录 | 确认评审记录已归档 | 口径争议时无据可查 |
紧急变更可以走加急评审，加急只压缩评审时间，不减少检查项；被跳过的检查项最终会以下游对账差异的形式暴露，代价更高。