📚 课程目录第3章数仓核心概念与分层架构

离线数仓负责人高阶面试宝典 - 第3节

3. 数仓核心概念与分层架构：维度建模、事实表、缓慢变化维、分层设计原则

【章节导入】本讲聚焦数仓设计的“灵魂”——维度建模与分层架构。面试官通过这组问题考察你对基础理论的理解深度、实战选型判断力，以及面对缓慢变化维等细节时的处理经验。

📌 面试问题1：请说明你常用的维度建模方法论和分层设计原则，并举例说明。

🎯 面试官考察点：

对 Kimball 与 Inmon 方法论的理解与取舍
能否讲清 ODS → DWD → DWS → ADS 每层的职责与典型操作
是否有真实分层落地经验，而非背书

📐 回答框架：

选型声明： 明确说自己采用 Kimball 维度建模 + 分层架构
分层简述： ODS 源数据入仓 → DWD 清洗/维度退化 → DWS 轻度汇总 → ADS 应用集市
模型举例： 以订单域为例，阐述每层做了什么、模型变化
设计原则： 高内聚低耦合、公共层下沉、一致维度和退化维度等

📝 简短示例回答： “我采用 Kimball 维度建模 + 四层分层。以订单域为例：ODS 原样入仓；DWD 做数据清洗、将商户/用户等公共维度退化到事实表减少 join；DWS 按下单粒度汇总整单数据；ADS 输出 GMV 看板。原则是 CDM 层保证高复用，ADM 层快速响应业务。”

🔍 可能追问： 为什么你的 DWD 层要做维度退化？会不会导致冗余？你怎么平衡 DWS 的汇总粒度和 ADS 的灵活性？

⚠️ 避坑提醒：不要只背分层名字，要说清楚每个层做了哪些“数据操作”（如清洗、去重、维度退化、汇总）。

📌 面试问题2：事实表有哪些类型？你在什么场景下使用周期快照事实表？

🎯 面试官考察点：

是否理解三种事实表（事务、周期快照、累积快照）的本质
能否结合业务场景说明选型逻辑
对周期快照的“快照粒度”有没有实操认知

📐 回答框架：

三种事实表概览： 事务——每行一个业务事件；周期快照——每行一个周期内实体状态；累积快照——每行一个业务流程全生命周期
选型场景： 举例说明你用了周期快照（如账户余额每日快照），说清原因（需要追踪状态变化，而非事件明细）
注意粒度： 强调周期快照的粒度是“周期+实体+维度”，避免歧义

📝 简短示例回答： “我在金融数仓中用周期快照事实表存储每日账户余额。因为业务要分析每天各账户的持仓情况，事件表无法直接还原当天状态。快照粒度为‘日期+账户+币种’，每天全量覆盖。相比事务表存储量可控，查询也快。”

🔍 可能追问： 周期快照数据量会不会膨胀严重？你怎么做增量更新？累积快照适用于什么场景？

⚠️ 避坑提醒：不要混淆“周期快照”和“累积快照”，累积快照是“过程跟踪”，周期快照是“时间切片”。

📌 面试问题3：你怎么处理缓慢变化维（SCD）？请结合业务举例说明。

🎯 面试官考察点：

是否掌握 SCD1/SCD2/SCD3 的适用场景与实现
能否处理混合场景（如部分属性覆盖、部分属性保留历史）
ETL 设计中如何实现 SCD2 的拉链算法

📐 回答框架：

类型简述： SCD1 覆盖；SCD2 新增；SCD3 加字段
业务选型： 举例“商家等级变化”——历史分析需要保留，选 SCD2；商家名称可能纯展示，选 SCD1
实现细节： 讲清 SCD2 的生效日期、过期日期、当前标志，以及拉链合并的 ETL 逻辑

📝 简短示例回答： “在电商数仓中商家维度采用混合策略：商家等级（历史分析需要）用 SCD2，增加 start_date/end_date/current_flag；商家名称（仅展示）用 SCD1 直接覆盖。ETL 用增量 + 左关联，先闭链旧记录再插入新行，确保存在性。数据量可控，查历史用 filtered join 取有效区间。

🔍 可能追问： 如果 SCD2 每天变化，数据量太大怎么办？你用什么方式优化拉链表的查询性能？

⚠️ 避坑提醒：不要只答“用 SCD2”，要随口带出“current_flag + 有效区间”这个具体实现细节，面试官很看重这个。另外需注意 SCD2 可能导致的维度膨胀，提前铺好应对方案更显专业。

📁 项目案例模板：离线数仓核心分层设计

项目名称	全渠道电商离线数仓建设（核心订单域）
业务背景	原有报表口径混乱、指标口径不统一，业务方需求响应周期长达2周。需重构数仓，实现 ODS→DWD→DWS→ADS 四层标准架构，支持 GMV、用户行为、供应链等核心场景。
规模指标	日均增量数据 80T，总存储量约 3PB；接入 200+ 业务表，产出 400+ 核心指标；数据延迟控制在 T+1 8:00 AM 前全量就绪。
技术栈	Hive（核心存储 + 数仓模型）、Spark SQL（ETL 加工）、DataX（数据同步）、Apache DolphinScheduler（调度）、Atlas（元数据管理）、Hologres（ADS 加速）
核心难点	多业务线维度严重不一致：如“用户状态”定义在不同系统差异大，需在 DWD 层做统一维度清洗事实表粒度设计：订单域涉及核销/退款/拆单，事务事实表与周期快照事实表并存，避免数据对不上缓慢变化维爆炸：商家评级每天变化，如果全量 SCD2 一个月产生 3000w 行，影响查询性能
面试高频追问	你讲的分层中，DWS 层和 DWD 层的边界怎么划分？如果两个业务方都要同一个指标，由哪层产出？多业务线维度不一致时，你们做了哪些“维度清洗”步骤？有没有沉淀出企业级公共维度？ SCD2 爆炸时你们最终怎么优化的？是不是所有维度属性都需要保留历史？你们 DWS 层用的是什么聚合粒度？如何平衡数据量和复用性？
可迁移回答话术	话术1（分层边界）： “DWD 层负责明细数据的清洗与标准化，保留最细粒度；DWS 层开始做业务视角的轻度汇总，例如将订单明细聚合到支付维度的整单粒度。CDM 层保证数据‘一次加工，多处使用’，但不做高频变动指标计算，由 ADS 层承接。” 话术2（维度不一致）： “先做元数据盘点，识别出‘同义不同名’的属性，制定统一的枚举字典；在 DWD 层用 UDF 或字典表做映射转换，下沉为公共维度表。如果业务方坚持不同枚举值，则保留源字段 + 映射字段两条线，并用元数据记录映射关系。” 话术3（SCD2 优化）： “我们按属性分类：高频变化且业务分析需要的（如用户等级）保留 SCD2；低频或仅展示的属性用 SCD1。同时引入‘月度拉链’而非日拉链，减少行数；查询时用 current_flag + 业务日期区间过滤，并建分区索引。”