第四章：数仓分层设计与建模理论
本章聚焦面试高频考点：分层架构的合理性、维度建模选择、事实表类型、缓慢变化维策略及模型评价。以下内容按“回答框架+追问路径+避坑提醒”结构化展开，便于快速记忆与现场调用。
图4-1：数仓分层回答框架图（先定目标→逐层说明→强调耦合→业务验证→总结原则）
图4-2：缓慢变化维策略对比及选择路径（Type1/2/3 → 依据 → 避坑）
常规面试问答卡片
- 总述分层目的：解耦、复用、管理数据生命周期
- 逐层说明：ODS（源数据备份）→ DWD（清洗去重、维度退化）→ DWS（轻汇总宽表）→ ADS（应用集市）
- 结合业务举例（如用户交易主题）
- 强调“高内聚低耦合”原则
离线数仓通常分为 ODS、DWD、DWS、ADS 四层。ODS 保留原始日志；DWD 做数据清洗、维度退化，生成明细宽表；DWS 按主题轻度聚合，如用户日活跃宽表；ADS 按业务需求输出报表。例如用户交易主题：ODS 存订单流水，DWD 关联商品维度，DWS 按天汇总交易金额，ADS 呈现趋势图。分层目的：解耦复杂逻辑，提升数据复用性。
- 为什么需要分层？
- 数据倾斜如何处理？
- 分层越多越好吗？如何控制层数？
不要过度分层导致链路过长（超过5层建议评估），也不应跳过 DWS 直接出报表。重点讲清楚每层转换逻辑和数据粒度变化。
- 对比星型 vs 雪花：星型性能好、冗余；雪花规范化、减少冗余但查询复杂
- 说明适用场景：星型常用于大宽表加速分析，雪花用于维度层级严谨的场景
- 事实表三种类型：事务事实表（每笔事件）、周期快照事实表（固定频率状态）、累积快照事实表（流程进度）
- 举例说明（订单、账户余额、订单生命周期）
星型模型以事实表为中心，维度表直接关联（如订单事实表 + 商品、时间维度），查询仅需一次join，性能优越。雪花模型将维度进一步规范化（如商品→品类→品牌），减少冗余但增加join次数。事实表分三类：事务事实表记录每笔交易（如支付明细）；周期快照事实表记录月末账户余额；累积快照事实表跟踪订单从下单到签收各环节时间戳。根据业务分析粒度选择。
- 缓慢变化维与事实表如何关联？
- 拉链表的具体设计？
- 多事实表如何建模？
不要混淆“事实表”和“明细表”；事务事实表通常要求幂等设计（避免重复加载导致数据翻倍）。
- 定义缓慢变化维：维度属性随时间变化
- Type1覆盖：不保留旧值，适用纠错或不需回溯（如手机号）
- Type2新增行：加开始/结束日期，保留全历史，适用邮编、地址等
- Type3新增列：保留有限历史，适用对比前后变化（如用户等级）
- 选择依据：历史需求、存储成本、查询复杂度
Type1直接更新，如用户手机号变化不涉及历史分析。Type2新增行并标记有效期，适合地址、部门等需要回溯场景，用拉链表实现。Type3新增“现地址-旧地址”两列，适用于只关注最近两次变化，如会员等级升降。实际电商中，收货地址用Type2，客户分类用Type3。选择时考虑：历史周期长度、存储预算、查询性能。
- Type2闭链数据如何处理分区？
- 拉链表与Type2关系？如何避免数据膨胀？
- Type3适用属性变化次数有上限吗？
Type2注意闭链时间戳精确到秒或日，分区策略建议用起始日期分区；避免全量扫描。Type3只适用于变化次数少且已知的场景。
项目案例：某电商平台离线数仓实时化改造项目
| 项目名称 | 某电商离线数仓实时化改造（DWD层融合流批） |
| 业务背景 | 电商订单及用户行为数据，需同时支持T+1报表与近实时自助分析，原有全量Hive任务延迟超8小时 |
| 规模指标 | 日增5TB，总数据200TB+，离线任务1500+，维度表50+，事实表20+ |
| 技术栈 | HDFS、Hive、Spark、HBase、Kafka、Airflow、Delta Lake（作为存储层） |
| 核心难点 |
|
| 面试高频追问 |
|
| 可迁移回答话术 |
“我们采用业务日期分区 + 增量加载，利用 Delta Lake 的 merge 操作实现 upsert，避免全量覆盖维度表。对于数据倾斜，先通过采样识别热点 key，再采用两阶段聚合（加随机前缀）或调整分区数。拉链表设计上，使用 row_number over (partition by 维度id order by 生效日期) 生成闭链时间，配合小文件合并策略，日负载控制在30分钟内。流批统一用 Delta Lake 作为存储，通过 CDC 事件保证最终一致性。” |
💡 模型评价核心指标：① 查询响应时间（<5s 为优秀）② 数据新鲜度（T+1 或 分钟级）③ 维度表与事实表关联正确率（>99.9%）④ 存储压缩比（ORC/Zstd）。面试时可用“我们在X项目中将查询时间从30s降到2s，同时存储节省40%”作为量化成果。
💡 加分项：能主动对比不同建模理论（Kimball vs Inmon），并结合公司实际说明选择理由；熟悉数据治理与元数据管理，如通过Atlas自动生成血缘。
⚠️ 常见雷区：面试时只背概念而不举实际例子；认为分层越多越好；没有考虑数据回溯成本；忽略缓慢变化维对下游任务的影响。