建模评审与上线检查
新表上线前过一遍评审：确认是否真的需要新表、主题域与分层归属、粒度与唯一键、命名规范、分区与生命周期策略、指标口径是否与字典一致、血缘与责任人是否登记。团队规模小时可以用检查清单替代正式评审会，但清单要真的填，并且把口径核对与粒度校验作为必填项。评审的目标不是增加流程，而是让表在上线时就具备被复用的条件；没有这个环节，重复表与同义不同名会快速堆积。
基本信息
| 评审内容 | 分层与主题域、粒度与主键、命名、分区、口径、血缘 |
|---|---|
| 形式 | 评审会或上线检查清单，按团队规模选择 |
| 必填项 | 粒度声明、口径与指标字典一致性核对 |
| 交付物 | 检查清单记录与口径说明，随表登记 |
| 目的 | 让表上线即具备被复用的条件 |
典型使用场景
- 新表上线评审：确认粒度与主键并加入每日稽核
- 新增指标评审：口径与既有指标是否重复或冲突
- 大表重构评审：确认下游影响面与切换方案
- 集市新增需求评审：判断能否复用公共层而不是新建表
- 季度治理回顾：按清单抽查已上线表是否符合规范
上线检查清单
上线检查清单
[ ] 表名符合命名规范（分层_主题域_业务描述_周期）
[ ] 分层与主题域归属明确，确认无法复用既有表
[ ] 粒度与唯一键已声明，并有可执行的校验 SQL
[ ] 字段有注释，枚举有取值说明
[ ] 指标口径与指标字典一致（列明引用条目）
[ ] 分区策略与生命周期已确定
[ ] 血缘与元数据已登记，负责人已明确
[ ] 下游已通知并有对接人常见评审问题
| 问题 | 典型表现 | 影响 | 处理建议 |
|---|---|---|---|
| 粒度不清 | 没说清一行代表什么 | 下游重复或漏统计 | 先声明粒度再建表 |
| 口径重复 | 与既有指标算法不同 | 同名不同数 | 先查字典再新增 |
| 命名随意 | 同义不同名 | 找不到表，重复开发 | 按规范改名后再建 |
| 无负责人 | 登记为空 | 无人应答口径问题 | 指定到人 |
| 无校验 | 上线即无稽核 | 问题长期潜伏 | 补充粒度校验 SQL |
评审的目标不是增加流程，而是让表在上线时就具备被复用的条件：粒度、口径、负责人三项写清楚，后续沟通成本能下降一大半。
评审只走形式不核对口径时，问题会在上线后暴露，返工成本远高于评审时多问两句。
不评审直接建表的后果是重复表与同义不同名快速堆积，数据地图上搜出五张相似表，使用者只能凭运气选。