第8章 数据仓库

学习目标

1. 说明数据仓库产生的背景，以及其与操作型数据库在目标和数据组织方式上的区别。
2. 准确表述数据仓库的定义，解释集成性、面向主题、反映历史变化和相对稳定性四个特征。
3. 比较 OLTP 与 OLAP 的处理对象、数据特点、设计目标和主要性能指标。
4. 描述多维数据模型中的维、事实、数据立方体、方体和概念分层等基本概念。
5. 举例说明上卷、下钻、切片、切块和转轴等 OLAP 操作的含义与作用。

引言

企业在长期运营过程中会积累大量业务数据。这些数据最初服务于采购、销售、库存、财务和客户服务等具体业务，由不同应用系统分别管理。随着系统数量和业务复杂性的增长，跨系统查询、历史趋势分析和企业级决策支持的需求日益突出。若直接在承担日常事务处理的数据库上执行复杂分析，容易造成资源竞争和响应延迟；若仅依靠分散的业务系统提供数据，又难以保证数据口径一致和历史记录完整。

数据仓库正是为解决上述矛盾而发展起来的一种数据组织与分析环境。它将来自多个业务系统的数据抽取、清洗、转换和集成后，按分析主题重新组织，并长期保存具有时间特征的数据，为联机分析处理、报表查询和数据挖掘提供稳定、一致的数据基础。

本章首先介绍数据仓库的产生背景、Inmon 提出的定义及其集成性、面向主题、反映历史变化、相对稳定性四个特征，并比较联机事务处理（OLTP）与联机分析处理（OLAP）在处理对象、数据特点和设计目标上的差异；然后阐述多维数据模型中的维、事实、度量、数据立方体、方体和概念分层等基本概念，介绍星型模式、雪花模式和事实星座模式三种概念模型，以及上卷、下钻、切片、切块和转轴等 OLAP 操作；最后说明数据仓库的三层体系结构、ETL 过程与元数据管理，并比较企业数据仓库、数据集市和虚拟数据仓库三种部署模型，为物流领域的绩效分析与决策支持奠定数据基础。

8.1 数据仓库概述

8.1.1 数据处理的演进

从数据处理技术发展的历史看，早期信息系统的主要任务是对业务活动进行记录、保存和查询。这一阶段通常表现为“一个应用系统对应一个或一组文件或数据库”，各系统围绕自身业务组织数据，彼此之间相对独立。随着采购管理、库存管理、销售管理、财务核算、人力资源等系统陆续上线，企业内部的业务数据总量迅速增长，数据定义、编码方式和存储格式的差异也逐渐显现。与此同时，企业管理层不再满足于查询单笔业务记录，而是需要面向决策的综合信息，例如跨部门、跨系统的销售与库存对比，长期的需求变化趋势，以及不同客户、产品和区域的绩效分析。这类决策支持需求要求数据口径一致、覆盖历史时期并能从多个角度汇总，而以事务处理为目标、彼此分散的业务系统难以满足。

为解决上述问题，业界逐步形成了新的技术思路，将分散在各业务系统中的数据统一抽取、清洗和集成，按照分析主题重新组织，并建立独立于日常事务处理的分析型数据平台。数据仓库正是在这一背景下发展起来的。

图8-1 从分散业务系统到数据仓库的数据流转

8.1.2 数据仓库的定义

20世纪90年代初，"数据仓库之父"W. H. Inmon 在《Building the Data Warehouse》中提出了被广泛引用的数据仓库定义：

数据仓库是一个集成的（Integrated）、面向主题的（Subject-Oriented）、反映历史变化的（Time-Variant）、相对稳定的（Nonvolatile）数据集合，用于支持管理决策过程。

这一定义包含四个关键特征，构成了数据仓库区别于传统操作型数据库的核心标志。

8.1.3 数据仓库的四大特征

1. 集成性

数据仓库的数据来源于多个异种数据源，包括关系型数据库、电子表格文件、联机事务处理（OLTP）系统的交易记录、日志文件，甚至外部的开放数据。构建数据仓库的首要任务是将这些异构数据进行清洗和集成，具体包括：

