数仓分层与建模

本文档记录 poyee-data-warehouse 数据仓库的分层架构、建模方法论与总线矩阵。与命名规范（数仓命名规范.md）配套阅读。

1. 架构原则

横向分层：提高数据复用率，明确数据血缘
竖向分域：指导指标体系的建设

2. 分层定义

二维视图（横向分层 × 公共维度侧柱）：

                                                ┌────────────┐
┌───────────────────────────────────────────┐   │            │
│  ADS  应用层：业务指标、面向服务端宽表      │   │            │
├───────────────────────────────────────────┤   │            │
│  TDM  标签层：长表明细 + 宽表 + 人群包      │◄──┤    DIM     │
├───────────────────────────────────────────┤   │            │
│  DWS  汇总层：主题聚合、提供公共指标        │◄──┤  公共维度   │
├───────────────────────────────────────────┤   │            │
│  DWD  明细层：清洗加工 + 维度退化           │◄──┤            │
├───────────────────────────────────────────┤   │            │
│  ODS  贴源层：类型转换、脏数据识别          │   │            │
├───────────────────────────────────────────┤   └────────────┘
│  RAW  采集层：全字段 STRING，原样落盘       │
└───────────────────────────────────────────┘

  竖向分域（贯穿 DWD 及以上）：交易 trd / 用户 usr / 商品 prd / 店铺 shp / 公共 pub

分层定义表：

层	代码	定位	典型操作
原始采集层	`raw`	从源系统/外部文件落地的原始数据，全字段 STRING，同步任务不做任何类型转换	DataX 直接同步、CSV 解析、字段原样落盘
贴源层	`ods`	类型转换、空值处理、脏数据识别的唯一入口，输出类型化的干净表	从 raw STRING 字段做 `CAST`/`TRY_CAST`、空值兜底、去重
维度层	`dim`	公共维度（时间、地区、渠道等），贯穿 DWD/DWS/TDM/ADS	维度退化、缓慢变化维
明细层	`dwd`	标准化、维度补全、异常处理；星型模型	宽表化、维度退化、数据质量校验
汇总层	`dws`	建立汇总宽表，提供公共指标	多维聚合、主题整合
主题域模型层	`tdm`	标签明细长表（EAV）+ 核心标签宽表（pivot）+ 人群包（远期 bitmap）；按实体类型分表（usr/prd/shp），Hive 离线计算，远期可加 HBase（在线标签服务）/ ClickHouse（人群包交叉计算）	标签计算、pivot 宽表、bitmap 圈选
应用层	`ads`	提供数据展示、数据指标	面向消费端的定制聚合

数据流：

RDS PG / ES ──DataX──▶ RAW ──SparkSQL──▶ ODS ──▶ DWD ──▶ DWS ──▶ TDM ──▶ ADS
                                                                             │
                                                                             ▼ DataX / Broker Load
                                                            服务层（Doris / CK / ES / Mongo）

3. 主题域划分

当前划分为以下主题域，对应命名规范的 domain 代码：

域	代码	说明
交易域	`trd`	订单、支付、退款、购物车
用户域	`usr`	注册、登录、活跃、画像
商品域	`prd`	商品、SKU、SPU、价格
店铺域	`shp`	店铺、商家
公共域	`pub`	平台、日历、地理等

4. 数仓总线矩阵

总线矩阵用于指导维度建模和指标体系建设，列出各业务过程与公共维度/业务维度的关系。以下是模板，还未整理成正式可用的矩阵

域	业务过程	说明	时间	用户	地区	渠道	商品	店铺	活动	支付
交易域	order_create	用户提交订单（未支付）	✓	✓	✓	✓	✓	✓	✓
	order_pay	用户完成订单支付	✓	✓	✓	✓	✓	✓	✓	✓
	order_cancel	用户取消订单	✓	✓	✓	✓	✓	✓	✓
	refund	用户发起退款/售后	✓	✓	✓	✓	✓	✓	✓
	cart_add	用户加入购物车	✓	✓	✓	✓	✓	✓
用户域	user_register	用户注册账号	✓		✓	✓
	user_login	用户登录行为	✓		✓	✓
	user_active	活跃行为（浏览/点击）	✓		✓	✓
商品域	product_expose	商品曝光（列表/推荐位）	✓	✓		✓		✓	✓	✓
	product_click	商品点击进入详情页	✓	✓		✓		✓	✓	✓
	product_favor	用户收藏商品	✓	✓		✓		✓	✓	✓
店铺域	shop_visit	用户访问店铺	✓	✓	✓	✓
	shop_follow	用户关注店铺	✓	✓	✓	✓

5. 维度建模方法论

OLTP 业务库采用范式建模；OLAP 数仓特别是 DWD 层采用维度建模（Kimball）。模型类型：星型模型，维度退化在 DWD 或 DIM 层完成。

5.1 建模五步法

