20-数仓分层与建模.md 12 KB
数仓分层与建模
本文档记录
poyee-data-warehouse数据仓库的分层架构、建模方法论与总线矩阵。 与命名规范（数仓命名规范.md）配套阅读。
1. 架构原则
- 横向分层：提高数据复用率，明确数据血缘
- 竖向分域：指导指标体系的建设
2. 分层定义
二维视图（横向分层 × 竖向分域）：
用户域 交易域 商品域 商家域 公共域
┌──────┬──────┬──────┬──────┬──────┐
ADS 数据应用层：提供数据展示、数据指标 │
├──────┴──────┴──────┴──────┴──────┤
TDM 标签数据层：长表明细 + 宽表服务 + 人群包圈选 │ ▲
├──────┬──────┬──────┬──────┬──────┤ │
DWS 数据汇总层：建立汇总宽表，提供公共指标 │ DIM
├──────┴──────┴──────┴──────┴──────┤ 公共
DWD 数据明细层：标准化、维度补全、异常处理 │ 维度
├──────┬──────┬──────┬──────┬──────┤ │
ODS 贴源层：类型转换、空值处理、脏数据识别 │ │
├──────┴──────┴──────┴──────┴──────┤ │
RAW 原始采集层：全字段 STRING，原样落盘，永不转换 │ │
└──────┴──────┴──────┴──────┴──────┘
分层定义表：
| 层 | 代码 | 定位 | 典型操作 |
|---|---|---|---|
| 原始采集层 | 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 ──▶ ODS ──▶ DWD ──▶ DWS ──▶ TDM ──▶ ADS
│
DataX / Broker Load
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 字段。
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（日期，必须）；hr（小时，按需） - 存储格式：ORC（列存）
- 压缩：
orc.compress=NONE（咱不压缩，放弃一部分磁盘换 CPU/查询速度与 debug 友好度 ，后期做冷热数据时再考虑压缩） - 纠删码：当前关闭（保持 3 副本），等 Worker 节点扩容后对冷数据启用
7.1 组合快照示例
拼团表 DWD 快照策略：每日增量快照 + 近 7 天全量快照 + 全量拉链表
8. raw 层与 ods 层的职责约定
这是本数仓的核心数据契约，所有 raw / ods 层作业都必须遵守。
8.1 raw 层：schema-on-read landing
- 全字段 STRING：raw 层所有表的业务字段（不含
dt分区）一律STRING类型，源库是什么类型、含不含空值、超不超长，raw 全部原样落盘 - 同步任务不做类型转换：DataX ini 里不写
columnType的类型映射（或统一填string），CSV 导入时 SparkSQL 读取后也不CAST - 为什么：
- 类型转换失败会中断同步链路，而 raw 是链路出入口，必须稳定
- 源库偶发脏数据（超长、空串、非预期类型）不会丢失，可追溯
- 同一份 raw 可以被 ods 重建多次（用不同清洗逻辑），而不需要回源库再同步
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 等框架字段，暂不做统一要求，后续实际接入第一批表时再根据需要补充到本节。