数据仓库建模实战面试
面试回答框架图
面对维度建模类题目，按以下5步结构化回答，既体现系统性又展示项目落地能力。
缓慢变化维策略选择图
面试中常让你根据业务场景推荐SCD策略，以下决策树可直接套用。
面试问答卡片
📌 问题1：请介绍维度建模核心概念，并对比星型模型与雪花型模型的适用场景。
考察点：对维度建模底层理解；模型选择与业务场景匹配能力；日常项目是否深入思考。
回答框架：
① 定义维度建模 = 事实表 + 维度表，围绕业务过程构建。
② 星型模型：维度表直接与事实表关联，冗余但查询性能好；
③ 雪花型：维度表规范化，减少冗余但查询需多表join；
④ 选型：查询频繁、性能优先选星型；数据一致性要求高、存储敏感选雪花型。
示例回答：“维度建模以业务过程为中心，事实表存储度量，维度表描述上下文。星型模型维度平铺，适合OLAP快速查询；雪花型将维度拆分，适合需要严格一致性的场景，比如金融风控。我优先选择星型，必要时对超大维度使用雪花型。”
可能追问：
· 如何处理维度退化？
· 你遇到过维度表太宽导致的存储问题吗？
📌 问题2：什么是缓慢变化维？请描述三种常用策略及其优缺点。
考察点：对SCD的理解深度；能否根据业务选择合适策略；实际项目中的实践细节。
回答框架：
① 定义：维度属性随时间缓慢变化的处理方式。
② SCD1：直接覆盖原值，无需历史，实现简单但丢失历史。
③ SCD2：新增行保留历史，通过有效时间标记，可追溯全量历史但数据膨胀。
④ SCD3：增加列记录前后值，折衷方案，适合变化次数有限的属性。
示例回答：“SCD1适合不需要追溯的属性，如用户昵称；SCD2适合必须保留历史的属性，如用户收货地址，我会加start_date和end_date；SCD3用于只关心最近变化的属性，如会员等级，用cur_level和prev_level列存储。”
可能追问：
· SCD2如何保证唯一性？
· 如何处理SCD2引起的维度表JOIN性能问题？
📌 问题3：设计事实表时如何确定粒度？请举例说明。
考察点：粒度定义清晰度；是否理解“最细粒度”原则；能否结合业务平衡存储与查询需求。
回答框架：
① 粒度 = 事实表中一行代表什么业务事件。
② 原则：原子粒度（最细），避免预聚合。
③ 举例：电商订单事实表，一行代表一个订单行（SKU），而非一个订单。
④ 若业务需要多表合并，使用累积快照或周期快照。
示例回答：“我遵循最细粒度原则。例如电商交易的订单事实，我以订单明细行作为粒度，而非订单头。这样既能支持多维度聚合，也不丢失数据。如果下游需要汇总订单金额，可通过聚合视图实现。同时我会在事实表里包含订单头维度退化字段。”
可能追问：
· 如果数据量极大，细粒度导致存储爆炸怎么办？
· 什么场景下应该使用累积快照事实表？
项目案例模板
| 项目名称 | 电商用户行为分析数仓 |
| 业务背景 | 某电商平台需要统一用户浏览、点击、加购、购买行为路径，支持运营漏斗分析和用户画像。 |
| 规模指标 | 日增行为事件 3亿条；维度表 12张，事实表 5张；存储 ODS+CDM+ADS 约 200TB。 |
| 技术栈 | Hive（离线） / Kafka+Flink（实时） / ClickHouse（分析） / Hbase（维表） / Airflow（调度） |
| 核心难点 | ① 用户属性（省份、会员等级）频繁变化，采用SCD2+代理键实现历史回溯；② 行为事件粒度确定为单次点击，按天分区分桶避免扫描全表；③ 星型模型下多维度关联查询性能优化，通过物化视图预聚合。 |
| 面试高频追问 | · 为什么选择SCD2而不是SCD1？具体怎么实现历史回溯？ · 星型模型下如何保证维度一致性？ · 事实表有重复数据如何处理？ |
| 可迁移回答话术 | “我们采用星型模型+SCD2处理用户维度。行为事实表按时间分区，维度表使用代理键。针对慢查询，我们创建了以用户行为类型+日期的物化视图，将查询时长从分钟级降到秒级。数据一致性通过ETL中统一维度代理键映射保证。” |