数据仓库 Data warehouse

数据仓库产生背景

大规模数据被存储在数据库中，一些非热点数据需要我们对其进行处理计算，根据这些数据得出一些我们在某个时间段或某个背景下想要得到的数据。

一、数据处理方式

1.1 OLTP（On-line Transaction Processing），联机事务处理

具有事务的特性，常用来处理高并发且数据量不大的查询。OLT主要是为了处理数据库，用于优化查询和负载，常见的优化在于主码索引和散列

1.2 OLAP（On-line analytical Processing）联机分析处理

OLAP则是为了分析数据而设计的，其查询方式往往是复杂的，通常会设计到大量的数据汇总计算。

1.3 OLAP基本操作

上卷：

将数据进行聚合处理，通过一个维度向更高的维度靠拢

下钻：

对数据进行拆分处理，将数据从高维拆分到低维

切片：

对某一维度数据进行切分，只关注特定的维度

切块：

对多个维度进行切分，只关注特定的维度

二、数据建模

良好的模型能帮我们快速查询需要的数据，减少IO吞吐。

关系建模：

3范式：

1NF：列不可再分

2NF：所有的列必须依赖主键

3NF：如果出现部分列不依赖主键，则把这部分列重新构建一张表

表于表关系：

1V1 相同主键，互相持有对方主键

1Vn 多方持有一方的主键

nVn 构建中间表，通过俩张表的主键连接到一起

维度建模：

在维度建模中，将度量称为 “ 事实 ” ， 将环境描述为 “ 维度 ” 。

维度表：

一般是对事实描述信息。每一张维度表对应着实现世界中的一个对象或者概念

特点：行数较少，内容固定

建模四部曲

选择业务：比如商城，整个商城流程分为商家端，用户端，平台端，运营需求是总订单量，订单人

数，及用户的购买情况等，选择业务很重要，后面几乎所有的步骤都是基于业务展开的

声明粒度： 一行代表信息：一条订单？一天的订单？一周的订单？ 选择最小粒度，对于有明确需

求的数据，我们建立 针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。
 

确认维度：维度退化：谁 。 什么时间 什么地点 数仓工具箱中告诉我们 牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一

确认事实：度量值：如个数，件数，金额

事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中

的数据是一个特定级别的细节数据，称为粒度。

维度建模的核心原则之一 是同一事实表中的所有度量必须具有相同的粒度 。这样能确保

不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属

性。记住 最实用的事实就是数值类型和可加类事实 。所以可以通过分析该列是否是一种

包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。

设计原则（了解）

维度属性尽量丰富，为数据使用打下基础

比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基

础。

给出详实的、富有意义的文字描述

属性不应该是编码，而应该是真正的文字。在间里巴巴维度建模中， 一般是编码和文字

同时存在，比如商品维度中的商品 ID 和商品标题、 类目 ID 和 类目名称等。 ID 一 般用

于不同表之间的关联，而名称一般用 于报表标签

区分数值型属性和事实

数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。 如果通常用于查询约

束条件或分组统计，则是作为维度属性 ; 如果通常 用于参与度量的计算， 则是作为事

实。比如商品价格，可以用于查询约 束条件或统计价格区间 的商品数量，此时是作为维

度属性使用的 ; 也可 以用于统计某类目 下商品的平均价格，此时是作为事实使用的。另

外， 如果数值型字段是离散值，则作为维度属性存在的可能性较大 ; 如果数 值型宇段是

连续值 ，则作为度量存在的可能性较大，但并不绝对，需要 同时参考宇段的具体用途。

沉淀出通用的维度属性，为建立一致性维度做好铺垫

有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通

过单表 的不同宇段混合处理得到，或者通过对单表 的某个字段进行解析得到。此时，需

要将尽可能多的通用的维度属性进 行沉淀。 一方面，可以提高下游使用的方便性，减少复杂度 ;

另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。

退化维度（ DegenerateDimension ）

在维度类型中，有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放

在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常

重要的作用，退化维度一般在分析中可以用来做分组使用。

缓慢变化维（ Slowly Changing Dimensions ）

维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的

