● ODS层"业务系统"与DWD层"主题域"的区别与联系

这是数仓建模中非常核心的一个概念，搞清楚这两者，就理解了"从源到仓"的本质转变。

---

一、本质区别：组织视角完全不同

┌──────────┬────────────────────────────────────┬──────────────────────────────┐
│ 维度 │ ODS 层（业务系统视角） │ DWD 层（主题域视角） │
├──────────┼────────────────────────────────────┼──────────────────────────────┤
│ 组织依据 │ 按源系统划分 │ 按业务过程划分 │
├──────────┼────────────────────────────────────┼──────────────────────────────┤
│ 划分逻辑 │ 数据从哪来 │ 数据描述什么业务行为 │
├──────────┼────────────────────────────────────┼──────────────────────────────┤
│ 边界 │ 由 IT 系统架构决定 │ 由业务分析需求决定 │
├──────────┼────────────────────────────────────┼──────────────────────────────┤
│ 稳定性 │ 跟随系统变化（系统拆分、迁移就变） │ 相对稳定（业务过程不轻易变） │
├──────────┼────────────────────────────────────┼──────────────────────────────┤
│ 命名前缀 │ ods_{系统名}xxx │ dwd{域}_{业务过程}_xxx │
├──────────┼────────────────────────────────────┼──────────────────────────────┤
│ 粒度 │ 与源表一致 │ 按业务过程重新定义粒度 │
├──────────┼────────────────────────────────────┼──────────────────────────────┤
│ 冗余 │ 同一份数据可能存在多个源系统里 │ 同一业务过程只有一份事实表 │
└──────────┴────────────────────────────────────┴──────────────────────────────┘

---

二、用淘宝场景直观对比

ODS 层：按"业务系统"组织（系统视角）

交易系统（Trade DB）
├── ods_trade_order_di （订单主表）
├── ods_trade_order_item_di （订单明细）
├── ods_trade_payment_di （支付表）
└── ods_trade_refund_di （退款表）

会员系统（Member DB）
├── ods_member_user_df （用户主表）
├── ods_member_level_df （等级表）
└── ods_member_login_log_di （登录日志）

履约系统（Logistics DB）
├── ods_logi_shipment_di （发货单）
├── ods_logi_track_di （物流轨迹）
└── ods_logi_warehouse_df （仓库信息）

营销系统（Marketing DB）
├── ods_mkt_coupon_di （优惠券）
└── ods_mkt_activity_df （活动表）

埋点日志（Log）
└── ods_log_app_click_di （APP 点击）

特点：源系统怎么设计的，ODS 就长什么样。订单系统有 4 张表，ODS 就有 4 张表。

---

DWD 层：按"主题域 + 业务过程"组织（业务视角）

交易域（trade）
├── dwd_trade_order_create_di （下单 业务过程）
├── dwd_trade_order_pay_di （支付 业务过程）
├── dwd_trade_order_refund_di （退款 业务过程）
└── dwd_trade_order_cancel_di （取消 业务过程）

会员域（member）
├── dwd_member_register_di （注册）
├── dwd_member_login_di （登录）
└── dwd_member_level_change_di （等级变更）

履约域（logi）
├── dwd_logi_shipment_di （发货）
├── dwd_logi_delivery_di （妥投）
└── dwd_logi_sign_di （签收）

流量域（traffic）
├── dwd_traffic_page_view_di （浏览）
└── dwd_traffic_item_click_di （点击）

特点：以"业务发生了什么"为视角重新组织。

---

三、关键区别详解

区别1：一对一 vs 多对一/一对多

ODS → DWD 不是简单的"复制"，而是"重组"

ODS 多张表 ──合并──→ DWD 一张事实表

例：dwd_trade_order_pay_di（支付事实）来源：
- ods_trade_order_di （取订单基础信息）
- ods_trade_payment_di （取支付金额、方式）
- ods_member_user_df （补用户属性，做维度退化）
- ods_dim_item_df （补商品类目、品牌）

ODS 一张表 ──拆分──→ DWD 多张事实表

例：ods_trade_order_di 一张表，按状态字段拆分到：
- dwd_trade_order_create_di（下单时刻的快照）
- dwd_trade_order_pay_di （支付时刻的快照）
- dwd_trade_order_cancel_di（取消时刻的快照）

区别2：粒度不同

┌───────────────────────────┬───────────────────────────────────────────────────────┐
│ 层 │ 粒度示例 │
├───────────────────────────┼───────────────────────────────────────────────────────┤
│ ods_trade_order_di │ 一个订单一行（源表怎么存就怎么存） │
├───────────────────────────┼───────────────────────────────────────────────────────┤
│ dwd_trade_order_create_di │ 一个商品一行（订单+商品的最小粒度，便于商品维度分析） │
└───────────────────────────┴───────────────────────────────────────────────────────┘

DWD 经常会重新定义粒度，让事实表的粒度服务于分析需求。

