2. 数仓核心概念面试
3 个面试问答卡片
📌 面试问题：请详细介绍数仓分层架构，以及每层的作用和典型表命名规范。
🧐 考察点： 1. 是否理解分层原因（解耦、统一口径、复用） 2. 对ODS/DWD/DWS/ADS的细节掌握 3. 实际项目中如何命名
✅ 回答框架：
- 分层目的：一句话点明“空间换时间，降低重复开发”。
- 逐层说明：ODS（源数据层，保留原始记录，表名后缀 _ods）；DWD（明细层，清洗降维，_dwd）；DWS（汇总层，轻度聚合，_dws）；ADS（应用层，面向具体报表，_ads）。
- 额外层：可提DIM维表层、TMP临时层，体现工程经验。
📝 示例回答（80字）： 数仓分层核心为ODS→DWD→DWS→ADS。ODS保持源数据原样；DWD完成清洗、维度退化，表名如`dwd_trade_order_detail`；DWS按主题轻度汇总，如`dws_trade_day_sku`；ADS直接支撑报表，如`ads_trade_city_top10`。减少下游重复加工，提升复用性。
💡 可能追问： 如果业务量极大，ODS层是否也需要分区？为什么DWD层要做维度退化？你们项目每层存储格式怎么选？
📌 面试问题：如何划分主题域？维度建模中的星型模型和雪花模型分别适用于什么场景？
🧐 考察点： 1. 主题域的划分方法（按业务过程/部门/实体） 2. 对星型/雪花模型的优缺点理解 3. 实际设计中的权衡
✅ 回答框架：
- 主题域划分：基于业务流程（如交易、营销、物流等），每个主题域包含一组相近的事实和维度。
- 星型模型：维度表直接关联事实表，查询性能高；适合快速报表。
- 雪花模型：维度表进一步规范化，减少冗余但增加关联；适合数据仓库ETL复杂、对存储敏感的场景。
- 实际选择：互联网行业80%用星型，强调查询性能；金融/ERP用雪花保证一致性。
📝 示例回答（90字）： 主题域按业务过程切分，例如交易域包含订单、支付等事实。星型模型维度直接挂事实表，查询快、易理解，适合大促实时看板；雪花模型维度拆成多层，存储更省、一致性强，适合财务对账。我司数仓以星型为主，仅在需要时用雪花规范地址等维度。
💡 可能追问： 事实表分哪几类（事务/周期快照/累积快照）？如何设计退化维度？多值维度怎么处理？
📌 面试问题：什么是缓慢变化维（SCD）？常用的 SCD 类型有哪些？在项目中如何选择？
🧐 考察点： 1. 对维度属性随时间变化的意识 2. 3种SCD类型的区别 3. 根据业务场景选择合适的类型
✅ 回答框架：
- 定义：维度属性非实时变化，需要记录历史状态。
- SCD1：直接覆盖，不保留历史，适用于业务不关注历史（如用户姓名）。
- SCD2：新增一条记录，加有效时间范围或版本号，保留全部历史，最常用。
- SCD3：在原有字段上加“原值/现值”多列，只保留有限历史，适用于关注近两次变化。
- 选择原则：业务要求全历史则SCD2；只关心最新则SCD1；需要快速对比前后变化则SCD3。
📝 示例回答（85字）： SCD指维度属性（如用户等级）随时间变化。SCD1直接覆盖，如用户手机号；SCD2新增记录加`start_date`/`end_date`，用于会员等级变迁全历史；SCD3加两列（之前等级、当前等级），适合快速对比。我们项目80%用SCD2，配合拉链表实现。
💡 可能追问： SCD2的拉链表如何生成？如何处理历史数据的粒度和闭链？如何避免SCD2数据膨胀？
项目案例模板
| 项目名称 | 某电商实时&离线数仓（交易域） |
|---|---|
| 业务背景 | 日均订单500万+，需要按商品、门店、活动等多维度输出小时级/天级GMV、退款率、复购率等报表 |
| 规模指标 | ODS层日增量200TB；DWD表50+张；DWS轻度汇总30+张；日调度任务2000+；支撑10+业务方看板 |
| 技术栈 | Hive+Spark+DataWorks+MaxCompute（阿里云）；表存储ORC，分区策略按dt+hh；调度使用阿里云Scheduler |
| 核心难点 | 1. 订单变更频繁（取消、退款），需要拉链表处理SCD2 2. 维度表与事实表关联时遇到“多值维度”（一个订单多个优惠券） 3. 数据倾斜（大商家订单量百万级） |
| 面试高频追问 |
|
| 可迁移回答话术 |
|