数据仓库基础：概念、架构与ETL流程

聊数据质量平台，绕不开数据仓库。我见过不少团队，质量工具选得挺好，但跟数仓搭不上——说白了，两边对数据的理解就不在一个频道上。所以这一章，咱们先把数仓的底子打扎实。

数据仓库到底是什么？

数据仓库，不是数据库的简单放大版。我习惯这么定义：它是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，专门用来支撑决策分析。

你想想看，业务库（OLTP）每天处理订单、扣库存，强调的是并发和事务。数仓（OLAP）呢？它关心的是“上个月哪个品类卖得最好”、“过去三年客户流失率怎么变的”。

我在一家零售企业做过项目，他们的业务库有 200 多张表，但领导要一个“区域销售趋势报表”，IT 部门要跑三天。后来建了数仓，同样的查询，秒级出结果。为什么？因为数仓把数据重新组织过了。

数仓的四大特征

特征	说明	我的经验
面向主题	按“客户”、“产品”、“销售”等主题组织，不按业务流程	主题划分错了，后面所有模型都得改，代价极大
集成性	统一编码、单位、命名规则，消除数据孤岛	曾经有个项目，“性别”字段在三个源里分别是 0/1、M/F、男/女，光清洗就花了两周
稳定性	数据进入数仓后一般不修改，只批量追加	数仓不是用来改数据的，是用来查历史的
时变性	保留历史快照，支持时间维度的分析	没有时间戳的数仓，等于没有记忆

星型模型：最常用的数仓建模方式

星型模型，说白了就是一张事实表在中间，周围围着多张维度表，形状像星星。事实表存度量（比如销售额、订单量），维度表存描述信息（比如时间、产品、门店）。

举个例子，一个销售分析场景：

• 事实表：销售事实表（订单ID、产品ID、门店ID、时间ID、销售额、数量）
• 维度表：产品维度表、门店维度表、时间维度表、客户维度表

查询“2024年上海地区咖啡品类销售额”，只需要关联事实表和3张维度表，SQL 写起来很直观。

雪花模型：更规范，但更复杂

雪花模型是星型模型的“规范化版本”。维度表不再是一张扁平的大表，而是拆成多张子表。比如“门店维度表”拆成“门店表”和“区域表”，“产品维度表”拆成“产品表”和“品类表”。

这样做的好处是减少数据冗余，坏处是查询时要多关联几张表，性能会下降。

星型 vs 雪花：一张表说清楚

对比维度	星型模型	雪花模型
表结构	维度表不拆分	维度表规范化拆分
查询性能	高（关联少）	低（关联多）
数据冗余	有冗余	冗余少
维护成本	低	高
适用场景	大多数 OLAP 场景	存储敏感、维度层次复杂的场景

ETL 流程简介

ETL 是数仓的“血液系统”。没有 ETL，数据进不来、出不去、用不了。三个字母分别代表：

• E（Extract，抽取）：从源系统（业务库、日志、API、文件）获取数据
• T（Transform，转换）：清洗、去重、格式统一、业务逻辑计算
• L（Load，加载）：将处理好的数据写入数仓目标表

嗯，这里要注意：很多人把 ETL 想得太简单，觉得就是“把数据搬过去”。实际上，T 阶段往往占整个 ETL 工作量的 70% 以上。

ETL 的三种常见策略

1. 全量抽取：每次把源表全部数据拉过来。适合小表或首次加载。
2. 增量抽取：只拉取变化的数据（基于时间戳、CDC、日志解析）。适合大表。
3. 全量+增量混合：首次全量，后续增量。最常用的方式。

我建议你一开始就设计好增量策略。我见过一个团队，每天全量抽取一张 5 亿行的订单表，跑了三个月，数仓直接崩了。

数仓核心架构图

下面这张图展示了从数据源到数仓再到应用的整体流程，我把它画成了三层结构：

ETL 与数据质量的关系

这一点我要特别强调：数据质量平台不是独立于 ETL 的，而是嵌入在 ETL 流程中的。我习惯在 ETL 的转换阶段设置多个质量检查点：

• 字段级检查：非空校验、格式校验、值域校验
• 记录级检查：去重、完整性校验
• 表级检查：主外键一致性、数据量波动监控

总结一下这一章的核心

数据仓库是质量平台的“下游消费者”，也是“上游依赖者”。你只有理解了数仓怎么建、数据怎么流，才能设计出真正有用的质量规则。星型模型简单高效，适合大多数场景；雪花模型更规范，但别滥用。ETL 是数据进仓的唯一通道，质量检查必须嵌进去，而不是事后补救。