步骤	说明	示例（发券业务）
1. 确定主题域	选取所属业务域	交易域 / 营销域
2. 选择业务过程	从业务流程中提取可度量的动作	券发放 / 曝光 / 点击 / 领取 / 核销
3. 声明粒度	明确事实表每行表示什么；优先原子粒度	"每个用户每次领券记录"；主键 = 领取 id + 幂等 id
4. 确认维度	从哪些角度切分数据	权益类型、发放渠道、门槛、折扣、时间、用户
5. 确认事实	表示度量的数值字段	领取金额、核销金额、引导 GMV

5.2 关键原则

同一事实表粒度必须一致。跨业务过程合并的合并事实表，各自度量必须有同等级粒度。
维度退化：将常用维度属性冗余到事实表，减少运行时 JOIN。
一致性维度：公共维度全局统一（见 dim_pub_* 系列）。
原子粒度优先：最低粒度事实可以无限上卷，高粒度事实不可下钻。

5.3 建模示例

【业务过程】 券的核销
【粒度】      子订单 × 券 id （SKU 级）
【维度】      权益类型 / 领取场景 / 发放渠道 / 时间 / 用户 / 店铺
【事实】      核销金额 / 引导 GMV

5.4 从数仓规划到物理落地的推演

左侧是抽象的规划层级，右侧是一个零售业务的具体示例：

规划层级	示例（xxx 零售）	物理落地
业务板块	xxx 零售	—
数据域	交易域	Schema 划分
业务过程	支付	DWD 事实表切片
度量	下单金额	事实字段
维度建模	时间 / 区域 / 商品	维度表：订单表、商品表
原子指标	下单金额	`order_amt_cny`
派生指标	近 1 天上海区域支付下单金额	ADS 汇总表字段
汇总表	`ads_trd_order_area_agg_inc_d`	按区域聚合的下单金额日汇总

关键映射：业务过程 → DWD 事实表；度量 → 事实字段；维度 → DIM 表；派生指标 = 原子指标 + 时间周期 + 修饰词 → DWS/ADS 字段。

5.5 DWD 事实表设计（事件 vs 状态）

核心规则：DWD 事实表默认承载业务事件（不可变事实），实体当前状态进 DIM 拉链表（_zip_d）。

事件 vs 状态判别：

事件：某一时刻发生的业务动作（下单、支付、发货、签收、提交审核、审核通过 / 拒绝），不可变，写入即固定
状态：实体当前的属性或阶段（订单当前状态、用户等级、拼团当前状态），随时间演化，可变

建模规则：

类型	归属	命名（参考 `21-命名规范.md`）	示例
业务事件	DWD 事实表，每个业务过程一张	`dwd_{域}_{业务过程}_apd_d`	`dwd_trd_order_create_apd_d`、`dwd_trd_order_pay_apd_d`
实体状态	DIM 拉链表	`dim_{域}_{实体}_zip_d`	`dim_trd_order_zip_d`（含 `current_status` / 各阶段时间 / `start_date` / `end_date`）

为什么这么拆：

DWD _apd_d 只追加，与 Hive 列存（ORC）"只追加 + 分区"模型天然契合，不需要 UPDATE
状态查询（"截止 dt 各状态订单数"）走拉链表 is_current 切片或按 dt 切片，直观
跨表 JOIN（"下单数 - 退单数 = 实际下单数"）是维度建模的正常能力，不是代价
这是 Hive / 列存数仓的事实标准做法（阿里 OneData / 字节 / 美团数仓主流）

典型场景：

场景	事件表（DWD `_apd_d`）	状态表（DIM `_zip_d`）
订单履约（下单 → 支付 → 发货 → 签收，单向）	4 张 `_apd_d`	`dim_trd_order_zip_d`
拼团（发起 → 审核 → 审核拒绝 → 重新提交 → ……，循环）	每个动作一张 `_apd_d`（含"审核拒绝"、"重新提交"等可重复事件）	`dim_trd_group_zip_d`，每次状态变更生成新拉链行
浏览 / 点击 / 加购（独立事件流，无状态实体）	各一张 `_apd_d`	无
订单 vs 订单明细行（一对多）	各一张 `_apd_d`（粒度不同必拆）	无

循环状态机的处理：业务流程若存在循环（如拼团审核可能多次反复："提交 → 拒绝 → 修改 → 再提交"），事件流水（_apd_d）天然支持任意次重复——每次状态变更追加一行，完整还原过程；DIM 拉链表（SCD Type 2）每次状态变更生成新行，旧行 end_date 置变更前一天，状态历史完整可回溯。

何时可考虑 acc：固定线性里程碑场景（不循环、里程碑可枚举且单向推进，如严格不可逆的合同审批流程），如有具体场景按需单独评估，不一刀切禁用。新建 acc 表时在 PR / 设计稿里说明选型理由。

自检：建表想给字段加"时间戳 + 若干状态字段"时，停一步问：这是事件还是状态？事件 → _apd_d；状态 → _zip_d。

6. 数据同步策略

ODS 层从业务库/埋点/爬虫数据接入。关键问题：数据是否存在物理删除，决定增量策略。

