数据仓库架构演进过程详解（概念、原理、建模、分层设计、架构设计）

作者：hangge | 2025-06-19 09:20

一、什么是数据仓库？

1，数据仓库的定义

数据仓库（Data Warehouse）是包含企业各个业务线数据的集合，主要用于支撑企业管理人员的决策。

2，数据仓库的特性

（1）面向主题

主题就是类型的意思。
传统数据库主要是为应用程序进行数据处理，未必按照主题存储数据。数据仓库侧重于数据分析工作，基本上都按照主题存储数据。
类似传统农贸市场与超市的区别：传统农贸市场中蔬菜和水果（数据）是按照商贩（应用程序）去归类（存储）的，而超市中是按照蔬菜和水果的类型（主题）去归类的。

（2）集成

传统数据库通常与某些特定的应用相关，数据库之间相互独立。
数据仓库中的数据，是在对分散的数据库数据进行抽取、清理、加工和汇总之后得到的，必须消除源数据中的不一致性，以保证数据仓库中的数据是整个企业中全局一致的数据。

（3）稳定

这里的稳定是指相对稳定。
传统数据库中的数据通常是实时更新的，数据随业务需求及时发生变化。数据仓库中的数据主要是供企业决策分析使用的，所涉及的数据操作主要是查询。某个数据一旦进入数据仓库，一般情况下将被长期保留。即数据仓库中一般有大量的查询操作，但几乎没有修改和删除操作。

（4）随时间变化

传统数据库主要关心当前某个时间段内的数据。数据仓库中的数据通常包含历史信息，记录了企业从过去某一个时间点到当时时间点的信息，通过这些信息可以对企业的发展历程和未来趋势做分析和预测。

二、为什么需要数据仓库

1.出现的问题

（1）在工作中，程序员经常会遇到这样的场景：产品经理过来说，老王啊，你来看一下，为什么这个数据指标在不同报表中的统计结果是不一样的呢?

（2）例如，对于平台中的用户下单数据，基本上都会在客户端和服务端分别记录。

当用户通过网页或者 App 下单时会触发一个埋点，埋点会上报这份数据，最终系统会把用户下单数据记录下来，这份数据被称为“客户端记录的数据”。
服务端也会在数据库中维护一份用户的下单数据，这份数据被称为“服务端数据”。

（3）老王在做报表时，如果想要按照“秒”级别或者“分钟”级别进行实时计算，统计出用户消费金额的曲线图，则一般会使用实时上报过来的“客户端记录的数据”，使用起来比较方便。但是，“客户端记录的数据”在准确度上可能会存在一些问题（例如丢失数据）。所以，基于这份数据进行统计可能会存在偏差，不过偏差不会很大，如果只是希望大致了解当天用户消费总金额的实时情况，其实这样做是没有什么问题的。

（4）如果要按照“天”级别汇总每天用户的消费总金额（这对数据的实时性没什么要求，但对数据的准确度有很高要求），则一般会使用数据库中的数据（即上面说的“服务端数据”)。因为数据库是有事务的，并且在统计时也可以排除掉用户退款数据，这样统计出来的才是这一天用户真正的消费总金额。

（5）产品经理反馈的数据指标结果不一致，大概率是因为不同报表使用了不同的数据源，当然也有可能是由于计算逻辑不一致所导致的（不同的报表是由不同需求人员提出来的，指标的计算逻辑可能会存在一些差异）。即出现这种问题是因为数据不统一、计算流程不统一。

（6）后来，老王经过追踪发现，在统计这个指标时，两个报表使用的底层数据不是同一份，一个使用的是客户端记录的数据，另一个使用的是服务端数据，所以导致统计的结果有偏差。

2，解决之道

（1）通过构建企业级数据仓库，可以对企业中的所有数据进行整合，为企业各个部门提供统一、规范的数据出口。这样大家在使用数据时，不需要每次都到各种地方去找数据，所有人都使用相同的基础数据，这样计算出来的结果肯定是相同的。