维度我们一般称之为缓慢变化维（ SCD ），缓慢变化维一般使用代理健作为维度表的主健。

事实表：

表中的每一行数据代表一个业务事件。事实表示业务事件的度量值

特征：非常的大，内容相对较窄，经常发生变化

事实表分类：

事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的

一行数据。

一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，以具有规律性

的、可预见的时间间隔记录事实。

例如每天或每月的总销售金额，或每月的账户余额等。

累积型快照事实表

累积快照事实表用于跟踪业务事实的变化，覆盖过程的整个生命周期，通常具有多个日

期字段来记录关键时间点。 例如数据仓库中可能需要累积或者存储订单从下单开始，到订单商品被打包、运输、签

收等各个业务阶段的时间点数据，来跟踪订单生命周期的进展情况。

当这个业务过程进行时，事实表的记录也要不断更新。

三、数据组织类型

维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。

3.1  星型模型

是一种多维的数据关系，它由一个事实表（ Fact Table ）和一组维表（ Dimension Table ）组成。

每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。

星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一

定的冗余

3.2 雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像

多个雪花连接在一起，故称雪花模型。

雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小

的事实表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。

通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗

余。

3.3 星座模型

星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型。

星座模型是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座模型只反映是否

有多个事实表，他们之间共享一些维度表。

实际企业开发中，一般不会只选择一种，需要根据情况灵活组合，甚至并存（一层维度和多层

维度都保存）。

整体来看，更倾向于维度更少的星型模型。尤其是大型数据仓库项目，减少表连接的次数，可

以显著提升查询效率。

四、数仓特性

4.1 面向主题

定好一个主题之后才能进行数据仓库的构建

主题 (Subject)是对应企业中某一宏观分析领域所涉及的分析对象（重点是分析的对象，对象，仔细理解 一下对象的含义）。例如： " 销售分析 " 就是一个分析领域，这个 " 销售分析"所涉及到的分析对象为商品、 供应商、顾客、仓库等，那么数仓主题可以确定为商品主题、供应商主题、顾客主题、仓库主题；联系到下文 " 销售分析 " 可以作为一个主题域；如果 " 产品分析 " 是一个分析领域， " 产品分析"所涉及到的分析对 象为商品、地域、时间、类别等，那么数仓的主题确定为商品主题、地域主题、时间主题、类别主 题， " 产品分析 " 可以作为一个主题域。

4.2 集成性

数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成， 统一与综合之后才能进入数据仓库，这一步时数据仓库中最关键、最复杂的一步，所有完成的工作有：

1. 要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等；

2. 进行数据综合和计算，数据仓库中的数据综合工作可以在从源数据库中抽取时生成，但许多是在数据仓库内部生成的。

4.3 不可更新性

数据非易失性主要针对与应用而言，数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要 是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

4.4 时变性

数据仓库中包含各种粒度的历史数据，数据仓库中的数据可能和特定的某个日期、星期、月份、季度和年份有关。数据仓库的目的是根据企业过去一段时间里业务的经营状况，挖掘其中隐藏的模式。虽然数 据仓库的用户不能修改数据，但并不是说数据仓库中的数据是永远不变的。分析结果只是反应过去的情 况，当业务发生变化后，挖掘出的模式就会失去失效性。因此数据仓库中的数据需要更新，以适用决策 的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程。数据仓库的数据随时间的变化表现 在以下几个方面：

1. 数据仓库的数据时效一般要远远长于操作型数据库数据的时效。

2. 操作性数据库存库的是当前数据，而数据仓库中存储的是历史数据。

3. 数据仓库中的数据是按照时间顺序进行追加的，它们都带有时间属性。

五、数据分仓

5.1 分仓原因

减少不同业务对相同数据同样的计算

避免底层数据发生改变而影响上层数据

简化操作的复杂度

5.2 分仓的好处

清晰的数据结构

方便数据学院追踪

减少重复开发

把复杂问题简单化

屏蔽原始数据的异常

5.3 分仓明细

ODS层

原始数据

经过简单处理过的数据

DW层

按照主题加工后的数据模型

ADS层

应用数据服务层

5.4 阿里五层数仓

ODS

