【离线数仓项目】——数据建模设计实战

庄小焱
191 阅读7分钟

摘要

本文详细介绍了离线数仓项目中的数据建模与数仓设计。数据建模面向主题域组织数据，构建多维数据结构，统一业务口径，实现数据的可理解、可追溯、可复用和可扩展。介绍了数仓常见建模方法，包括维度建模及其常见结构（星型模型、雪花模型、星座模型）。重点阐述了数仓分层建模架构（ODS、DWD、DWS、ADS、DIM），以及指标建模与口径管理。还提供了建模流程（从业务调研到文档编写）和电商订单主题建模示例，最后给出设计建议与最佳实践。

1. 数据建模（Data Modeling）

数据建模设计（Data Modeling Design）是将现实世界的业务需求抽象为数据结构与关系的过程，目的是支撑数据的存储、传输与分析。它是信息系统、数据库、数据仓库建设的核心步骤。数据建模实战建议：

  • 从业务出发，建模服务于业务需求
  • 命名统一，使用规范前缀、缩写、风格（如 user_info / biz_order）
  • 做好数据字典，每个字段必须有清晰定义
  • 注重数据血缘，便于追踪上下游逻辑
  • 版本控制建模文档，支持审计与演进

1.1. 数据建模的目标

  • 明确业务实体及其关系
  • 规范数据结构，消除冗余，确保一致性
  • 为系统开发、报表分析、数据治理提供统一标准
  • 提高系统的可维护性、可扩展性

1.2. 数据建模的分层结构

数据建模通常分为三个层次，每一层的抽象程度不同：

层级名称作用工具示例
1️⃣ 概念模型（CDM）Conceptual Data Model反映业务实体及其关系ER图用户、订单、商品
2️⃣ 逻辑模型（LDM）Logical Data Model描述字段、类型、主外键PowerDesigner用户表：user_id、name、email
3️⃣ 物理模型（PDM）Physical Data Model映射到实际数据库结构Navicat / SQL表字段类型、索引、分区

1.3. 核心建模要素

1.3.1. 实体（Entity）

业务对象，如“用户”、“商品”、“订单”。

1.3.2. 属性（Attribute）

实体的特征，如用户的“姓名”、“手机号”。

1.3.3. 关系（Relationship）

实体之间的联系，如“用户下单”是“用户”与“订单”的关系。

1.3.4. 主键/外键（PK/FK）

  • 主键：唯一标识一条记录（如 user_id）
  • 外键：指向其他实体的主键，建立关联（如 order.user_id）

1.4. 常见建模方法

1.4.1. ✅ ER 图法（Entity-Relationship Diagram）

  • 使用实体、关系、连接线表示业务结构
  • 适用于概念建模

1.4.2. ✅ 三范式建模（适用于OLTP系统）

范式含义目的
第一范式（1NF）字段不可再分保证原子性
第二范式（2NF）消除部分依赖减少冗余
第三范式（3NF）消除传递依赖提升一致性

应用于业务系统设计（例如微服务数据库建模）

1.4.3. ✅ 维度建模（适用于OLAP/数仓系统）

  • 强调可读性、查询效率，适合报表/分析
  • 使用事实表（Fact Table）和维度表（Dimension Table）
  • 星型模型 vs 雪花模型

1.5. 建模流程（企业级最佳实践）

graph TD
A[业务调研] --> B[实体识别]
B --> C[属性识别]
C --> D[关系建立]
D --> E[绘制概念模型]
E --> F[设计逻辑模型]
F --> G[生成物理模型]
G --> H[落地实施：建库/建表/开发]

1.6. 数据建模工具推荐

工具用途特点
PowerDesigner企业建模标准支持CDM/LDM/PDM转换
ERwin建模与数据治理大型企业使用
dbdiagram.io快速画ER图适合轻量协作
Navicat结构同步、建表数据库运维辅助
Archimate / EA建模与架构一体用于业务架构设计

1.7. 数据建模设计（电商系统建模示例）

1.7.1. ✅ 概念模型（ERD）：

[用户] --- 下单 ---> [订单] --- 包含 ---> [订单明细] --- 指向 ---> [商品]

1.7.2. ✅ 逻辑模型（E—R）：

-- 用户表
CREATE TABLE user (
  user_id BIGINT PRIMARY KEY,
  name VARCHAR(50),
  email VARCHAR(100)
);

-- 商品表
CREATE TABLE product (
  product_id BIGINT PRIMARY KEY,
  name VARCHAR(100),
  price DECIMAL(10,2)
);

-- 订单表
CREATE TABLE order (
  order_id BIGINT PRIMARY KEY,
  user_id BIGINT,
  order_date DATE,
  FOREIGN KEY (user_id) REFERENCES user(user_id)
);

-- 订单明细表
CREATE TABLE order_item (
  order_id BIGINT,
  product_id BIGINT,
  quantity INT,
  price DECIMAL(10,2),
  FOREIGN KEY (order_id) REFERENCES order(order_id),
  FOREIGN KEY (product_id) REFERENCES product(product_id)
);

