数据仓库理论

数据仓库

什么是数据仓库？

1988年，为解决全企业集成问题，IBM公司第一次提出了信息仓库（Information Warehouse）的概念。数据仓库的基本原理、技术架构以及分析系统的主要原则都已确定，数据仓库初具雏形。

1991年Bill Inmon（比尔·恩门）出版了他的第一本关于数据仓库的书《Building the Data Warehouse》，标志着数据仓库概念的确立。书中指出，数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化的(Time Variant)数据集合，用于支持管理决策(Decision-Making Support)。该书还提供了建立数据仓库的指导意见和基本原则。凭借着这本书，Bill Inmon被称为数据仓库之父。

四大特征

面向主题的

与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。
- 什么是主题呢？
  - 主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象
  - 在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象面向主题的数据组织方式，就是在较高层次上对分析对象的数据的一个完整、一致的描述，能完整、统一地刻划各个分析对象所涉及的企业的各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。
  例如销售情况分析就是一个分析领域，那么数据仓库的分析主题可以是“销售分析”。
集成的

数据仓库的数据是从原有的分散的多个数据库、数据文件、用户日志中抽取来的，数据来源可能既有内部数据又有外部数据。操作型数据与分析型数据之间差别很大：
- 数据仓库的每一个主题所对应的源数据，在原有的各分散数据库中有重复和不一致的地方，且来源于不同的联机系统的数据与不同的应用逻辑捆绑在一起
- 数据仓库中的数据很难从原有数据库系统直接得到。数据在进入数据仓库之前，需要经过统一与综合
数据仓库中的数据是为分析服务的，而分析需要多种广泛的不同数据源以便进行比较、鉴别，数据仓库中的数据会从多个数据源中获取，这些数据源包括多种类型数据库、文件系统以及Internet网上数据等，它们通过数据集成而形成数据仓库中的数据。
稳定的

数据仓库数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。

数据稳定主要是针对应用而言。数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。
反映历史变化的

数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。虽然数据仓库不会修改数据，但并不是说数据仓库的数据是永远不变的。数据仓库的数据也需要更新，以适应决策的需要。数据仓库的数据随时间的变化表现在以下几个方面：
- 数据仓库的数据时限一般要远远长于操作型数据的数据时限
- 业务系统存储的是当前数据，而数据仓库中的数据是历史数据
- 数据仓库中的数据是按照时间顺序追加的，都带有时间属性

作用

整合企业业务数据，建立统一的数据中心；

产生业务报表，了解企业的经营状况；

为企业运营、决策提供数据支持；

可以作为各个业务的数据源，形成业务数据互相反馈的良性循环；

分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；

开发数据产品，直接或间接地为企业盈利；

与数据库的区别

数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。

OLTP（On-Line Transaction Processing 联机事务处理），也称面向交易的处理系统。主要针对具体业务在数据库系统的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。

OLAP（On-Line Analytical Processing 联机分析处理），一般针对某些主题的历史数据进行分析，支持管理决策。

数据仓库的出现，并不是要取代数据库：

数据仓库主要用于解决企业级的数据分析问题或者说管理和决策
数据仓库是为分析数据而设计，数据库是为捕获和存储数据而设计
数据仓库是面向分析，面向主题设计的，即信息是按主题进行组织的，属于分析型；数据库是面向事务设计的，属于操作型

数据仓库在设计是有意引入数据冗余（目的是为了提高查询的效率），采用反范式的方式来设计；数据库设计是尽量避免冗余（第三范式），一般采用符合范式的规则来设计
数据仓库较大，数据仓库中的数据来源于多个异构的数据源，而且保留了企业的历史数据；数据库存储有限期限、单一领域的业务数据

以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记账。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存取款多，消费交易多，那么该地区就有必要设立ATM了。

银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的大型数据库。

对比内容	数据库	数据仓库
数据内容	近期值、当前值	历史的、归档的数据
数据目标	面向业务操作	面向管理决策、面向分析（主题）
数据特性	动态频繁更新静态、	不能直接更新；定时添加数据
数据结构	高度结构化、满足第三范式	简单的、冗余的、满足分析的
使用频率	高	低
数据访问量	访问量大；每次访问的数据量少	访问量小；每次访问的数据量大
对响应时间的要求	高	低（不敏感）

数据集市

数据仓库（DW）是一种反映主题的全局性数据组织。但全局性数据仓库往往太大，在实际应用中将它们按部门或业务分别建立反映各个子主题的局部性数据组织，即数
据集市（Data Mart），有时也称它为部门数据仓库。

数据集市：是按照主题域组织的数据集合，用于支持部门级的数据分析与决策。如在商品销售的数据仓库中可以建立多个不同主题的数据集市：

商品采购数据集市
商品库存数据集市
商品销售数据集市

数据集市仅仅是数据仓库的某一部分，实施难度大大降低，并且能够满足企业内部部分业务部门的迫切需求，在初期获得了较大成功。但随着数据集市的不断增多，这种架构的缺陷也逐步显现。企业内部独立建设的数据集市由于遵循不同的标准和建设原则，以致多个数据集市的数据混乱和不一致，形成众多的数据孤岛。

企业发展到一定阶段，出现多个事业部，每个事业部都有各自数据，事业部之间的数据往往都各自存储，各自定义。每个事业部的数据就像一个个孤岛一样无法(或者极其困难)和企业内部的其他数据进行连接互动。这样的情况称为数据孤岛，简单说就是数据间缺乏关联性，彼此无法兼容。

数据仓库建模方法

数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。有了适合业务和基础数据存储环境的模型，能获得以下好处：