数据来源	接入方式	快照类型	备注
业务库 (PG/MySQL)	DataX + CDC	`inc`（增量）	如存在物理删除，后续推行软删除
埋点 (Sensors → Kafka)	Kafka → HDFS/Hive	`apd`（追加）	不可变事件流
爬虫数据	爬虫落库 → DataX	`ful` 或 `inc`	按源站特性决定
维度数据	手工上传 / 配置化	`ful`（全量）	如国家映射、汇率表
一次性历史 / vendor 单批交付	本地 CSV → `bin/csv-to-hdfs-starter.py`	`his`（一次性历史）	永不调度，导入后入档；周期段固定 `_o`

快照类型决策：

数据创建后会被修改 → inc（增量快照）
数据不可变 → apd（追加）
缓慢变化维、需要保留历史轨迹 → zip（拉链表）
每日重刷全表 → ful（全量）
一次性导入、永不再跑 → his（与 ful 严格区分：ful 是周期性调度的全量重刷，his 是导入后归档的一次性快照）

7. 分区与存储策略

分区字段：dt（必须），STRING 类型，格式 YYYYMMDD（如 20260101）；hr（小时，按需）
存储格式：ORC（列存）
纠删码：当前关闭（保持 3 副本），等 Worker 节点扩容后对冷数据启用

7.1 组合快照示例

拼团表 DWD 快照策略：每日增量快照 + 近 7 天全量快照 + 全量拉链表

8. raw 层与 ods 层的职责约定

这是本数仓的核心数据契约，所有 raw / ods 层作业都必须遵守。

8.1 raw 层：schema-on-read landing

全字段 STRING：raw 层所有表业务字段以及 dt 分区字段一律 STRING 类型
同步任务不做类型转换：DataX ini 里不写 columnType 的类型映射（或统一填 string），CSV 导入时 SparkSQL 读取后也不 CAST
外部表兜底：raw 层建表一律用 CREATE EXTERNAL TABLE，DROP TABLE 只删元数据，HDFS 数据保留；raw 作为链路兜底层，误删元数据时数据仍可 MSCK REPAIR / 重建元数据恢复，无需回源库重同步

8.2 ods 层：类型转换与脏数据识别

ods 是类型化的第一层：从 raw 的 STRING 字段做 CAST / TRY_CAST，输出真正类型化的干净表
ods 是脏数据拦截线：转换失败的数据不能静默丢弃，必须有可观测的出口（打标记字段、落到 _err 分区、或写入专门的数据质量日志表，具体策略 TBD）
ods 不做业务语义加工：只做"把字符串变回正确类型 + 空值兜底 + 去重"，不做字段合并、维度关联、指标计算等 dwd 才做的事

8.3 其他框架字段

raw 层是否需要 etl_load_time / src_file / src_row_no 等框架字段，暂不做统一要求，后续实际接入第一批表时再根据需要补充到本节。

8.4 ods 层类型映射参考

总则：raw 层一律 STRING 兜底同步；类型化在 ods 层完成。下表为 ods 层 CAST 目标类型的参考表，具体字段可按业务需要微调（如小金额字段可下沉到 DECIMAL(16,2)）。

8.4.1 PostgreSQL → Hive

PG 类型	Hive 类型
`int2` / `smallint`	`BIGINT`
`int4` / `integer` / `int`	`BIGINT`
`int8` / `bigint`	`BIGINT`
`serial`	`BIGINT`
`bigserial`	`BIGINT`
`numeric` / `decimal`	`DECIMAL(20,4)`
`real` / `float4`	`DECIMAL(20,4)`
`float8` / `double precision`	`DECIMAL(20,4)`
`char` / `character`	`STRING`
`varchar` / `character varying`	`STRING`
`text`	`STRING`
`timestamp` / `timestamp without time zone`	`STRING`
`timestamptz`	`STRING`
`date`	`STRING`
`time` / `timetz`	`STRING`
`boolean` / `bool`	`TINYINT`
`uuid`	`STRING`
`interval`	`STRING`
`tsvector`	`STRING`
`array`	`STRING`（保留 JSON/文本形态，dwd 按需解析）
`hstore`	`MAP<STRING,STRING>`

说明：

整数统一 BIGINT：避免上游扩位（int4 → int8）时下游被动改表
小数统一 DECIMAL(20,4)：覆盖绝大多数金额/比率场景；特殊精度需求（如高精度科学计算）单独评估
布尔用 TINYINT（0/1）：Hive 的 BOOLEAN 与 ORC/Spark 生态兼容性没有 TINYINT 稳定
时间类型全部 STRING：保留源端字面量，dwd 层再按需 to_timestamp / to_date

8.4.2 Elasticsearch → Hive

（待补，首批 ES 埋点库接入时落地）

9. 相关文档

命名规范 — 表/字段命名五段式
指标体系 — 原子/派生指标定义
标签体系 — TDM 层画像/标签

20-数仓分层与建模.md 16 KB 文件歷史 原始文件