4. 数据建模与数据仓库质量保障：维度建模、范式建模、数据质量规则嵌入
本章聚焦面试中最常被问到的三大核心：建模方法的选择逻辑、数据质量规则的体系设计，以及如何将规则无缝嵌入数仓开发流程。掌握这些，你能在架构设计和质量保障两类问题上拿下高分。
Q1：如何选择维度建模还是范式建模？请结合场景说明。
回答框架：先定义两种模型特点 → 列举典型适用场景 → 给出选择决策树（查多写少/写多查少/一致性要求） → 强调可混合使用（如星型+雪花）。
简短示例回答：“维度建模适合分析型业务，如电商销售报表，星型模型查询快且易理解；范式建模适合事务型系统，如订单状态更新，消除冗余。我会根据用户是分析师还是应用开发者来选择，必要时用维度模型作为宽表层，底层用范式存储事实。”（98字）
Q2：数据质量规则应如何嵌入数据仓库建模过程？
回答框架：按“建模时定义元数据约束 → ETL中实现校验规则 → 产出后监控告警”三阶段展开，并举例说明。
简短示例回答：“建模阶段在表设计里增加not null、unique、枚举值约束，并用主外键保证一致性。ETL阶段使用数据质量框架（如Great Expectations）对每个管道做行数校验、空值率扫描。最后通过实时仪表盘监控数据新鲜度和指标波动。”（95字）
Q3：请描述一条你设计过的数据质量规则，并说明如何保证其不成为性能瓶颈。
回答框架：先说明规则背景 → 技术实现方式（SQL校验/Spark校验） → 性能优化（分区裁剪/抽样/异步） → 失败后的降级策略。
简短示例回答：“在用户行为宽表中，我们需要确保user_id不出现空值且长度≥6。我们在ODS层用spark sql做count+where过滤，只扫描最近一天分区，单次任务控制在2分钟内。如果失败，停止下游加载并发送告警，同时保留异常数据到日志表供排查。”（98字）
📁 项目案例：电商全渠道订单数据仓库质量保障建设
| 项目名称 | 电商订单与履约数仓质量工程 |
| 业务背景 | 公司从单体数据库迁移至数据仓库，需要支撑日百万订单的实时分析，业务方频繁投诉报表数据延迟/空值/CPS不一致。 |
| 规模指标 | 日新增订单记录 200 万行，涉及 12 个业务系统，数据延迟要求 < 30 分钟，下游报表 40+ 张。 |
| 技术栈 | Spark (ETL), Hive/ClickHouse, Airflow, Great Expectations, Kafka, 自研元数据中心 |
| 核心难点 | 多源异构订单数据的主键一致性、订单金额跨系统校验、异常订单的实时阻断与回溯分析。 |
- “你们如何定义‘高质量’的订单数据？用什么指标衡量？”
- “如果某个维度表的缓慢变化维更新错误，怎么影响下游事实表？”
- “在实时流中如何嵌入质量规则？如果出现脏数据，你会暂停管道还是二次清洗？”
“在建模阶段我们采用星型+雪花混合模型，事实表只保留订单粒度的ID和金额，维度表做SCD2。质量规则分层落地：ODS层做字段完整性和主键唯一性（批处理加基表校验）；DWD层做业务一致性校验（如订单金额=商品小计+运费）；DWS层做指标波动监控。遇到20%以上异常时切断下游，由值班人员人工确认后通过回刷重新生产数据。”（约140字）
📊 知识结构：维度建模 vs 范式建模 核心对比
| 对比维度 | 维度建模 (星型/雪花) | 范式建模 (3NF/雪花) |
|---|---|---|
| 设计目标 | 查询性能 + 业务易用 | 数据一致性 + 减少冗余 |
| 适用场景 | 分析报表、BI看板 | 事务系统、高更新频率 |
| 数据质量问题典型风险 | 维度表缓慢变化维导致数据回溯困难 | 多表关联易产生不一致，JOIN成本高 |
| 质量规则嵌入难度 | 低，规则集中在事实表聚合 | 高，需逐表校验外键/级联约束 |
| 典型大数据架构组合 | Star Schema + OLAP引擎 | 3NF + 关系型数据库 + 增量CDC |
- 建模选型一定要结合业务场景的读/写比例、延迟要求、下游用户类型。
- 质量规则不是事后添加，需在建模时设计字段约束和元数据标注。
- 面试官喜欢听“当规则失败时的策略”和“性能优化方案”，这两个细节是加分项。
- 项目案例中强调数据量、技术栈、规则分层，体现工程落地能力。