上一篇
如何根据数据源画出数据仓库模型？数据仓库建模步骤详解
构建数据仓库模型是一个将原始业务数据转化为结构化、易于分析的数据资产的过程，这一过程通常遵循从需求分析到物理实现的完整生命周期，核心在于通过分层架构设计，解决数据孤岛、数据质量不一致以及查询性能低下等问题。
数据源分析与需求梳理
在开始建模之前，必须深入理解数据源的业务含义和技术特征，数据源可能来自关系型数据库（如 MySQL、Oracle）、日志文件、API 接口或第三方 SaaS 平台。
| 数据源类型 | 典型特征 | 处理难点 | 建议接入方式 |
|---|---|---|---|
| 关系型数据库 | 结构化强，事务一致性好 | 表结构复杂，关联关系多 | CDC (Change Data Capture) 或定时全量/增量同步 |
| 日志/文本文件 | 非结构化或半结构化，数据量大 | 解析困难，格式不统一 | 使用 Flume/Kafka 采集，ETL 清洗后存入 HDFS/OSS |
| API 接口 | 实时性高，数据量波动大 | 接口稳定性，频率限制 | 消息队列缓冲，异步批量拉取 |
此阶段的关键产出是《数据需求文档》，明确需要统计的业务指标（如日活用户数、转化率）以及粒度（如按天、按小时、按用户 ID）。
概念模型与逻辑模型设计
逻辑模型设计是数据仓库建模的核心，通常采用维度建模方法（Kimball 方法论），我们将数据划分为“事实表”和“维度表”。
- 事实表（Fact Table）：存储业务过程的度量值（数字），如销售额、点击次数。
- 维度表（Dimension Table）：存储描述业务环境的上下文信息，如时间、地点、产品属性。
设计步骤：
- 确定粒度：明确事实表中每一行代表什么。“订单明细”粒度意味着每一行代表一个商品在订单中的记录,而不是整个订单。
- 识别事实：找出需要度量的数值，如 quantity（数量）、amount（金额）。
- 识别维度：找出用于过滤、分组和描述事实的属性，如 date_key（日期）、product_id（产品ID）。
数据仓库分层架构
为了降低数据耦合度并提高复用性，数据仓库通常分为四层：ODS、DWD、DWS、ADS。
ODS 层（Operational Data Store，操作数据层）
该层数据与源系统保持基本一致,主要进行原始数据的存储。
- 作用：作为数据仓库的入口，保留历史快照,支持数据回溯。
- 特点：数据量大，结构复杂,不做清洗或仅做简单清洗。
DWD 层（Data Warehouse Detail，数据明细层）
这是数据仓库的核心层，进行数据清洗、标准化和维度退化。
- 作用：统一数据口径，解决数据质量问题,形成明细事实表和维度表。
- 关键操作：
- 数据清洗：去除空值、异常值、重复数据。
- 维度退化：将高频使用的维度属性（如产品名称、城市名称）冗余到事实表中,减少关联查询。
- 一致性维度：确保同一维度（如“用户”）在不同事实表中具有相同的定义和 ID。
DWS 层（Data Warehouse Summary，数据汇总层）
该层基于 DWD 层进行轻度或高度汇总,面向主题域。
- 作用：提高查询性能,减少重复计算。
- 设计原则：按主题域（如用户域、商品域、交易域）进行宽表设计。“用户每日行为宽表”，包含用户 ID、日期、登录次数、购买次数、浏览商品数等。
ADS 层（Application Data Store，应用数据层）
该层直接面向最终应用或报表。
- 作用：为 BI 报表、数据大屏、推荐系统提供直接可用的数据。
- 特点：数据量小，查询速度快,结构高度定制化。
物理模型实现示例
以下是一个简化的“电商交易”数据仓库模型示例，展示从 DWD 到 DWS 的转换逻辑。
DWD 层：订单明细事实表 (dwd_order_detail)
| 字段名 | 类型 | 描述 | 来源 |
|---|---|---|---|
| order_id | BIGINT | 订单 ID | 源系统 |
| user_id | BIGINT | 用户 ID | 源系统 |
| product_id | BIGINT | 商品 ID | 源系统 |
| quantity | INT | 购买数量 | 源系统 |
| amount | DECIMAL | 订单金额 | 源系统 |
| create_time | DATETIME | 创建时间 | 源系统 |
| dt | STRING | 分区字段 (yyyy-MM-dd) | 系统生成 |
DWS 层：用户每日交易汇总宽表 (dws_user_trade_day)
| 字段名 | 类型 | 描述 | 计算逻辑 |
|---|---|---|---|
| user_id | BIGINT | 用户 ID | 来自 DWD |
| dt | STRING | 日期 | 来自 DWD |
| order_count | INT | 下单次数 | COUNT(order_id) |
| total_amount | DECIMAL | 总消费金额 | SUM(amount) |
| product_count | INT | 购买商品种类数 | COUNT(DISTINCT product_id) |
SQL 逻辑示意：
INSERT OVERWRITE TABLE dws_user_trade_day PARTITION (dt='${biz_date}') SELECT user_id, '${biz_date}' as dt, COUNT(order_id) as order_count, SUM(amount) as total_amount, COUNT(DISTINCT product_id) as product_count FROM dwd_order_detail WHERE dt = '${biz_date}' GROUP BY user_id;
模型优化与维护
- 缓慢变化维（SCD）处理：对于维度属性变化（如用户地址变更），需决定是覆盖旧值（Type 1）还是保留历史轨迹（Type 2，增加有效起止时间字段）。
- 数据倾斜处理：在 MapReduce 或 Spark 计算中，若某个 Key（如热门商品 ID）数据量过大，需进行加盐（Salting）或广播变量优化。
- 生命周期管理：设定数据保留策略，ODS 层保留 3-6 个月，DWD 层保留 1-3 年，ADS 层按需保留,以控制存储成本。
相关问题与解答
问题 1：在数据仓库建模中，为什么通常建议将高频使用的维度属性冗余到事实表中（即维度退化），而不是通过 JOIN 关联查询？
解答：
维度退化的主要目的是提升查询性能，在数据仓库中，查询通常涉及海量数据扫描，如果每次查询都需要通过外键关联维度表，不仅增加了 I/O 开销，还可能导致复杂的 JOIN 操作，尤其是在分布式计算框架（如 Hive、Spark）中，JOIN 操作容易成为性能瓶颈，通过将维度属性（如商品名称、分类、用户性别）冗余到事实表中，可以将多表关联转化为单表扫描，显著减少数据 Shuffle 和计算时间，从而加快报表响应速度，虽然这会牺牲一定的存储空间并增加 ETL 的复杂度，但在“读多写少”的数据仓库场景下,性能收益远大于存储成本。
问题 2：当源系统发生表结构变更（Schema Change）时，数据仓库模型应如何应对以保证历史数据的可追溯性和新数据的正确性？
解答：
应对源系统结构变更，应采取“向前兼容”和“版本控制”策略，在 ODS 层应保留原始数据的快照，不直接修改源表结构，而是新增字段或创建新表来承载变更，在 DWD 层，对于新增字段，若不影响现有业务逻辑，可逐步引入；若为必填字段，需设置默认值或空值处理逻辑，对于删除或重命名字段，应保留旧字段一段时间作为过渡，并在 ETL 脚本中增加版本判断逻辑，建立数据血缘追踪机制至关重要，一旦源系统变更，需自动评估对下游 DWS 和 ADS 层的影响，并及时更新模型定义和 ETL 任务，确保历史数据的一致性不被破坏,同时新数据能正确接入新模型。