性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐
成本：良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本
效率：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率
质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性

大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

ER模型

数据仓库之父Bill Inmon提出的建模方法是从全企业的高度设计一个3NF模型，用实体关系(Entity Relationship, ER)模型描述企业业务，在范式理论上符合3NF。数据仓库中的3NF与OLTP系统中的3NF 的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。其具有以下几个特点：

需要全面了解整个企业业务和数据
实施周期非常长
对建模人员的能力要求非常高

釆用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。其建模步骤分为三个阶段：

高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况
中层模型：在高层模型的基础上，细化主题的数据项
物理模型(也叫底层模型)：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等

维度模型

维度模型是数据仓库领域的Ralph Kimball大师所倡导的，他的《数据仓库工具箱》是数据仓库工程领域最流行的数据仓库建模经典。

维度建模从分析决策的需求出发构建模型，为分析需求服务，重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星型模型，以及在一些特殊场景下使用的雪花模型。其设计分为以下几个步骤：

选择需要进行分析决策的业务过程。业务过程可以是：
- 单个业务事件，比如交易的支付、退款等
- 某个事件的状态，比如当前的账户余额等
- 一系列相关业务事件组成的业务流程
选择数据的粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度
识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选
选择事实。确定分析需要衡量的指标

现代企业业务变化快、人员流动频繁、业务知识功底的不够全面，导致ER模型设计产出周期长。大多数企业实施数据仓库的经验说明：在不太成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。而维度建模对技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能。

数据仓库分层

数据仓库更多代表的是一种对数据的管理和使用的方式，它是一整套包括了数据建模、ETL（数据抽取、转换、加载）、作用调度等在内的完整的理论体系流程。数据仓库在构建过程中通常都需要进行分层处理。业务不同，分层的技术处理手段也不同。

分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控。详细来讲，主要有下面几个原因：

清晰的数据结构

每一个数据分层都有它的作用域，在使用表的时候能更方便地定位和理解。
将复杂的问题简单化

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的问题，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的地方开始修复。
减少重复开发

规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
屏蔽原始数据的异常

屏蔽业务的影响，不必改一次业务就需要重新接入数据。
数据血缘的追踪

最终给业务呈现的是一个能直接使用业务表，但是它的来源很多，如果有一张来源表出问题了，借助血缘最终能够快速准确地定位到问题，并清楚它的危害范围。

数仓的常见分层一般为3层，分别为：数据操作层、数据仓库层和应用数据层（数据集市层）。当然根据研发人员经验或者业务，可以分为更多不同的层，只要能达到流程清晰、方便查数即可。

ODS（Operation Data Store 数据准备区）。数据仓库源头系统的数据表通常会原封不动的存储一份，这称为ODS层，也称为准备区。它们是后续数据仓库层加工数据的来源。ODS层数据的主要来源包括：

业务数据库。可使用DataX、Sqoop等工具来抽取，每天定时抽取一次；在实时应用中，可用Canal监听MySQL的 Binlog，实时接入变更的数据；
埋点日志。线上系统会打入各种日志，这些日志一般以文件的形式保存，可以用Flume 定时抽取；
其他数据源。从第三方购买的数据、或是网络爬虫抓取的数据；

DW（Data Warehouse 数据仓库层）。包含DWD、DWS、DIM层，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

DWD（Data Warehouse Detail 细节数据层），是业务层与数据仓库的隔离层。以业务过程作为建模驱动，基于每个具体的业务过程特点，构建细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，也即宽表化处理；
DWS（Data Warehouse Service 服务数据层），基于DWD的基础数据，整合汇总成分析某一个主题域的服务数据。以分析的主题为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表；
公共维度层（DIM）：基于维度建模理念思想，建立一致性维度；
TMP层：临时层，存放计算过程中临时产生的数据；

ADS（Application Data Store 应用数据层）。基于DW数据，整合汇总成主题域的服务数据，用于提供后续的业务查询等。

数据仓库层次的划分不是固定不变的，可以根据实际需求进行适当裁剪或者是添加。如果业务相对简单和独立，可以将DWD、DWS进行合并。

数据仓库模型

事实表与维度表

事实表

在数据仓库中，保存度量值的详细值或事实的表称为事实表。

事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据。事实表的粒度决定了数据仓库中数据的详细程度。

常见事实表：订单事实表

事实表的特点：表多（各种各样的事实表）；数据量大

事实表根据数据的粒度可以分为：事务事实表、周期快照事实表、累计快照事实表
维度表

维度表（维表）可以看作是用来分析数据的角度，纬度表中包含事实数据表中事实记录的特性。有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息。

常见维度表：时间维度、地域维度、商品维度
小结

事实表是关注的内容（如：销售额、销售量）

维表是观察事务的角度

事实表分类

事务事实表

事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

事务事实表的日期维度记录的是事务发生的日期，它记录的事实是事务活动的内容。用户可以通过事务事实表对事务行为进行特别详细的分析。

如：订单表

通过事务事实表，还可以建立聚集事实表，为用户提供高性能的分析。
周期快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存日快照表等。它统计的是间隔周期内的度量统计，如历史至今、自然年至今、季度至今等等。

周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。周期快照事实表的维度个数比事务事实表要少，但是记录的事实要比事务事实表多。

如：商家日销售表（无论当天是否有销售发生，都记录一行）日期、商家名称、销售量、销售额
累积快照事实表

累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。

累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。

如：订货日期、预定交货日期、实际发货日期、实际交货日期、数量、金额、运费

如：商家本周、本月、本年累计销售表