（2）一个完善合理的数据仓库，对于企业整体的数据管理是意义重大的。数据仓库是整个大数据系统中的重要一环：更高层次的数据分析、数据挖掘等工作都会基于数据仓库进行。如果底层基础数据都没有规划好，那么层的数据分析及数据挖掘都会受影响。就像是盖房子，如果地基没有打牢，那盖出来的房子肯定是摇摇欲坠的。所以说，数据仓库对于一个中大型企业而言是至关重要的。

（3）如果是刚起步的创业型公司，产品也是刚上线，这时花费大量的时间去建设数据仓库是没有太大意义的，这时讲究的是快速迭代。只有数据规模上来了，数据仓库才是有意义的，并且也是必不可少的。

三、数据仓库的基础知识

1，事实表和维度表

从业务层面，可以将数据库中的表划分为事实表和维度表。

事实表：保存了大量业务数据的表，或保存了一些真实行为数据的表。例如，销售商品所产生的订单数据。
维度表：其中存放的是某些维度的数据。维度指的是一个对象的属性或者特征，例如时间维度、地理区域维度、年龄维度。

注意：事实表和维度表是人为定义的，没有严格的限定。在某些场景下，一个表既可以是事实表，也可以是维度表。

2，数据库三范式

（1）第一范式（1NF）：要求数据库表中的每一列都是不可分割的原子数据项。

（2）第二范式（2NF）：要求在第一范式的基础上，数据库表中的每一列都和主键相关，不能只和主键的某一部分相关（针对联合主键而言）。即一个表中只能保存一种类型的数据，不可以把多种类型的数据保存在同一张表中。

（3）第三范式（3NF）：要求一个数据库表中不包含已在其他表中包含的非主键字段。即如果表中的某些字段信息能够被推导出来，那不应该单独设计一个字段来存放这样的信息（能用外键 JOIN 操作来实现就用外键 JOIN 操作来实现）。

3，数据仓库的建模方式

（1）ER 实体模型

ER 实体模型其实就是满足数据库第三范式的模型。它是数据库设计的理论基础，当前几乎所有的 OLTP 系统设计都采用 ER 实体模型来建模。

提示：Bill Inom 提出的数仓理论推荐采用 ER 关系模型进行建模，不过不推荐在实际工作中使用。

（2）维度建模模型

在 Ralph Kimball 提出的数仓理论中提出了维度建模：将数据仓库中的表划分为事实表和维度表，基于事实表和维度表进行维度建模。

提示：维度建模是企业构建数据仓库时最常使用的方式。

（3）Data Vault 模型

Data Vault 模型是在 ER 实体模型的基础上衍生而来的，此模型的设计初衷是为了有效地组织基础数据层，使之易扩展、能灵活应对业务的变化。它还强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理，所以说它并非针对分析场景而设计。

（4）Anchor 模型

Anchor 模型是对 Data Vault 模型做了更近一步的规范化处理，初衷是为了设计高度可扩展的模型，其核心思想是“所有的扩张只添加而不修改”，于是利用该模型设计出来的基本都是 K-V 结构的模型。

4，维度建模模型

（1）维度建模模型分为星型模型和雪花模型。

星型模型：星型模型是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。一般采用降维操作，利用冗余来避免模型过于复杂，提高易用性和分析效率。

雪花模型：雪花模型的维度表可以拥有其他维度表的。维度表的设计更加规范，一般符合数据库第三范式。

（2）雪花模型和星型模型的对比：

数据冗余层面：雪花模型符合业务逻辑设计，采用数据库第三范式设计，能有效降低数据冗余。星型模型的维度表设计不符合数据库第三范式，反规范化，维度表之间不会直接相关，牺牲了部分存储空间。
查询性能层面：雪花模型由于存在维度间的关联，采用数据库第三范式降低数据冗余，通常在使用过程中需要连接更多的维度表，所以导致查询性能偏低。星型模型违反数据库第三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，查询性能比较高。

（3）实际工作中的建议：

在实际工作中，构建数据仓库大多采用星型模型，因为数据仓库主要是侧重于数据分析，对数据的查询性能要求比较高。
在实际工作中，应尽可能多构建一些宽表，提前把多种有关联的维度数据整合到一张表中，后期使用时就不需要多表关联了，比较方便，且性能也较高。