DW

DWD 数据和数据仓库隔离,可以将数据进一步细化,准备数据

DWS 提供一些数据的清洗转换,并进行汇总整合一些维度信息

DWT 基于某些主题数据已经准备完毕,根据主题维度汇聚到一起开始计算

ADS

六、常见概念

6.1  数据仓库

概念：

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理

中的决策制定。

特点：

首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库 ;

其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数

据，而且存放在数据仓库中的数据一般不再修改。

应用场景：

一般都是作为商业智能系统、数据仪表盘等可视化报表服务的数据源。

数据仓库是一个功能概念 ，是将企业的各业务系统产生的基础数据，通过维度建模的方式，将业务

数据划分为多个主题（集市）统一存储，统一管理。

6.2 数据集市

数据集市可以理解为是一种 " 小型数据仓库 " ，它只包含单个主题，且关注范围也非全局。数据

集市可以分为两种 :

分类：

独立数据集市，这类数据集市有自己的源数据库和 ETL 架构；

非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓库。

应用场景：

数据集市是数仓之上更聚焦的业务主题合集，更偏向于应对业务数据快速高效应用的需求，一

般用于商业智能系统中探索式和交互式数据分析应用。

数据集市是一个结构概念， 它是企业级数据仓库的一个子集，主要面向部门级业务，并且只面向某

个特定的主题。

6.3 数据孤岛

业务系统之间各自为政、相互独立造成的数据孤岛，体现在业务不集成、流程不互通、数据不共

享。

6.4 数据湖

概念：

2010 年， Pentaho 首席技术官 James Dixon 创造了 “ 数据湖 ” 一词。

他把数据集市描述成一瓶清洗过的、包装过的和结构化易于使用的水。

数据湖更像是在自然状态下的水，数据流从源系统流向这个湖。用户可以在数据湖里校验，取

样或完全的使用数据。

特点：

从源系统导入所有的数据，没有数据流失。

数据存储时没有经过转换或只是简单的处理。

数据转换和定义 schema 用于满足分析需求。

应用场景：

以大数据技术为基础有多样化数据结构海量大数据存储需求，也可作为数据仓库或者数据集市

的数据源。

数据湖是一种数据存储理念， 存储企业各种各样的原始数据的大型仓库，包括结构化、非结构、二

进制图像、音频、视频等等。

6.5 数据中台

概念：

数据中台是指通过企业内外部多源异构的数据采集、治理、建模、分析，应用，使数据对内优

化管理提高业务，对外可以数据合作价值释放，成为企业数据资产管理中枢。数据中台建立

后，会形成数据 API ，为企业和客户提供高效各种数据服务。

特点：

利用大数据技术，对海量数据进行统一采集、计算、存储，并使用统一的数据规范进行管理，

将企业内部所有数据统一处理形成标准化数据，挖掘出对企业最有价值的数据，构建企业数据

资产库，提供一致的、高可用大数据服务。

数据中台不是一套软件，也不是一个信息系统，而是一系列数据组件的集合，企业基于自身的

信息化建设基础、数据基础以及业务特点对数据中台的能力进行定义，基于能力定义利用数据

组件搭建自己的数据中台。

应用场景：

是将数据服务化提供给业务系统，目的是将数据能力渗透到业务各个环节，不限于决策分析。

数据中台是一个逻辑概念 ，为业务提供服务的主要方式是数据 API ，它包括了数据仓库，大数据、

数据治理领域的内容。

七、 宽表窄表

7.1. 宽表

从字面意义上讲就是字段比较多的数据库表。

通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。

由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要

坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。

这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可

以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。

7.2. 窄表

严格按照数据库设计三范式。尽量减少数据冗余，但是缺点是修改一个数据可能需要修改多张表。

方便扩展，能适应各种复杂的数据结构（树形、继承等），无论有多少配置，都不用修改表结构。

但代码逻辑可能需要包装一下。

八、 ETL

8.1  概念：

ETL 是将业务系统的数据经过抽取（ Extract ）、清洗转换（ Transform ）之后加载（ Load ）到数据

仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分

析依据。

五大模块：