• 统一命名约定：不同系统可能使用不同的字段名表示相同的概念，如"客户编号"在A系统中为 CustID，在B系统中为 CustomerNo，数据仓库需统一为同一名称。
• 统一编码结构：同一属性在不同系统中可能采用不同的编码。例如，"性别"字段在一个系统中用"男/女"表示，在另一个系统中用"1/0"表示，在第三个系统中用"M/F"表示。数据仓库必须将其转化为统一编码。
• 统一属性度量：不同业务部门可能使用不同的度量单位。例如，国内仓库以"千克"计量货物重量，而国际航运部门以"磅"计量。数据仓库需将所有度量单位转换为统一标准。

数据在从操作型数据库迁移到数据仓库的过程中，必须经历转化处理，将原始数据从不统一的状态转变为一致的、可比较的状态。

案例：水情数据仓库

防汛减灾是一项涉及多部门协作的系统工程。一个典型的水情数据仓库需要集成以下多源数据：

• 水文监测站：提供水位、流量、降雨量等实时观测数据。
• 气象部门：提供天气预报、降雨预测、台风路径等气象信息。
• 水利工程部门：提供大堤抗洪能力、水库蓄水量、闸门状态等工程信息。
• 应急管理部门：提供守堤抢险人员部署、巡查记录等人力资源数据。
• 物资保障部门：提供抗洪物资储备量、调配记录等后勤保障数据。

这些数据来自不同部门、不同系统，数据格式和采集频率各异。通过数据仓库的集成，才能为防汛指挥决策提供统一的、全面的数据视图。

2. 面向主题

主题（Subject）是指特定的数据分析领域与目标，是用户使用数据仓库进行决策分析时所关注的核心对象。

面向主题意味着数据仓库中的数据按照分析主题来组织，而不是按照业务流程或应用系统来组织。传统操作型数据库中的数据是面向具体应用的原始数据，而数据仓库中的数据则需要对原始数据进行抽取、加工和汇总，形成围绕特定分析主题的完整信息集合。

案例：从面向事务的"商场"数据库到面向主题的数据仓库

以一个面向事务处理的商场数据库系统为例，其数据按照业务流程组织在四个子系统中：

采购子系统：

• 订单（订单号，供应商号，总金额，日期）
• 订单细则（订单号，商品号，类别，单价，数量）
• 供应商（供应商号，供应商名，地址，电话）

销售子系统：

• 顾客（顾客号，姓名，性别，年龄，文化程度，地址，电话）
• 销售（员工号，顾客号，商品号，数量，单价，日期）

库存管理子系统：

• 领料单（领料单号，领料人，商品号，数量，日期）
• 进料单（进料单号，订单号，进料人，收料人，日期）
• 库存（商品号，库房号，库存量，日期）
• 库房（库房号，仓库管理员，地点，库存商品描述）

人事管理子系统：

• 员工（员工号，姓名，性别，年龄，文化程度，部门号）
• 部门（部门号，部门名称，部门主管，电话）

上述数据模式基本上是按照企业内部的业务活动及其相关数据来组织数据的存储的，没有实现真正的数据与应用分离，其抽象程度也不够高。

如果按照面向主题的方式重新组织数据，首先应按照管理人员的分析要求来确定主题。例如，商场管理者关心三个核心分析主题：商品、供应商和顾客。

主题一：商品

• 商品固有信息：商品号，商品名，类别，颜色等
• 商品采购信息：商品号，供应商号，供应价，供应日期，供应量等
• 商品销售信息：商品号，顾客号，售价，销售日期，销售量等
• 商品库存信息：商品号，库房号，库存量，日期等

主题二：供应商

• 供应商固有信息：供应商号，供应商名，地址，电话等
• 供应商品信息：供应商号，商品号，供应价，供应日期，供应量等

主题三：顾客

• 顾客固有信息：顾客号，顾客名，性别，年龄，文化程度，住址，电话等
• 顾客购物信息：顾客号，商品号，售价，购买日期，购买量等

在每个主题中，都集中了与该主题相关的所有信息，同时抛弃了与分析处理无关或不需要的数据，如领料单中的领料人等操作性细节。原本分散在各个子系统中的相关信息被集中到一个主题中，形成有关该主题的一个完整、一致的描述。

3. 反映历史变化

数据仓库是从历史角度提供信息的。与操作型数据库相比，数据仓库在时间维度上存在显著差异：

表8-1 操作型数据库与数据仓库的时间特征对比

例如，在操作型数据库中，当某商品的价格从50元调整为60元时，价格字段直接被更新为60，旧值50被覆盖。而在数据仓库中，两条记录都会被保留——一条标注价格50元（有效期为2024年1月至6月），另一条标注价格60元（有效期为2024年7月起），使分析人员能够追溯价格变动的完整历史。

