数据模型评审
总结
| 记忆点 | 内容 |
|---|---|
| 为什么评审 | 上线容易下线难，一开始就要审好 |
| 基础规范 | 命名 + 注释 + 分区 |
| 模型设计 | 粒度唯一 + 避免重复建设 + 上下游清晰 |
| 数据质量 | 主键唯一 + 回刷验证 + 异常兜底 |
| 落地方式 | 自检 → Peer Review → 上线验证 → 文档归档 |
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
进阶 | 大数据面试 · 数仓建模系列
| 面试真题 你们团队新建一张数仓表，上线前有什么流程？怎么保证模型质量？ |
|---|
为什么需要模型评审？
因为上线容易，下线难。一张表上线之后，下游很快就会有人依赖它。等你发现粒度定错了、命名不规范、冗余太多想改的时候，下游已经挂了5张报表和2个接口。改一张表要协调7个人，不如一开始就审好。
| Wood的实战经验 我之前接手一个项目，有张dws表建的时候没有评审，粒度混了「订单」和「订单明细」，金额字段聚合出来一直是错的。等发现时下游已经有十几张报表在用，最后花了一周时间做数据迁移才改过来。 从那以后我就在团队里推了模型评审机制。说实话一开始同事们觉得麻烦，但跑了一个月之后，线上数据问题减少了大约一半，大家都认可了。 |
|---|
我的评审Checklist：10个必查项
一、基础规范（3项）
① 命名是否符合规范？对照DAY 8的命名公式：层级_业务域_主题_描述_时间粒度。不符合的打回去改。
② 表注释和字段注释是否完整？每张表必须有表级注释说明用途，每个字段必须有COMMENT。没注释 = 没文档 = 三个月后谁都看不懂。
③ 分区设计是否合理？日增量/日全量表必须有dt分区。数据量大且有明确业务过滤维度的加二级分区。避免过度分区（三级以上要有充分理由）。
二、模型设计（4项）
④ 粒度是否明确且唯一？这是最重要的一项。一行数据代表什么？必须能一句话说清楚。粒度模糊 → 下游使用混乱 → 数据膨胀/重复计算。
⑤ 是否有重复建设？新建表之前先查：有没有已有的表能满足需求？或者在已有表上加几个字段就行？我见过团队里3个人各自建了一张用户画像表，字段重叠了70%。
⑥ 上下游关系是否清晰？这张表的数据从哪来？谁在用？上游表延迟了，SLA怎么保证？
⑦ 维度关联是否正确？拉链表是否加了时间范围过滤？维度表主键是否唯一？外键是否有NULL？
三、数据质量（3项）
⑧ 有没有数据质量校验？上线前至少要有：主键唯一性检查、行数波动检查（波动超过20%告警）、关键字段NULL率检查。
⑨ 历史数据是否回刷验证？新表不能只跑当天数据就上线。至少回刷7天数据，和已有报表/源表交叉验证，确认数值一致。
⑩ 异常情况有没有兜底？上游表没数据时下游怎么处理？数据量突增10倍时资源能不能扛住？
| -- 主键唯一性检查 SELECT user_id, dt, COUNT(*) FROM dws_xxx GROUP BY user_id, dt HAVING COUNT(*) > 1; -- 关键字段NULL率检查 SELECT COUNT(*) AS total, SUM(CASE WHEN pay_amount IS NULL THEN 1 ELSE 0 END) AS null_cnt FROM dws_xxx; |
|---|
评审流程怎么落地？
不需要搞得很重，我的做法是轻量但有效：
1. 开发者自检 → 对照Checklist自查一遍（10分钟）
2. Peer Review → 找一个同事过一遍设计文档（15分钟）
3. 上线验证 → 回刷数据 + 对数 + 质量校验通过
4. 文档归档 → 表信息录入元数据系统
整个流程加起来不到1小时，但能避免上线后花一周修问题。
| 面试加分提示 这题考的是你的工程规范意识和团队协作能力，中高级岗位必问： 「我们团队有一套模型评审机制，我负责推动建立的。核心是一个10项Checklist，覆盖命名规范、粒度定义、上下游关系、数据质量校验四个维度。每张新表上线前需要开发者自检+一个同事Review，回刷至少7天数据对数通过才能上线。推行之后线上数据质量问题减少了大约50%。」 重点：不只是你个人能力，而是你推动了团队规范化。这是管理者思维，也是晋升的加分项。 |
|---|