数据仓库分层架构与表类型总览：ODS、DWD、DWS、DM、维度表、拉链表

总纲：分层如酿酒

试想一座酒坊——

田里割下的葡萄是业务源数据，带着泥、梗、叶，良莠不齐
ODS 是把葡萄原样搬进仓库，一筐一筐码好，不动它
DWD 是洗葡萄、去梗、分拣，坏的一颗颗挑出来，好的分门别类
DWS 是把葡萄榨汁，算出每一桶多少升、甜度几何
DM 是最终端上桌的成品酒——这一杯给张总，那一瓶贴「典藏赤霞珠」

数据仓库的分层，与此同出一辙。

---

① ODS 表 —— 贴源层「原样镜像」

Operational Data Store，操作数据存储。 数据从业务库搬来，结构与源表一模一样。

项	说明
做什么	将 MySQL、Oracle、日志等数据原封不动同步过来
改不改	不改字段、不改值，顶多加个 `dt` 分区字段标记日期
同步方式	全量（每天拉一整张）或增量（只拉今天新增/变更的）
举个例子	源库有张 `orders` 表 → ODS 里就有张 `ods_orders_di`（`_di` 即 daily increment）

数据库里就是张裸表，带上日期分区。 不建模型，不洗数据。

---

② DWD 表 —— 明细数据层「清洗+建模」

Data Warehouse Detail，数据仓库明细层。 此处是数仓的真正核心地带。

DWD 层有两类关键表，它们组成了经典的星型模型——中间一个事实表，周围一圈维度表。

事实表（Fact Table）

记录「发生了什么」——每一笔交易、每一次点击、每一次登录。核心是度量值（金额、次数、时长）。

dwd_order_fact_di
┌─────────┬──────────┬──────────┬───────────┬──────────┐
│ order_id│ user_id  │ prod_id  │ order_amt │ dt       │
├─────────┼──────────┼──────────┼───────────┼──────────┤
│ 1001    │ U001     │ P_A      │ 299.00    │ 20260616 │
│ 1002    │ U002     │ P_B      │ 1299.00   │ 20260616 │
└─────────┴──────────┴──────────┴───────────┴──────────┘

user_id、prod_id 就是外键，指向维度表。

维度表（Dimension Table）

回答「谁」「什么」「何时」「何地」——描述性信息。相对静态，一条记录代表一个实体。

dim_user (用户维度表)
┌─────────┬───────┬──────────┬────────────┐
│ user_id │ name  │ city     │ reg_date   │
├─────────┼───────┼──────────┼────────────┤
│ U001    │ 张三  │ 上海     │ 2026-01-15 │
│ U002    │ 李四  │ 北京     │ 2026-03-20 │
└─────────┴───────┴──────────┴────────────┘

维度表与事实表的关系，好比字典与流水账——事实表记「第3号商品卖了299元」，想知道「第3号商品」是个啥，就去维度表里查。

---

③ 拉链表 —— 维度表的「历史博士」

拉链表（Zipper Table）是维度表的一种特殊实现，专治缓慢变化维度（Slowly Changing Dimension, SCD）。

问题：张三月前还是「普通会员」，今天升级为「黄金会员」。若直接覆盖维度表，你就丢了历史——查上月报表时，张三变回黄金会员了，数据就对不上。

拉链表的解法：不覆盖，而是追加一条新记录，并用 start_date 和 end_date 标记有效期：

dim_user_zip (用户拉链表)
┌─────────┬───────┬──────────┬────────────┬────────────┐
│ user_id │ name  │ level    │ start_date │ end_date   │
├─────────┼───────┼──────────┼────────────┼────────────┤
│ U001    │ 张三  │ 普通     │ 2026-01-15 │ 2026-06-01 │
│ U001    │ 张三  │ 黄金     │ 2026-06-02 │ 9999-12-31 │
└─────────┴───────┴──────────┴────────────┴────────────┘

end_date = 9999-12-31 表示「至今仍有效」——这条就是「开链」记录
查今天的用户等级：WHERE end_date = '9999-12-31'
查5月的历史快照：WHERE start_date <= '2026-05-01' AND end_date > '2026-05-01'

故曰：维度表答「是谁」，拉链表答「曾是谁」。

---

④ DWS 表 —— 汇总层「轻度聚合」

Data Warehouse Summary，数据仓库汇总层。 将 DWD 层的事实表按主题进行轻度汇总。

项	说明
做什么	按天/周/月聚合，计算 `SUM`、`COUNT`、`AVG`
典型表	`dws_user_behavior_1d`（用户行为日汇总）、`dws_trade_1d`（交易日汇总）
与 DWD 的区别	DWD 是一条条明细；DWS 是「一天共多少条，总计多少钱」

DWD: 张三 16号10:03 浏览商品A
     张三 16号10:05 加购商品A
     张三 16号10:12 下单商品A
                      ↓ 聚合
DWS: 张三 | 20260616 | 浏览1次, 加购1次, 下单1次, 消费299元

---

⑤ DM 表 —— 数据集市/应用层「成品上桌」

Data Market（或 ADS，Application Data Service），数据集市层。 面向具体业务场景的「成品」。

项	说明
做什么	为报表、BI看板、推荐系统、风控模型直接供数
特点	高度定制化，往往已经是「宽表」——一张表包含所需全部字段
典型表	`dm_sales_dashboard`（销售看板）、`dm_user_rfm`（用户价值分层）

DM 层是「厨子炒好的菜」，分析师拿着就能吃。DWS 是「切好备好的料」，还需要再烹一下。

---

总结：一图以蔽之

层级	数据形态	加工粒度	通俗比喻
源系统	业务库原始表	逐行事务	地里的葡萄
ODS	源表镜像	逐行，不改	搬进仓库的葡萄筐
DWD	事实表 + 维度表	明细行，已清洗	洗净分拣的葡萄粒
DWS	轻度汇总表	天/周/月	榨好的葡萄汁（按桶计）
DM	应用宽表	定制化	装瓶贴标的成品酒
维度表	实体描述	静态为主	「葡萄品种图鉴」
拉链表	实体历史快照	有效期	「品种演变史」

---

总而言之：ODS 是「搬」、DWD 是「洗」、DWS 是「算」、DM 是「端」。 维度表横跨各层答「谁」，拉链表给维度加上时间轴答「曾经是谁」。四字记之，足矣。