2. 数仓模型设计（DataHub）

数仓模型设计（Data Warehouse Modeling）是数据仓库构建的核心步骤，目标是将复杂业务过程转换为便于分析的数据结构，支持决策、报表、运营、数据挖掘等需求。

2.1. ✅ 数仓模型设计的核心目标

  • 面向主题域组织数据（如用户、订单、营销、资金等）
  • 构建多维数据结构，便于OLAP分析（切片、下钻、聚合等）
  • 统一业务口径，支持企业级指标平台与报表体系
  • 实现数据的“可理解、可追溯、可复用、可扩展”

2.2. ✅ 数仓常见建模方法

2.2.1. 维度建模（Dimensional Modeling）– 推荐

适用于 报表分析、BI系统、运营分析场景。核心思想：用事实表（Fact）+ 维度表（Dimension） 建模，反范式，优化查询性能。

  • 事实表（Fact Table） ：记录业务事件，如下单、支付
  • 维度表（Dimension Table） ：提供上下文，如时间、用户、地区、渠道
  • 指标字段：通常在事实表，如金额、数量、次数等

2.2.2. 常见结构

模型特点示例
星型模型事实表中心，维度表直接关联fact_order + dim_user、dim_time
雪花模型维度表继续规范化，形成子维度表dim_user → dim_user_region
星座模型（Fact constellation）多个事实表共享维度表fact_order, fact_payment 公用 dim_user

2.3. ✅ 数仓分层建模架构（核心）

大厂实践中，普遍采用分层建模思想，控制复杂度，明确各层职责。

层级简称作用
ODS（数据源层）原始数据同步保留来源，轻度清洗
DWD（明细层）统一粒度的事实/维度标准化、宽表、主键唯一
DWS（汇总层）聚合指标 + 多维度用于复用分析主题
ADS（应用层）面向报表/场景指标口径固定，命名规范
DIM（维度层）独立维度表用户、商品、组织等

示意图：

ODS → DWD（宽表标准化）→ DWS（汇总指标）→ ADS（报表层）
                         ↘ DIM（共享维度）

2.3.1. 指标建模与口径管理

  • 指标命名规范：xxx_cnt、xxx_amt、xxx_rate
  • 维度一致性设计：统一维度表，如 dim_region 作为“省/市/区”标准
  • 指标可追溯：通过血缘工具或注释说明每一层指标如何推导
  • 衍生指标管理：存入指标平台或通过SQL + 文档管理

2.3.2. 建模流程（实战）

graph TD
A[业务调研与指标梳理] --> B[确认分析主题域]
B --> C[设计维度/事实表]
C --> D[建DWD表]
D --> E[设计汇总逻辑 DWS]
E --> F[构建ADS应用层]
F --> G[编写文档与数据字典]

2.4. ✅ 电商订单主题建模示例

2.4.1. 1️⃣ 维度表设计（Dim）

dim_user(user_id, name, gender, birth_date, region_code, ...)

dim_product(product_id, name, category, brand, ...)

dim_time(dt, year, month, day_of_week, is_holiday, ...)

2.4.2. 2️⃣ 事实表设计（Fact）

fact_order(order_id, user_id, product_id, order_time, pay_time, amount, quantity, status, dt)

fact_payment(payment_id, order_id, user_id, pay_time, pay_amount, pay_channel, dt)

2.4.3. 3️⃣ 汇总层（DWS）示例

dws_user_order_day(user_id, dt, order_count, order_amount, pay_amount)

2.4.4. 4️⃣ 应用层（ADS）示例

ads_user_retention_7day(dt, new_user_cnt, retained_user_cnt, retention_rate)

2.5. ✅ 设计建议与最佳实践

关键点建议
粒度控制每张事实表必须粒度清晰，如“订单级”、“支付级”、“天级”
命名规范表、字段、指标命名要一致、简洁、语义清晰
可追溯每层指标需有注释说明（来源+口径+单位）
可扩展模型支持未来业务扩展，不硬编码
可复用公共维度表、公共聚合表、标准函数组件化
ETL解耦按主题域组织代码，按表组织任务调度

2.5.1. ✅ 数仓模型工具&技术选型

领域工具
数据建模PowerDesigner、ERwin、dbdiagram.io
数仓引擎Hive、ClickHouse、Snowflake、BigQuery
ETL调度Airflow、Flink、AzKaban、DataX
元数据管理Apache Atlas、DataMap、Amundsen
血缘/数据字典DataCatalog、OneModel、数栈MetaBase

2.5.2. ✅ 信贷风控场景示例：

主题域：用户画像、借款申请、审批结果、还款行为

  • DWD 表：dwd_loan_apply_fact、dwd_user_dim、dwd_repay_detail
  • DWS 表：dws_user_credit_behavior
  • ADS 表：ads_credit_score_distribution

博文参考

help.aliyun.com/zh/datawork…

avatar
文章
阅读
粉丝