4. 相对稳定性

尽管数据仓库中的数据来源于操作型数据库，但它们在物理上是分离保存的。数据仓库与操作型数据库在数据操作方式上有本质区别：

• 操作型数据库的更新操作（INSERT、UPDATE、DELETE）不会直接出现在数据仓库环境中。
• 数据仓库不需要事务处理、故障恢复和并发控制等复杂机制。
• 数据仓库只涉及两种基本的数据访问操作：数据的批量载入和数据的查询访问。

这种相对稳定的特性使得数据仓库可以针对查询分析场景进行深度优化（如建立大量索引、创建物化视图等），而不必担心这些优化措施会影响事务处理的性能。

8.1.4 数据仓库四大特征

表8-2 数据仓库四大特征综合对比

8.2 OLTP与OLAP

8.2.1 基本概念

数据仓库技术的出现，催生了两种截然不同的数据处理范式：联机事务处理（OLTP）和联机分析处理（OLAP）。

联机事务处理（Online Transaction Processing, OLTP）是指对数据库进行日常联机操作，通常涉及对一个或一组记录的查询和修改。OLTP系统的典型应用场景包括：购买下单、库存扣减、银行转账、工资发放、注册登记、记账核算等。OLTP系统的核心要求是快速响应用户请求，对数据的安全性、完整性以及事务吞吐量要求很高。

联机分析处理（Online Analytical Processing, OLAP）是指对海量历史数据进行的查询和分析操作。OLAP系统的典型应用场景包括：数据分析与决策支持，以不同形式显示数据以满足不同用户的分析需要。OLAP系统的核心要求是能够处理大量数据，执行复杂的查询和分析操作。

传统数据库管理系统（DBMS）的主要任务是联机事务处理 OLTP，服务于企业的日常运营；而数据仓库（Data Warehouse）的主要任务是联机分析处理 OLAP，服务于企业的分析决策。二者有着本质不同的设计目标和优化方向。

8.2.2 OLTP与OLAP对比

下表从11个维度对 OLTP 与 OLAP 进行系统对比：

表8-3 OLTP 与 OLAP 的对比

8.2.3 为什么需要独立的数据仓库

既然 OLTP 和 OLAP 服务于不同的目标，为什么不能在同一个系统中同时完成事务处理和分析处理呢？需要将二者分离的原因主要体现在两个层面：

一、性能层面的冲突

DBMS 是为 OLTP 而设计的，其存储方式、索引策略、并发控制和恢复机制都围绕事务处理进行了优化。例如，OLTP 系统通常采用行式存储（Row-oriented Storage），将一条记录的所有字段连续存储在磁盘上，这样在插入或更新一条完整记录时效率最高。

而数据仓库是为 OLAP 而设计的，需要高效执行复杂的分析查询、多维视图计算和数据汇总。OLAP 系统更适合采用列式存储（Column-oriented Storage），将同一字段的所有值连续存储，这样在对单个字段进行大规模聚合计算时效率极高。

如果在事务处理过程中执行大规模的分析查询，会占用大量的 CPU 和 I/O 资源，导致在线事务的响应时间急剧增加，影响正常的业务运营。

二、数据层面的差异

除了系统性能上的冲突，OLTP 与 OLAP 在数据本身的特点上也存在明显差异。在历史数据方面，决策支持需要长期积累的历史数据，用于趋势分析和预测；而操作型数据库为了保证事务处理效率，通常只保留当前周期内的数据。其次，在数据汇总方面，决策支持需要对来自多个异构数据源的数据进行聚集和汇总；而操作型数据库存储的是细粒度的原始数据，难以直接满足这种需求。最后，在数据质量方面，不同源系统往往采用不一致的数据表示、编码和格式，必须先对这些数据进行转换和集成，才能开展有效的分析。

8.3 多维数据模型

8.3.1 多维数据模型基础

OLAP 工具以多维数据模型（Multidimensional Data Model）为基础。在多维数据模型中，数据以数据立方体（Data Cube）的形式存在，允许从多个维度观察和分析数据。数据立方体由维（Dimension）和事实（Fact）共同定义。

维（Dimension）是一个组织想要记录的视角或观点。每个维都有一个与之关联的表，称为维表（Dimension Table）。维表存储该维度的详细描述信息。常见的维包括：

• 时间（Time）：日期、星期几、月份、季度、年份
• 地点（Location）：街道、城市、省份/州、国家
• 商品（Item）：商品名、品牌、类型、供应商类型
• 分支机构（Branch）：分支名称、分支类型

