DWD 明细层是什么
DWD（Data Warehouse Detail）按业务过程组织明细数据：一行代表一次业务事件（下单、支付、退款）或一天的一条明细记录。它承担的是清洗与规范化——去重、空值处理、枚举标准化、单位统一、必要的维度退化——因此是后续所有汇总层的公共数据源。
建表原则
核心原则是「按业务过程建表，不按报表建表」：同一个业务过程只保留一张明细表，多个下游需求都从它出发。这样口径只在一处实现，新增需求不需要重复加工，也不会出现同源不同数的情况。更新方式通常是按天分区、可重跑覆盖。
基本信息
| 粒度 | 一次业务事件（下单、支付、退款等）或一条明细记录 |
|---|---|
| 加工内容 | 去重、空值处理、枚举标准化、单位与类型统一 |
| 组织方式 | 按业务过程建表，一张表对应一个过程 |
| 更新方式 | 日增量分区，支持按分区重跑覆盖 |
| 命名示例 | dwd_trade_order_detail_di（di 表示日增量） |
加工动作读法
| 动作 | 做什么 | 注意 |
|---|---|---|
| 去重 | 同一业务主键取最新状态一条 | 排序字段选错会取到旧状态 |
| 类型规范 | 金额统一为定点小数，时间统一为时间类型 | 单位不一致是最隐蔽的错值来源 |
| 枚举标准化 | 把数字状态码映射为可读名称 | 未覆盖的状态码要落到明确的兜底值 |
| 空值处理 | 明确默认值或标记为未知 | 默认值与真实取值的语义要区分开 |
| 维度退化 | 把常用维度字段直接冗余到明细 | 减少下游频繁 join 维表 |
典型使用场景
- 交易链路：订单、支付、退款各建一张明细表，后续汇总都基于它们
- 行为链路：曝光、点击、加购的明细清洗与去重
- 多源合并：同一业务过程来自多个系统时，在 DWD 统一成一份明细
- 口径统一：把状态码、渠道编码的映射收口在这一层
- 问题回溯：下游数字异常时，从 DWD 逐条核对原始事件
去重与规范化
去重与规范化
-- 按天分区覆盖写入：去重取最新状态，同时统一类型与枚举
INSERT OVERWRITE TABLE dwd_trade_order_detail_di PARTITION (dt = '2026-10-11')
SELECT order_id, user_id,
CAST(amount AS DECIMAL(18,2)) AS pay_amount, -- 统一金额精度
CASE status WHEN 1 THEN 'created'
WHEN 2 THEN 'paid'
ELSE 'unknown' END AS status_name, -- 枚举标准化
create_time
FROM (
SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY update_time DESC) AS rn
FROM ods_order_mysql
WHERE dt = '2026-10-11'
) t
WHERE rn = 1; -- 每个订单只保留最新一条同一业务过程只建一张明细表：多个需求各自建表看起来很快，但两份明细的清洗规则很快会分叉，最终没人能说清哪个数字是对的。
在 DWD 做跨天聚合，会让明细表失去复用价值：其它需要不同粒度的需求只能另建一张，等于绕过了公共层的意义。聚合应放到 DWS。