区别3：是否做清洗与统一

┌────────────┬─────────────┬───────────────────────────────────┐
│ 处理 │ ODS │ DWD │
├────────────┼─────────────┼───────────────────────────────────┤
│ 脏数据过滤 │ ❌ 原样保留 │ ✅ 过滤测试单、负数订单 │
├────────────┼─────────────┼───────────────────────────────────┤
│ 字段标准化 │ ❌ 原样 │ ✅ 地址、手机号、枚举值统一 │
├────────────┼─────────────┼───────────────────────────────────┤
│ 脱敏 │ ❌ │ ✅ 手机号、身份证 │
├────────────┼─────────────┼───────────────────────────────────┤
│ 维度退化 │ ❌ │ ✅ 商品类目、城市直接冗余进事实表 │
├────────────┼─────────────┼───────────────────────────────────┤
│ 口径统一 │ ❌ │ ✅ "有效订单"定义在这层落实 │
└────────────┴─────────────┴───────────────────────────────────┘

区别4：跨系统数据的归属

业务上同一个"过程"，源系统可能拆在多个库里：

“用户支付订单” 这一个业务过程：
- 订单状态变更 → 在 交易系统
- 支付流水 → 在 支付系统
- 营销抵扣 → 在 营销系统

ODS：分散在 ods_trade_xxx、ods_pay_xxx、ods_mkt_xxx
DWD：统一汇聚到 dwd_trade_order_pay_di 一张表

DWD 打破了系统边界，按"业务过程"重新聚合。

---

四、紧密联系：DWD 完全依赖 ODS

虽然组织方式不同，但两者关系密不可分：

1. ODS 是 DWD 唯一的数据源

DWD 不允许跨过 ODS 直接读源库，保证：

• 数仓与业务系统解耦
• 数据可回溯、可重算

2. 血缘关系清晰

ods_trade_order_di ─┐
ods_trade_payment_di ┼──→ dwd_trade_order_pay_di ──→ dws_user_trade_nd
ods_member_user_df ─┘

3. ODS 变化的"防火墙"

源系统改字段、改表结构时：

• ODS 跟着改（贴源）
• DWD 通过映射逻辑屏蔽变化，下游 DWS/ADS 无感知

这就是为什么必须有 ODS 层 —— 它是 DWD 的稳定输入源。

---

五、一个完整例子串起来

业务场景：分析"用户支付行为"

【源系统层面】
交易系统（MySQL）：order 表、payment 表
会员系统（MySQL）：user 表
营销系统（MySQL）：coupon_used 表

       │ Binlog 同步
       ▼

【ODS 层 - 按系统组织】
ods_trade_order_di ← 来自交易系统
ods_trade_payment_di ← 来自交易系统
ods_member_user_df ← 来自会员系统
ods_mkt_coupon_used_di ← 来自营销系统

       │ 清洗 + 多表 join + 维度退化 + 口径统一
       ▼

【DWD 层 - 按业务过程组织】
dwd_trade_order_pay_di（支付事实表）
字段：
order_id, user_id, item_id,
pay_amount, pay_method, pay_time,
coupon_amount, ← 从营销系统补充
user_level, register_channel, ← 退化的用户维度
item_cate_id, brand_id, ← 退化的商品维度
province, city, ← 退化的地区维度
is_valid_pay ← 统一口径标识

一句话：ODS 回答"数据来自哪个系统"，DWD 回答"数据描述哪个业务过程"。

---

六、为什么要做这个转变？

┌────────────────────────────────────┬──────────────────────────┐
│ 如果只有 ODS，没有 DWD │ 引入 DWD 后 │
├────────────────────────────────────┼──────────────────────────┤
│ 分析师要懂每个业务系统的表结构 │ 分析师只需懂业务过程 │
├────────────────────────────────────┼──────────────────────────┤
│ 一个分析跨 5 个系统、写 10 个 join │ 一张事实表搞定 │
├────────────────────────────────────┼──────────────────────────┤
│ 源系统改字段，所有报表崩 │ DWD 隔离，下游无感 │
├────────────────────────────────────┼──────────────────────────┤
│ "有效订单"每个人定义不同 │ DWD 统一口径，全公司一致 │
├────────────────────────────────────┼──────────────────────────┤
│ 同样的 join 逻辑被写 100 遍 │ DWD 沉淀一次，处处复用 │
└────────────────────────────────────┴──────────────────────────┘

---

七、一句话总结

▎ ODS 是"按系统组织的原料仓"，DWD 是"按业务过程组织的标准化半成品车间"。
▎
▎ - 联系：DWD 的所有数据都来自 ODS，ODS 是 DWD 的唯一源头；
▎ - 区别：ODS 跟着源系统走（IT 视角），DWD 跟着业务过程走（业务视角）；
▎ - 价值：这层转换是数仓从"数据搬运工"升级为"业务建模师"的关键一跃。