多维数据模型围绕中心主题组织，该主题用事实表（Fact Table）表示。事实表包含事实的名称或度量（Measure）以及每个相关维表的外键（Foreign Key）。事实（Fact）指的是一些数字度量，如销售数量（units_sold）、销售金额（dollars_sold）、平均销售额（avg_sales）等。

8.3.2 数据立方体的维度与层级

二维数据立方体(2-D)本质上等价于一个关系表。例如，以时间为行、商品为列形成的二维表，单元格中存储的是销售金额。这也就是日常所见的交叉表或透视表。

当增加一个观察维度（如地点）后，二维表就扩展为三维数据立方体(3-D)。可以形象地将其理解为一摞二维表——每一层对应一个地点，每层内部仍是时间和商品的二维矩阵。

在数据仓库中，数据立方体通常是 n 维的。给定一个维的集合，可以构造不同的数据立方体，每个数据立方体在不同的汇总级别或不同的数据子集上展示数据。

在数据立方体理论中，一个重要的概念是方体（Cuboid）：

表8-4 数据立方体中的方体类型

以包含时间（Time）、商品（Item）、地点（Location）和供应商（Supplier）四个维度的数据立方体为例，所有可能的方体构成一个格（Lattice）结构：

• 0-D 方体（顶点）：all（全局总计）
• 1-D 方体：time、item、location、supplier（共4个）
• 2-D 方体：time×item、time×location、time×supplier、item×location、item×supplier、location×supplier（共6个）
• 3-D 方体：time×item×location、time×item×supplier、time×location×supplier、item×location×supplier（共4个）
• 4-D 方体（基本）：time×item×location×supplier（共1个）

8.3.3 概念分层

概念分层定义了一个映射序列，将低层的、细粒度的概念映射到更一般的、粗粒度的高层概念。例如，对于地点（Location）维，概念分层为：

又如，时间（Time）维的概念分层为：

概念分层允许用户在各种抽象级别审查和处理数据。通过在多维数据模型的不同维上定义概念分层，用户可以在不同维度、不同粒度层次上灵活地观察数据。多维数据模型与概念分层的结合，为 OLAP 操作提供了理论基础。

8.4 数据仓库的概念模型

数据仓库概念模型通常以多维数据模型为基础。在关系型数据库环境中，多维数据模型主要有三种实现形式：星型模式、雪花模式和事实星座模式。

8.4.1 星型模式

星型模式是数据仓库建模中最基本、最常用的模式。

1. 结构特征

星型模式由一个事实表和若干个维表组成。事实表位于模型的中心，维表围绕事实表排列，通过外键与事实表连接。由于维表围绕事实表呈辐射状分布，整体形状类似于星星，因此被称为"星型模式"。

图8-2 星型模式的基本结构

2. 事实表的设计

事实表是星型模式的核心，存储着企业的业务度量数据。事实表的每一行记录一个具体的业务事件，列分为两类：

(1) 维度外键：指向各维表主键的引用，用于标识"何时""何地""何物""谁"等上下文信息。

(2) 度量（Measure）：数值型的业务指标，是分析查询的计算对象。度量可分为三种类型：

表8-5 度量的三种类型

以销售分析为例，一个典型的事实表结构如下：

表8-6 Sales 事实表

3. 维表的设计

维表存储分析上下文的描述性信息，是用户进行"按××维度分析"的基础。与事实表相反，维表通常包含较多列但行数较少，呈现"又宽又浅"的结构特点。

以 Sales 事实表关联的四个维表为例：

表8-7 time 维表

表8-8 location 维表

表8-9 item 维表

表8-10 branch 维表

在 time 维表中，day、month、quarter、year 这些属性形成了一个自然的概念分层（日→月→季度→年）；在 location 维表中，street、city、state_or_province、country 同样形成了概念分层（街道→城市→省份→国家）。这些概念分层为后续的上卷（Roll-Up）和下钻（Drill-Down）操作提供了基础。

4. 星型模式的优点与局限

星型模式的优点主要体现在以下几个方面：

