📚 课程目录第2章高频面试问题与回答框架

第2章数仓分层设计与建模原则

离线数仓负责人面试中，“数仓分层设计”是必考高频题，占比超过80%。面试官通过分层问题考察你对数据治理、复用性、性能优化的理解深度。本章围绕分层设计的三个核心问答，帮你建立结构化的回答框架。

  💡 核心卡片清单：本章3个问答覆盖分层原则、DWD建模细节、DWS与ADS设计，可直接套用大多数面试场景。

面试问题	请解释离线数仓为什么需要分层设计？分哪几层？
考察点	对分层本质的理解（解耦、复用、可回溯）而非只背层名；能否区分数仓与业务系统的定位差异。
回答框架	① 一句话点明分层目的（如：分层是为了平衡存储成本、计算效率和数据一致性）；② 简述标准5层（ODS→DWD→DWS→ADS→DM）；③ 举例说明每层典型动作（如ODS保持源表结构仅全量/增量，DWD做清洗与维度退化）。
简短示例	分层解决三大矛盾：模型复用与定制、历史回溯与改造、聚合效率与明细保留。我常用ODS保留原始痕迹，DWD做一致性清洗与退化维度，DWS轻量聚合，ADS按场景个性化切片。避免“打平后直接出报表”的烟囱式架构。
可能追问	① 你们实际项目用了5层吗？有没有合并或新增？ ② 如果OLAP系统支持宽表，是否还需要DWS？
避坑提醒	❌ 错误答案：“分5层，具体是XXX”只背层名没有理解。面试场景：只说“为了解耦”太泛，一定要结合你经历的真实问题（如查不到真实数据、重复开发）来印证。

面试问题	你在做DWD层建模时，如何选择建模方法？维度退化 vs 星型模型，你更倾向哪种？
考察点	是否能结合实际数据规模、查询模式、下游偏好做出合理判断；是否理解两种模式的本质代价。
回答框架	① 先区分场景：大宽表（维度退化）适合查询简单、下游非技术用户居多；星型模型适合灵活多维分析、需要维度一致性。② 给出选择依据：数仓规模大（>1000张表）且ETL团队强，优先星型；小团队且报表固定，可宽表。③ 补充权衡：宽表冗余存储但节省join，星型灵活但增加开发复杂度。
简短示例	一般DWD采用“轻度宽表”策略：保留核心维度（时间、地点、商品），将常用描述字段退化到事实表，其余维度保留独立表。例如订单DWD表会退化订单状态、渠道名称，而商品分类仍用维表，避免退化后维表更新导致全量重跑。
可能追问	① 如果业务方要求所有字段都在一张表里，你怎么说服他们用星型？ ② 维度退化后维表更新如何影响历史数据？
避坑提醒	❌ 常见陷阱：直接说“我永远用星型”或“我只做宽表”。面试官想听决策过程，而非结论。必须结合项目中的业务规模、查询频次、数据一致性要求来论证。

面试问题	DWS层和ADS层有哪些区别？你在实际项目中如何划分它们的职责？
考察点	能否清晰定义“公共汇总”与“应用定制”的边界；是否考虑过冗余与性能的平衡。
回答框架	① 定义DWS：按业务域做轻度聚合（如日活、GMV、订单数），粒度相对固定，服务多个下游。② 定义ADS：按报表/仪表盘定制，粒度细到维度组合，常有预计算和透视。③ 划分原则：如果同一个聚合被3个以上应用使用，下沉到DWS；仅1-2个应用使用，留在ADS。④ 举例说明。
简短示例	例如“每天每个渠道GMV”被运营、财务、绩效三个看板使用，我放在DWS层；而“每天每个SKU在直播间的加购率”只有直播运营用，则在ADS实现，避免污染公共层。划分后DWS表数量控制在30%以内，ADS表占70%但可快速下线。
可能追问	① 如果DWS和ADS都做了相同聚合，你怎么治理这种重复？ ② ADS表过多该如何治理？
避坑提醒	❌ 切忌回答：“DWS是汇总，ADS是应用”太笼统。评分关键：你能否量化边界规则？比如“复用数≥3下沉”、“历史不可改的指标放DWS”等具体策略。另外不要忽略数据血缘治理。

📌 章节总结：分层设计面试的核心是“原则+决策”——先讲通用分层原则，再结合真实项目讲每层的具体做法与取舍。不要背大纲，要讲思考过程。

第2章 数仓分层设计与建模原则