数据抽取、数据清洗、库内转换、规则检查、数据加载。

各模块可灵活进行组合，形成 ETL 处理流程。

8.2  模块介绍

数据抽取

确定数据源，需要确定从哪些源系统进行数据抽取

定义数据接口，对每个源文件及系统的每个字段进行详细说明

确定数据抽取的方法：是主动抽取还是由源系统推送？是增量抽取还是全量抽取？是按照每日

抽取还是按照每月抽取？

数据清洗

主要将不完整数据、错误数据、重复数据进行处理

数据转换

空值处理：可捕获字段空值，进行加载或替换为其他含义数据，或数据分流问题库

数据标准：统一元数据、统一标准字段、统一字段类型定义

数据拆分：依据业务需求做数据拆分，如身份证号，拆分区划、出生日期、性别等

数据验证：时间规则、业务规则、自定义规则

数据替换：对于因业务因素，可实现无效数据、缺失数据的替换

数据关联：关联其他数据或数学，保障数据完整性

8.3  ETL 工具

ETL 工具（ sqoop ， DataX ， Kettle ， canal ， StreamSets ）

sqoop ：

是 Apache 开源的一款在 Hadoop 和关系数据库服务器之间传输数据的工具。

将一个关系型数据库（ MySQL ,Oracle 等）的数据导入到 Hadoop 的 HDFS 中，也可以将 HDFS

的数据导出到关系型数据库中。

sqoop 命令的本质是转化为 MapReduce 程序。

sqoop 分为导入（ import ）和导出（ export ）

策略分为 table 和 query

模式分为增量和全量。

DataX

DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具 / 平台

实现包括 MySQL 、 Oracle 、 SqlServer 、 Postgre 、 HDFS 、 Hive 、 ADS 、 HBase 、

TableStore(OTS) 、、 DRDS 等各种异构数据源之间高效的数据同步功能。

Kettle

一款国外免费开源的、可视化的、功能强大的 ETL 工具，纯 java 编写

可以在 Windows 、 Linux 、 Unix 上运行，数据抽取高效稳定。

canal

canal 是阿里巴巴旗下的一款开源项目，纯 Java 开发。

基于数据库增量日志解析，提供增量数据实时订阅和消费，目前主要支持了 MySQL ，也支持

mariaDB 。

StreamSets

是大数据实时采集 ETL 工具，可以实现不写一行代码完成数据的采集和流转。

通过拖拽式的可视化界面，实现数据管道 (Pipelines) 的设计和定时任务调度。

创建一个 Pipelines 管道需要配置数据源 (Origins) 、操作 (Processors) 、目的地 (Destinations)

三部分。

8.4  加载策略

系统日志分析方式

通过分析数据库自身的日志来判断变化的数据。

触发器方式

直接进行数据加载

利用增量日志表进行增量加载

时间戳方式

在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。

全表比对方式

全表比对即在增量抽取时， ETL 进程逐条比较源表和目标表的记录，将新增和修改的记录读取

出来。

源系统增量 （ delta ） 数据直接或者转换后加载

日常的 ETL 更新中，还会遇到目标表的数据来源来自于多张源表，通过关键字段的拼接进行

更新操作。

如果多张源表都有时间戳字段，可以利用时间戳进行增量更新，另外还可以采用全表比对的方

式进行增量更新。

九、 数据仓库元数据

9.1  业务元数据

描述 ” 数据 ” 背后的业务含义

主题定义：每段 ETL 、表背后的归属业务主题。

业务描述：每段代码实现的具体业务逻辑。

标准指标：类似于 BI 中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。

标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。

不断的进行维护且与业务方进行沟通确认。

9.2  技术元数据

数据源元数据

例如：数据源的 IP 、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的

定义及 key 指对应的值。

ETL 元数据

根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。

数据清洗，主要目的是为了解决掉脏数据及规范数据格式；因此此处元数据主要为：各表各列

的 " 正确 " 数据规则；默认数据类型的 " 正确 " 规则。

数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。源数据到数

仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。

数据仓库元数据

数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；业务系

统、数据仓库和数据集市的体系结构和模式等。

BI 元数据

汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的

查询与报告。