1. 查询简单。 所有分析查询都以事实表为中心，通过简单的星形连接即可获取数据，SQL 语句结构清晰，易于理解和编写。
2. 性能优越。 维表的扁平结构避免了多层雪花式连接，数据库优化器可以利用星形连接优化技术提升查询性能。
3. 易于理解。 星型模式的结构直观，业务人员无需了解复杂的规范化理论，就能理解数据之间的关系。
4. 工具兼容。 主流 BI 工具（如 Tableau、Power BI）都原生支持星型模式，能够自动识别事实表和维表。 同时，星型模式也存一定的局限，维表中有数据冗余，例如 location 维表中每条记录都重复记录了城市所属的省份和国家。

5. 星型模式应用示例

在物流领域，星型模式可以很自然地用于运输绩效分析：

表8-11 运输绩效分析的星型模式模型

管理者可以利用该模型分析"某一季度各承运商在不同线路上的平均在途天数和准时率"，从而为承运商选择和线路优化提供数据支持。

8.4.2 雪花模式

雪花模式是星型模式的变种。在雪花模式中，某些维表被进一步规范化，将原本合并在一张维表中的层级信息拆分到多个附加表中。由于维表被拆分后呈现出层级分支的结构，整体模式图的形状类似于雪花，因此称为"雪花模式"。

以商品维度为例，在星型模式中，商品维表包含商品名、子品类、大品类等所有属性。而在雪花模式中，这些信息被拆分为三张表：

表8-12 雪花模式下的商品维度表结构

图8-3 商品维表规范化后的雪花模式片段

雪花模式的本质就是将星型模式中揉在一起的维度属性，通过规范化手段拆解开来。

雪花模式的优缺点：

雪花模式的优点主要体现在两个方面：一是减少了维表中的数据冗余，从而节省存储空间；二是维表的维护更加规范，例如更新某个品类名称时，只需修改一处即可。与此同时，雪花模式也存在不足：一方面，查询时需要进行更多的表连接操作，导致查询性能下降；另一方面，模型结构更加复杂，业务人员的理解难度也随之增加。在实际工程中，由于存储成本持续降低而查询性能始终是关键瓶颈，星型模式在多数场景下优于雪花模式，是数据仓库建模的首选方案。

8.4.3 事实星座模式

当企业有多个分析主题需要共享相同的维度信息时，可以采用事实星座模式。在这种模式中，多个事实表共享部分维表，整体结构可以看作多个星型模式的集合，因此也称为星系模式（Galaxy Schema）。

以一个同时分析销售和物流运输的场景为例：

表8-13 事实星座模式示例：Sales 与 Shipping 事实表

图8-4 由 Sales 与 Shipping 两个星型模式共享维度形成的事实星座模式

事实星座模式的关键约束是一致性维度（Conformed Dimension）。被多个事实表共享的维表必须在所有事实表中保持完全一致的定义和标识。例如，如果 item 维表同时被 Sales 和 Shipping 事实表引用，那么同一商品在两个事实表中必须使用相同的商品键（如 item_key = 1001）。

如果两个事实表引用的维度不一致，例如销售部门和采购部门对同一商品使用了不同的编号，那么这就不是真正的星座模型，而是两个数据孤岛，将导致企业无法进行跨部门的关联分析。

8.4.4 三种概念模型的综合比较

表8-14 三种概念模型的综合比较

8.5 OLAP 操作

多维数据模型结合概念分层，为用户提供了从不同角度、不同层次观察数据的灵活性。在此基础上，可以定义一系列 OLAP 操作，帮助分析人员在数据立方体上进行交互式的探索分析。OLAP 的核心操作主要包括五种：上卷、下钻、切片、切块和转轴。

8.5.1 上卷（Roll-Up）

上卷操作是对数据进行汇总，从细粒度数据向粗粒度数据聚合。上卷有两种实现方式：

方式一：沿概念分层向上攀升

沿某个维度的概念分层从低层向高层聚合数据。

如某物流企业的数据仓库记录了每天每个城市的包裹投递数量。管理者想了解按季度、按省份的投递总量。此时，需要在时间维上从"日"上卷到"季度"，在地点维上从"城市"上卷到"省份"。

方式二：通过维归约实现汇总

直接去掉一个或多个维度，对剩余维度上的数据进行聚合。例如，去掉地点维度，只保留时间维度，得到各季度的全国投递总量。这种方式相当于在被去掉的维度上进行了全范围求和。

8.5.2 下钻（Drill-Down）

下钻是上卷的逆操作，从汇总数据深入到更详细的数据。下钻同样有两种实现方式：

方式一：沿概念分层向下展开

沿某个维度的概念分层从高层向低层展开。