四、数据仓库分层

1，为什么要对数据进行分层？

（1）在构建数据仓库过程中，通常需要对数据进行分层处理。业务不同，每个分层中数据的处理手段也不同。对数据进行分层的主要原因是：希望在管理数据时，能够对数据有一个更加清晰的掌控。

（2）数据仓库分层主要有以下这些原因：

清晰的数据结构：每一个分层的数据都有其作用域，这样在使用数据时能够更加方便地进行定位和理解。
数据血缘追踪：可以简单这样理解，数据仓库最终给业务方呈现的是一个可以直接使用的业务表，但该业务表会依赖很多源表。如果某一个源表出现了问题，则需要快速、准确地定位问题，并清楚其危害范围。数据仓库分层可以很好地解决这个问题。
减少重复开发：通过数据分层，在开发一些通用的中间层数据时，能够很大程度地减少重复开发。
复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单，也容易理解，而且便于维护数据的准确性。当数据出现问题后，不需要修复所有的数据，只需要从有问题的步骤开始修复即可。
屏蔽业务的影响：不需要修改业务即可重新接入数据。

2，数据分层设计

（1）数据仓库一般分为 4 层：

ODS 层：全称为 Operation Data Store（原始数据层）。该层对从数据源采集的原始数据进行原样存储。
DWD 层：全称为 Data Warehouse Detail（明细数据层）。该层对 ODS 层的数据进行清洗，主要解决一些数据质量问题。
DWS 层：全称为 Data Warehouse Service（服务数据层）。该层对 DWD 层的数据进行轻度汇总，生成一系列的中间表，提升公共指标的复用性，减少重复加工，并构建出一些宽表供给后续的业务查询。
APP 层：全称为 Application（应用数据层）。DWD、DWS 层的数据统计结果会存储在 APP 层。APP 层的数据可以直接对外提供查询，不过一般会把 APP 层的数据导出到 MySQL 中供 BI 系统使用，提供报表展示、数据监控及其他功能。

（2）DWD 层在对 ODS 层的数据进行清洗时，一般需要遵循以下原则：

数据唯一性校验：通过数据采集工具采集的数据会存在重复的可能性。
数据完整性校验：采集工具采集的数据可能会出现缺失字段的情况。对于缺失字段的数据，可以选择直接丢掉。如果可以确定是哪一列缺失，则可以进行补全，在补全时可以使用上一条数据的相同列或者下一条数据的相同列。
数据合法性校验：如果在数字列中出现了 NULL、- 之类的异常值，则可以将其全部替换为某个特殊值（0 或者 -1),这需要根据具体的业务场景而定。对于某些字段还需要校验数据的合法性，例如用户的年龄不能是负数。

3，数据仓库命名规范

在基于 Hive 构建数据仓库时，如何体现数据仓库的层次结构呢?

对于数据仓库的每一层，都在 Hive 中创建一个数据库，数据库的名称使用每一层的标识符。例如：对于 ODS 层，可以在 Hive 中创建数据库“ods”，把 ODS 层的表都放到这个数据库中，方便使用和管理。
对于数据仓库中的表名，在创建时可以使用每一层的标识符开头。例如，对于用户数据，可以在数据库“ods”中创建表“ods_user”，这样方便后期使用，只要看到以“ods”开头的表名就知道这个表在哪一层。
对于数据仓库中一些临时表，可以在创建表名时以“_tmp”结尾。
对于数据仓库中一些备份表，可以在创建表名时以“_bak”结尾。

五、数据仓库架构设计

1，典型的企业数据仓库系统

一个完整的企业级数据仓库系统，通常包括数据源、数据存储与管理和数据访问：

数据源部分包括企业中的各种日志数据、业务数据及一些文档数据。将基于这些数据构建数据仓库。
数据仓库构建好了后，可以为多种业务提供数据支撑，例如，数据报表、OLAP 数据分析、用户画像、数据挖掘都需要使用数据仓库中的数据。
在实际工作中，数据仓库还可以细分为离线数据仓库和实时数据仓库。

