终于有人把数据仓库讲明白了

作者：彭锋 宋文欣 孙浩峰

来源：大数据DT（ID：hzdashuju）

数据仓库是一个面向主题的、集成的、随时间变化但信息本身相对稳定的数据集合，用于支持管理决策过程。数据仓库的主要功能如下：

• 建立公司业务数据模型；

• 整合公司数据源，让清洗和治理之后的数据成为业务数据的唯一事实；

• 支持进行细粒度的、多维的分析，帮助高层管理者或者业务分析人员做出商业战略决策；

• 为更高一层的数据服务、机器学习应用提供主要的历史数据来源。

数据仓库的发展已有近40年的历史，但是它在大数据平台出现之前主要处理的是关系型数据库中的数据（这里称之为传统数据仓库）。在大数据出现之后，数据仓库承担的任务并没有变，但是其建设方式、建设内容和技术架构都发生了很大的变化。本文将对此做个简单介绍。

与ODS一般保存支持业务运营的当前数据不同，数据仓库记录的是业务数据的历史及汇总数据。在很多系统中，ODS对应的持久性数据存储也叫作贴源数据层，其意义都是一样的：从业务系统中采集的不作修改的OLTP操作数据集。ODS除了作为OLTP数据的导入区之外，也可以处理一些分析需求。表10-2对二者进行了简单对比。

▼表10-2 ODS和数据仓库的对比

01 数据建模方式

关于数据仓库中的建模，已经有很多介绍传统数据仓库的书详细介绍过，因此这里只做简单介绍。

数据仓库的模型分为三层：概念模型、逻辑模型和物理模型。

• 概念模型将业务抽象出来，实现对实际业务的数字化描述。

• 逻辑模型将概念模型进行结构化的设计，使其能够用于后续的分析和管理。

• 物理模型将逻辑模型映射到实际的物理存储上，例如数据库、表的设计。

一般数据仓库中的建模工作主要在于逻辑模型层，常见的有实体关系（ER）建模和维度（dimensional）建模两种方式。

实体关系建模使用实体加关系的3NF模型来描述企业业务架构。值得注意的是，业务系统（OLTP）里的3NF模型一般针对某个具体的业务流程，而数据仓库（OLAP）里的3NF模型一般针对企业全局的实体和关系抽象，强调数据的汇聚整合和一致性治理。

被誉为“数据仓库之父”的Bill Inmon比较倡导实体关系建模。例如，Teradata为金融业设计的FS-LDM（Financial Services Logical Data Model）就是一个典型的实体关系模型（见图10-2），它将常见的金融活动抽象和总结为10个主题以及它们之间的关系，这10个主题是当事人、产品、协议、事件、资产、财务、机构、地域、营销和渠道。

▲图10-2 Teradata FS-LDM

实体关系建模的好处是符合3NF，数据冗余少，容易进行数据整合和治理。但是不推荐将这种方式用于基于大数据的数据仓库建模，因为其建设周期长，设计者必须深刻了解企业的全局业务之后才能设计和实施，且其不能很好地支持业务的快速变化。

维度建模由数据仓库和商务智能领域的权威专家Ralph Kimball提出，其核心思想是从业务分析决策的需求出发构建模型。

具体来讲，就是将需要分析的业务流程的基本信息（如一次交易的交易ID、客户ID、门店ID、货物ID、交易时间、交易金额）记录在事实表中，而将与此业务流程相关的通用信息（如客户信息、门店信息、货物信息）记录在维度表中。

与实体关系建模不同，维度建模一般使用星型模型或者雪花模型，会有一定的数据冗余（例如在同一次交易中的多个货物记录中，交易ID、客户ID、门店ID等可能会重复），也不符合3NF，但它是我们在为数据中台建设数据仓库时更推荐的建模方式，因为相比实体关系建模，它具有以下优势：

• 比较直观和便于理解，一条事实表中的记录就可以还原一个业务流程的大部分信息；

• 处理复杂的查询效率较高，无须做大量会占用很多计算资源的join操作；

• 能够快速支持业务的变化和扩展，可以方便地添加新的业务模型及维度，而无须考虑复杂的依赖关系；

• 可以快速实施和见效，可以有针对性地选择业务场景落地然后再逐渐扩展。