如管理者在看到"2024 Q1 江苏省投递总量为 568 万件"的汇总数据后，想进一步了解各城市的具体分布。此时，在地点维上从"省份"下钻到"城市"：

方式二：引入新的维度

通过增加一个新的分析维度来展现更多细节。例如，在原有"时间×地点"的分析基础上，引入"承运商"维度，查看各承运商在不同地区的绩效表现，使分析从二维扩展到三维。

8.5.3 切片（Slice）

切片操作在数据立方体的一个维度上选定一个特定的值，将 n 维立方体"切"成一个 (n-1) 维的子方体。

示例：在一个包含时间、地点和商品三个维度的销售数据立方体上，选定时间维 = "2024 Q2"，得到一个只包含 2024 年第二季度数据的二维切面，该切面展示所有地点和商品的销售情况。切片操作本质上是一个在指定维度上添加等值过滤条件的查询操作。

8.5.4 切块（Dice）

切块操作通过在两个或更多维度上同时进行选择来定义一个子方体。与切片选定一个值不同，切块在每个维度上可以选定一个值范围或多个值。

如：在销售数据立方体上，同时选定时间维：2024 Q1 或 2024 Q2；地点维：北京 或 上海；商品维：商品A 或 商品B，就可以得到一个更小的子方体。

切块操作本质上是在多个维度上同时添加范围过滤条件或IN筛选条件的查询操作。切片可以视为切块的一个特殊情况。

8.5.5 转轴（Pivot）

转轴操作是对数据立方体进行重定位或视角旋转的可视化操作。它不改变数据本身的值，而是改变数据的呈现方式，将维度在行和列之间进行交换，或将一个高维立方体转化为一系列低维的平面表格。

如：行列交换

原始视图以时间为行、商品为列：

表8-15 转轴前：以时间为行、商品为列的销售视图

转轴后以商品为行、时间为列：

表8-16 转轴后：以商品为行、时间为列的销售视图

虽然数据值完全相同，但通过行列交换，观察者更容易看出各商品随时间的增长趋势。转轴操作的价值在于，同一份数据，从不同的视角呈现，往往能揭示不同的业务洞察。

8.5.6 其他 OLAP 操作

除了上述五种核心操作外，OLAP 系统还支持以下扩展操作：

(1) 钻过（Drill-Across）

钻过操作用于执行跨越多个事实表的查询。在事实星座模式中，多个事实表共享一致性维度。当分析需求涉及两个或多个事实表中的度量时，就需要通过共享的维度将不同事实表的数据关联起来。

例如，管理者想分析"各商品的销售额与运输成本的比率"。销售额来自 Sales 事实表，运输成本来自 Shipping 事实表，二者通过共享的 item 和 time 维表进行关联。

(2) 钻透（Drill-Through）

钻透操作使用关系 SQL 机制，穿透数据立方体的聚合层，直接访问底层关系数据库中的明细记录。当分析人员在 OLAP 报表中发现某个异常数据点时，可以钻透到支撑该数据点的原始交易记录，查看具体明细。

例如，管理者发现某月某线路的运输成本异常偏高，通过钻透操作可以查看该月该线路的每一笔运输单据，找出成本异常的具体原因。

(3) Top-N / Bottom-N 排序

列出某一度量指标排名最高或最低的 N 项记录。例如，"销售额前10名的产品"或"准时率最低的5条运输线路"。

(4) 计算型操作

在 OLAP 环境中常用的计算型操作包括：

• 移动平均值：计算滑动窗口内的平均值，消除短期波动。物流应用示例：计算过去12周的平均周投递量。
• 增长率：计算同比/环比增长百分比。物流应用示例：计算仓储成本的月度环比增长率。
• 占比分析：计算部分相对于整体的百分比。物流应用示例：各区域运输成本占全国总成本的比例。
• 累计汇总：计算从期初到当前时点的累计值。物流应用示例：年初至今的累计销售额。

8.6 数据仓库体系结构

8.6.1 三层数据仓库架构

数据仓库系统通常采用三层架构，从下到上分别是：数据仓库数据库服务器、OLAP 服务器和前端客户工具层。

1. 底层

底层是数据仓库的数据存储与管理层。其核心任务是从多种异构数据源中提取数据并加载到数据仓库中。数据源包括操作型数据库（通过 ODBC、JDBC、OLE/DB 等网关连接）、外部数据文件、Web 日志等。