2，离线数据仓库架构

（1）离线数据仓库需要借助于 Flume、Sqoop、HDFS、Hive 等技术组件，通过定时任务每天拉取增量数据，然后创建各个业务不同维度的数据，对外提供“T+1”的数据服务，数据延迟度较高，整体架构如下图所示：

（2）在离线数据仓库架构中，常见的就是使用 Hive 进行构建，并对数据进行分层处理。当然，也可以使用 Imapala 进一步提高 Hive 的计算性能。

（3）对于 Hive SQL 无法直接处理的复杂业务逻辑，则可以考虑自定义 SQL 函数来解决，或者使用 MapReduce、Spark 代码来解决。

3，实时数据仓库架构

（1）为了适应业务快速迭代的特点，帮助企业及时分析用户行为，进一步挖掘用户价值，需要建设实时数据仓库。

实时数据仓库的构建需要借助于 Flume、Maxwell/Canal、Kafka、Redis、HBase、Flink、ClickHouse 等技术组件。
在实时数据仓库架构中，常见的就是使用 Flink 提供的实时数据计算功能，产生的实时数据在 Kafka 中实时流动，最终结果写入 ClickHouse 这种实时 OLAP 引擎中。

（2）目前，主流的实时数据仓库架构有：Lambda 架构和 Kappa 架构。二者的主要区别见下表：

比较项	业内使用	灵活性	容错性	成熟度	迁移成本	批/流处理代码
Lambda 架构	高	高	高	高	低	2 套
Kappa 架构	低	低	低	低	高	1 套

（3）Lambda 架构介绍

为了快速计算一些实时指标，通常会在已有离线数据仓库上新增一个实时数据计算链路来构建实时数据仓库。这种架构目前是比较成熟、稳定的。其唯一的缺点是：需要单独维护两套代码（离线数据仓库的代码和实时数据仓库的代码），在实际使用中可能会出现数据不一致的情况。
实时数据仓库可以实现“秒”级别或者“分钟”级别的数据延迟，其整体架构如下图所示：

实时数据仓库中引入了类似于离线数据仓库的分层理念，主要是为了提高模型的复用率，同时也要考虑易用性、一致性及计算成本。

注意：实时数据仓库的分层可以结合需求尽量简化，因为分层越多数据的延迟度就越高。

（4）Kappa 架构介绍

Kappa 架构只关心实时计算，数据以流的方式写入 Kafka，然后通过 Flink 将实时的计算结果保存到 ClickHouse 这种实时 OLAP 引擎中。
Kappa 架构是在 Lambda 架构的基础上简化了离线数据仓库的内容，实现了批流一体化数据仓库，其整体架构如下图所示：

Flink SQL 提供的“Hive 数仓同步”功能为批流一体化数据仓库的实现提供了底层技术支持，所有的数据加工逻辑由 Flink SQL 以实时计算模式执行。在数据写入端会自动将在 ODS、DWD 和 DWS 层已经加工好的数据实时回流到 Hive 表中，这样就不需要再单独维护离线计算任务了。
对比传统的“离线+实时数据仓库”架构，基于 Flink 的批流一体化数据仓库架构可以保证计算口径与处理逻辑统一，降低开发和运维成本。
传统数据仓库架构需要维护两套数据管道，其最大的问题是：需要保持两套数据管道的处理逻辑的等价性。但由于使用了不同的计算引擎（例如离线处理使用 Hive，实时处理使用 Flink），所以 SQL 往往不能直接套用，存在代码上的差异性。时间长了以后，离线处理和实时处理逻辑很可能会完全偏离（有些公司可能会存在两个团队分别去维护离线数据仓库和实时数据仓库，人力和物力成本非常高）。
Flink 支持“Hive 数仓同步”功能后，实时处理结果可以实时回流到 Hive 表中，离线处理的计算层可以完全去掉，处理逻辑由 Flink SQL 统一维护。离线层只需要使用回流的 ODS、DWD 和 DWS 层的表做进一步的即席查询即可。