📚 课程目录第4章数据仓库建模实战案例

第4章数据仓库建模实战：星型/雪花模型、维度建模、缓慢变化维

数据仓库建模是数据平台负责人的核心能力之一。面试中不仅考察你是否会画星型模型，更关注你在业务变化、数据一致性、查询性能之间的权衡决策。本章从实战角度拆解高频追问，帮你构建“可落地的建模思维”。

维度	具体内容
回答框架	1. 定义两种模型的核心区别（维表是否直接与事实表相连）；2. 给出选择依据： • 星型：查询性能优先、维度不复杂、ETL 维护简单 • 雪花：数据一致性要求高、维度表有层级（如多级区域）、存储节省但不明显 3. 强调业务场景驱动：大部分互联网数仓优先星型，金融/监管场景可能用雪花
简短示例	“在电商订单模型里，我选了星型。因为下单、支付、退款等事实表需要频繁 join 用户和商品维度，雪花会增加 join 层数和查询延迟；而且人员流动大，维护多级维度代价高。”
追问	• 如果业务要求所有维度数据必须规范化（如银行监管），你如何平衡？ • 雪花模型变宽后，你怎么优化？ • 你遇到过大宽表完全替代星型模型的情况吗？
避坑	❌ 不要只说“星型好”。面试官想听你了解雪花的使用场景。 ❌ 不要混淆“维度退化”与“雪花模型”，前者是维度字段直接放入事实表。

💡 加分点：引出“桥接表”或“星座模型”应对多对多关系，展示进阶知识。

维度	具体内容
回答框架	1. 简述三种类型： • 类型1：直接覆盖，不保留历史 • 类型2：新增行，保留历史（有效日期、有效期标志） • 类型3：新增列（原值/新值），保留有限历史 2. 决策依据： • 业务是否需要回溯历史（如用户手机号变更后看旧订单）→ 类型2 • 维度字段是否经常变 → 避免类型2膨胀 • 只需要看“变化前 vs 变化后”对比 → 类型3 或类型2 + 拉链表
简短示例	“用户上次登录时间用类型1；用户所在城市变化需要分析历史销量，我用类型2，加上 valid_from/valid_to，查询时用 <= order_date。对于产品分类调整，新增旧分类列用类型3。”
追问	• 类型2每天百万级变更怎么处理？（合并写入、分区交换） • 如果不允许修改历史事实，但维度属性变了，你怎么设计？ • 拉链表与类型2的关系？
避坑	❌ 不要无脑全用类型2。类型2占用大量存储，需要评估变化频率。 ❌ 不要忽略“缓慢”的含义——对高频变化字段应该用事实表存储快照。

⚠️ 注意：面试官喜欢追问“你如何判断变化频率？”，可答：计算字段历史 distinct 值/时间分区数量，设定阈值。

维度	具体内容
回答框架	1. 事实表设计原则： • 粒度声明（每个事实行代表一次业务事件） • 可加性事实（金额、数量）与半可加性（账户余额） • 无重复度量（避免冗余计算） 2. 维度表设计原则： • 代理键（替代业务主键） • 维度退化（如订单号直接放入事实表） • 层次维度（如日期维度包含年/季/月/日） 3. 案例：订单事实表（粒度=每个商品行），包含 order_id、product_sk、user_sk、amount、quantity
简短示例	“之前设计佣金模型，先把结算粒度定为‘一笔结算记录’，然后拆分出结算日期维度、商家维度、商品维度。为了避免维度表过多，把结算状态这种枚举值直接退化到事实表。”
追问	• 事实表里何时使用“退化维度”？ • 维度表如果超过50个字段怎么优化？（垂直拆分、雪花化） • 如何处理多币种/多单位事实？
避坑	❌ 不要忘记代理键！否则业务主键变更会导致维度表数据断裂。 ❌ 不要将业务逻辑（如会员等级计算）放入维度表，应放入事实表或宽表中。

🎯 面试官画像：通常来自数据平台或数据工程团队 leader，关注你能否在 5-10 分钟内把建模方案讲清楚，并给出 trade-off 的决策依据。

公司类型	模型偏好	SCD 倾向	关注点
大厂（字节/阿里/腾讯）	星型为主，部分场景用星座模型	类型2配合拉链表，自动化 merge	查询性能、数据一致性、日增量处理
金融/银行	雪花模型偏多，监管审计要求	类型2+历史快照表	可追溯性、数据血缘、缓慢变化全记录
中型互联网（滴滴/快手）	星型+宽表混合，快速迭代	类型1/2混合，业务部门共同决定	开发效率、模型复用性、维度膨胀控制
初创/成长型	先上宽表，逐步维度化	类型1居多，后期再改造	上线速度、最小设计、后期重构成本

📌 进阶建议：准备一个你主导的建模项目，用 STAR 法描述：背景是业务爆炸增长，旧模型性能瓶颈；任务是要重构；行动是你如何选择模型、设计维度、处理SCD；结果查询效率提升 3 倍，数据一致性达到 100%。

第4章 数据仓库建模实战：星型/雪花模型、维度建模、缓慢变化维