数据仓库数据库通常是一个面向查询和追加的集中式数据库，配备大量的索引和物化视图（Materialized View）以加速分析查询。与操作型数据库不同，它一般不支持事务性的更新操作。

2. 中间层

中间层是 OLAP 分析引擎，负责将底层存储的数据转化为支持多维分析的形式。根据实现方式的不同，OLAP 服务器可分为三种类型：

表8-17 OLAP 服务器的三种类型

3. 前端工具层

前端工具层是用户直接交互的界面，提供多种数据访问和分析手段：

• 查询工具：支持用户自定义的即席查询（Ad-hoc Query）
• 报表工具：生成标准报表和定制化报表，支持定时推送
• 分析工具：提供多维分析、统计分析和可视化展示功能
• 数据挖掘工具：运用机器学习和统计算法，从数据中发现隐含模式与规律

图8-5 数据仓库的三层体系结构

8.6.2 ETL工具与数据流转

ETL（Extract-Transform-Load，抽取-转换-加载）是数据仓库建设中最为核心的技术环节。ETL 工具负责将数据从源系统搬运到数据仓库，是连接操作型系统和分析型系统的桥梁。

ETL 流程的三个阶段：

(1) 抽取（Extract）：从多个异构数据源中读取原始数据。数据源可以是关系型数据库、CSV 文件、XML 文件、API 接口、日志文件等。

(2) 转换（Transform）：对抽取的数据进行清洗和转化，包括：

• 数据清洗：处理缺失值、纠正错误数据、统一格式。
• 数据关联：将来自不同源的相关数据进行连接（Join）。
• 数据聚合：按分析需求对细粒度数据进行汇总计算。
• 数据过滤：筛选出符合条件的数据，排除无关记录。
• 格式转换：统一日期格式、货币单位、编码体系等。
• 去重：识别指向同一实体的多条重复记录并合并。

(3) 加载（Load）：将转换后的数据写入数据仓库。加载方式包括全量加载和增量加载。

图8-6 ETL 的基本数据流转过程

此外，ETL 过程还涉及两项辅助功能：

• 数据画像（Profiling）：对数据源进行统计分析，构建数据分布的直方图、统计摘要表等，帮助理解数据质量状况。
• 质量管理（Quality Management）：对照主数据值、已知的业务规则和约束条件进行自动化测试，确保进入数据仓库的数据满足质量标准。

8.6.3 元数据管理

元数据（Metadata）是"关于数据的数据"，记录了数据仓库中数据的来源、含义、转换规则、存储位置和更新频率等信息。元数据在数据仓库体系结构中起到目录和导航的作用。

元数据的主要内容包括：

• 技术元数据：表结构定义、字段类型、索引信息、ETL 转换规则、数据源映射关系、加载时间表。
• 业务元数据：业务术语定义、度量指标的计算口径、数据所有者、数据质量标准。
• 操作元数据：ETL 运行日志、数据加载记录、错误报告、系统性能监控数据。

元数据存储库（Metadata Repository）是数据仓库体系结构中的重要组成部分，它支撑着数据仓库的日常监控、问题排查和系统整合。没有完善的元数据管理，数据仓库将变成一个"黑箱"——用户无法理解数据的含义，运维人员无法追踪数据的来源和加工过程。

8.7 数据仓库的部署模型

从体系结构的角度来看，数据仓库的部署模型主要有三种：企业数据仓库、数据集市和虚拟数据仓库。

8.7.1 企业数据仓库

企业数据仓库收集跨越整个组织的所有主题信息，是企业级的统一数据分析平台。从数据覆盖范围来看，企业数据仓库覆盖全企业范围，整合所有业务系统的数据，数据体量通常在数百 GB 至数 PB 级别。由于需要全面的规划和协调，其建设周期较长，通常需要数月至数年。企业数据仓库适用于大型企业的全局决策支持，尤其是需要跨部门、跨业务线进行综合分析的场景。典型代表包括大型零售企业、金融机构和电信运营商的企业级数据平台。

8.7.2 数据集市

数据集市是企业范围数据的一个子集，面向特定部门或特定业务领域的分析需求。其范围限于选定的主题，如市场营销数据集市、财务分析数据集市、物流运营数据集市等。数据集市根据数据来源的不同，分为两种类型：

独立的数据集市

• 直接从操作型数据源获取数据，独立构建
• 优点：建设速度快、成本低、灵活性高
• 缺点：缺乏统一的数据标准，容易形成数据孤岛，不同数据集市之间的数据可能不一致

非独立的数据集市

