DWD 层（明细层）和 DWS 层（汇总层）的设计原则分别是什么？
在数据仓库的建设中，DWD（Data Warehouse Detail，明细数据层） 和 DWS（Data Warehouse Service/Summary，汇总数据层/服务层） 是最核心的两个层次。它们承上启下，决定了数仓的稳定性、复用性和查询性能。
以下是这两层详细的设计原则对比：
一、 DWD 层（明细数据层）设计原则
定位：DWD 层是数仓的“地基”和“事实来源”。它基于 ODS（原始数据层）进行清洗、转换，以维度建模（Kimball 方法论）为核心，保存最细粒度的业务行为数据。
1. 保持最细粒度（Atomic Granularity）
- 原则：DWD 层的数据必须保持业务发生的原子级别，不可进行聚合操作。
- 原因：只有保留最细粒度，才能支持后续任意维度的上卷（Roll-up）和下钻（Drill-down）分析。
- 示例：如果是电商订单，DWD 层应存储“每一行商品”的下单记录，而不是“每个订单”的总金额，更不是“每天”的销售额。
2. 维度建模（Dimensional Modeling）
- 原则：采用星型模型（Star Schema）构建，将数据拆分为事实表（Fact Table）和维度表（Dimension Table）。
- 事实表：存储业务过程（如下单、支付、浏览），包含外键（关联维度）和度量值（金额、次数）。
- 维度表：存储环境描述信息（如用户、商品、时间、地区），通常采用一致性维度（Conformed Dimensions），保证同一维度在不同事实表中含义一致。
3. 数据清洗与标准化
- 原则：在 ODS 到 DWD 的过程中，必须完成脏数据治理。
- 空值处理：填充默认值或保留 NULL。
- 格式统一：时间格式（YYYY-MM-DD）、布尔值（0/1 或 T/F）。
- 单位统一：金额统一为分或元，距离统一为米。
- 数据脱敏：手机号、身份证号加密或掩码。
4. 业务过程的完整性
- 原则：DWD 层应覆盖所有业务过程的生命周期。
- 事务型事实表：记录单次行为（如点击、支付）。
- 周期快照事实表：记录固定时间点的状态（如每日库存、每日账户余额）。
- 累积快照事实表：记录流程的全生命周期（如：下单时间 -> 支付时间 -> 发货时间 -> 收货时间，在一行中体现）。
5. 代理键的使用（Surrogate Key）
- 原则：建议使用数仓生成的自增 ID 或 UUID 作为主键，而不是直接使用业务系统的 ID。
- 原因：业务系统 ID 可能会重置、变更或跨库重复，代理键能隔离源系统变化对数仓的影响，并处理缓慢变化维（SCD Type 2）。
二、 DWS 层（汇总数据层/服务层）设计原则
定位：DWS 层是数仓的“公共服务区”。它基于 DWD 层进行轻度或高度汇总，目的是提升查询性能和指标复用性。通常以宽表（Wide Table）形式存在。
1. 以主题为导向（Subject-Oriented）
- 原则：DWS 层不再像 DWD 那样关注单一业务过程，而是关注业务主题（如：用户主题、商品主题、流量主题、活动主题）。
- 做法：将同一主题下的多个业务过程汇聚在一起。
- 示例：在“用户主题宽表”中，既包含用户的基本属性（维度），也包含该用户当天的下单金额、支付次数、登录次数、浏览时长（来自不同 DWD 事实表的聚合）。
2. 宽表设计（Wide Table）
- 原则：以空间换时间。将维度和事实进行预连接（Pre-join），减少下游查询时的 Join 操作。
- 做法：一张 DWS 表通常包含几十甚至上百个字段（指标），涵盖该主题下的常用分析维度。
3. 汇总粒度的标准化
- 原则：DWS 层的聚合必须有明确的时间粒度，通常分为：
- 最近 1 天（日加表）
- 最近 7 天 / 30 天（周/月聚合）
- 历史至今（累积聚合）
- 命名规范：表名通常带有粒度标识，如
dws_user_action_day_count（用户行为日统计）。
4. 指标复用性（Commonality）
- 原则：DWS 层的设计必须服务于多个下游应用（ADS 层或 BI 报表），而不是只为一个报表定制。
- 判断标准：如果一个聚合表只被一个报表使用，它可能应该放在 ADS 层；如果被三个以上报表使用，它必须沉淀在 DWS 层。
5. 避免算术计算，保留基础度量
- 原则：DWS 层主要存储
Sum、Count、Max、Min等可累加指标，尽量避免存储比率型指标（如转化率、平均值）。 - 原因：比率型指标不可再聚合。
- 错误做法：存储“平均客单价”。
- 正确做法：存储“总销售额”和“总订单数”。下游 ADS 层计算时再相除。这样如果下游需要计算“周平均”，可以将每天的“总销售额”相加除以“总订单数”相加，保证数据准确。
6. 幂等性与重跑机制
- 原则：DWS 层的数据生成脚本必须支持重跑（Re-runnable）。
- 做法：通常采用
INSERT OVERWRITE分区的方式，确保多次运行结果一致，不会出现数据重复累加。
三、 DWD 与 DWS 的核心对比总结
| 特性 | DWD (明细层) | DWS (汇总层) |
|---|---|---|
| 核心任务 | 清洗、标准化、维度建模 | 聚合、宽表化、公共指标计算 |
| 数据粒度 | 最细粒度（原子级），一行代表一次行为 | 聚合粒度（如按天、按用户），一行代表一个对象的汇总状态 |
| 表结构 | 星型模型（事实表 + 维度表） | 宽表模型（大宽表，包含大量指标字段） |
| Join 操作 | 查询时通常需要 Join 维度表 | 尽量减少 Join，维度信息已冗余或打平 |
| 数据量 | 极大（与 ODS 接近） | 较小（经过聚合压缩） |
| 查询性能 | 较慢（需扫描大量行，做多表关联） | 极快（列式存储优势明显，单表查询） |
| 主要用户 | 数据分析师（排查问题、探索性分析） | 业务人员、BI 报表、ADS 层开发人员 |
| 设计口诀 | 弱耦合、强一致、存明细 | 聚通项、宽表化、高复用 |
总结
- DWD 设计好坏决定了数仓的数据质量和扩展能力（能不能查到细节）。
- DWS 设计好坏决定了数仓的查询效率和开发成本（能不能快速出数）。
右滑查看面试常问