• 从企业数据仓库中提取数据，是企业数据仓库的衍生产品
• 优点：与企业数据仓库保持数据一致性，确保不同部门使用相同的数据标准
• 缺点：依赖于企业数据仓库的建设，前期投入较大

在实际应用中，如果企业尚未建设企业级数据仓库，可以先从独立的数据集市开始，快速满足部门级的分析需求；待条件成熟后，再将各数据集市整合为企业数据仓库。但需要注意的是，如果独立数据集市在建设时缺乏统一规划，后期的整合成本可能非常高昂。

8.7.3 虚拟数据仓库

虚拟数据仓库并不物理地存储一份独立的数据副本，而是在操作型数据库之上建立一系列视图（View），将视图呈现给分析用户。

在数据存储方面，虚拟数据仓库不独立存储数据，而是依赖操作型数据库，且只展示部分可能的汇总视图。在建设成本方面，它是三种模型中最低的，无需单独的硬件和 ETL 流程。因此，它适用于资源有限的小型组织、快速原型验证以及临时性的分析需求。但虚拟数据仓库也存在明显局限：分析查询会影响操作型数据库的事务处理性能，无法存储历史数据，查询功能也较为受限。

8.7.4 部署比较

表8-18 三种部署模型的综合比较

本章小结

本章围绕数据仓库的基本概念、数据模型、分析技术与部署方式展开。数据仓库源于消除多系统点对点接口形成的“蛛网”结构、支持企业级决策分析的需要。按照 Inmon 的定义，数据仓库是面向主题的、集成的、反映历史变化的、相对稳定的数据集合，与面向日常事务处理的 OLTP 系统在服务对象、数据内容和性能指标上存在明显差异。

在多维数据模型方面，事实、维、度量和数据立方体构成了分析的基础；概念分层支持上卷与下钻，星型模式、雪花模式和事实星座模式分别适用于不同的建模场景，缓慢变化维则要求在历史追溯与数据更新之间做出合理处理。在分析操作方面，切片、切块、转轴等 OLAP 操作可以从多角度观察数据，ROLAP、MOLAP 和 HOLAP 在存储方式与查询性能上各有特点。

数据仓库的建设离不开 ETL 过程和元数据管理，前者保证数据的抽取、转换与加载质量，后者保障数据的可理解性与可管理性。在部署上，企业数据仓库、数据集市和虚拟数据仓库在成本、周期、一致性和性能方面各有取舍，应结合企业规模与需求选择。数据仓库为物流运输、仓储、配送等领域的绩效分析与决策提供了坚实的数据基础，并与数据挖掘相互补充。

课后习题

1. 写出数据仓库的定义，并结合实例解释集成性、面向主题、反映历史变化和相对稳定的含义。
2. 比较 OLTP 与 OLAP 在服务对象、数据内容、访问模式、任务单位、数据规模和主要性能指标方面的区别。
3. 什么是维、维表、事实、事实表和度量？说明一个销售事实表通常包含哪些维度和度量。
4. 简述概念分层的作用。以地点维为例，说明如何利用概念分层实现上卷和下钻。
5. 比较星型模式、雪花模式和事实星座模式的结构特点、优缺点及适用场景。
6. 分别说明切片和切块操作的区别，并写出在一个三维销售数据立方体上执行切片和切块的查询条件。
7. 结合物流业务，设计一个运输绩效分析数据模型。要求指出事实表、主要维表、核心度量以及可执行的上卷、下钻、切片和转轴操作。

参考文献

[1] W. H. Inmon. Building the Data Warehouse[M]. 4th ed. Indianapolis: Wiley Publishing, 2005.

[2] Ralph Kimball, Margy Ross. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling[M]. 3rd ed. Indianapolis: Wiley, 2013.

[3] Jiawei Han, Micheline Kamber, Jian Pei. Data Mining: Concepts and Techniques[M]. 3rd ed. Waltham: Morgan Kaufmann, 2012.

[4] Intellipaat. Data Warehouse Tutorial: A Step-by-Step Guide for Beginners[EB/OL]. https://intellipaat.com/blog/tutorial/data-warehouse-tutorial/.

[5] W3Schools. Data Warehouse Tutorial[EB/OL]. https://www.w3schools.com/datascience/ds_data_warehouse.asp.

[6] Oracle. Database Data Warehousing Guide[EB/OL]. https://docs.oracle.com/en/database/oracle/oracle-database/19/dwhsg/.