数据仓库基础

数据仓库

数据仓库概念

数据仓库（英语：Data Warehouse，简称数仓、DW）,是一个用于存储、分析、报告的数据系统。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。

数据仓库本身并不“生产”任何数据，其数据来源于不同外部系统；同时数据仓库自身也不需要“消费”任何的数据，其结果开放给各个外部应用使用，这也是为什么叫“仓库”，而不叫“工厂”的原因。

数据仓库的产生

为了分析数据而来，分析结果给企业决策提供支撑。

信息总是用作两个目的：

操作型记录的保存和分析型决策的制定。
数据仓库是信息技术长期发展的产物。

以中国人寿保险公司（chinalife）发展为例

操作型记录的保存：

中国人寿保险（集团）公司下辖多条业务线，包括：人寿险、财险、车险，养老险等。各业务线的业务正常运营需要记录维护包括客户、保单、收付费、核保、理赔等信息。

联机事务处理系统（OLTP） 正好可以满足上述业务需求开展, 其主要任务是执行联机事务和查询处理。其基本特征是前台接收的用户数据可以立即传送到后台进行处理，并在很短的时间内给出处理结果。

关系型数据库是 OLTP 典型应用，比如：Oracle、Mysql、SQL Server 等。

分析型决策的制定：

基于业务数据开展数据分析，基于分析的结果给决策提供支撑。也就是所谓的数据驱动决策的制定。

OLTP的核心是面向业务，支持业务，支持事务。所有的业务操作可以分为读、写两种操作，一般来说读的压力明显大于写的压力。如果在OLTP环境直接开展各种分析，有以下问题需要考虑：

数据分析也是对数据进行读取操作，会让读取压力倍增；
OLTP仅存储数周或数月的数据；
数据分散在不同系统不同表中，字段类型属性不统一；

当分析所涉及数据规模较小的时候，在业务低峰期时可以在OLTP系统上开展直接分析。但是为了更好的进行各种规模的数据分析，同时也不影响OLTP系统运行，此时需要构建一个集成统一的数据分析平台。

该目的很简单：面向分析，支持分析。并且和OLTP系统解耦合。

数据仓库的构建

如数仓定义所说,数仓是一个用于存储、分析、报告的数据系统，目的是构建面向分析的集成化数据环境。

把这种面向分析、支持分析的系统称之为OLAP（联机分析处理）系统。数据仓库是OLAP一种。

中国人寿保险公司就可以基于分析决策需求，构建数仓平台：

数据仓库的数据模型

在数据仓库建设中，一般会围绕着星型模型和雪花模型来设计数据模型。每个数据仓库都包含一个或者多个事实数据表。

事实表

事实表是对分析主题的度量，它包含了与各维度表相关联的外键，并通过连接（Join）方式与维度表关联。

事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。

例如现存在一张订单事实表，其字段Prod_id（商品id）可以关联商品维度表、TimeKey（订单时间）可以关联时间维度表等。
维度表

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

维度表包含帮助汇总数据的特性的层次结构，维度是对数据进行分析时特有的一个角度，站在不同角度看待问题，会有不同的结果。

维度表信息较为固定，且数据量小，维度表中的列字段可以将信息分为不同层次的结构级。

例如当分析产品销售情况时，可以选择按照商品类别、商品区域进行分析，此时就构成一个类别、区域的维度。

星型模型

在数据仓库建模中，星型模型是维度建模中的一种选择方式。星型模型是以一个事实表和一组维度表组合而成，并且以事实表为中心，所有的维度表直接与事实表相连。

所有的维度表都直接连接到事实表上，维度表的主键放置在事实表中，作为事实表与维度表连接的外键，因此，维度表和事实表是有关联的，然而，维度表与维度表并没有直接相连，因此，维度表之间是并没有关联的。

雪花模型

雪花模型也是维度建模中的另一种选择，它是对星型模型的扩展。

从上图中可以看出，雪花模型的维度表可以拥有其他的维度表，并且维度表与维度表之间是相互关联的。因此，雪花模型相比星型模型更规范一些。但是，由于雪花模型需要关联多层的维度表，因此，性能也比星型模型要低，所以一般不是很常用。

数据仓库主要特征

数据仓库：

面向主题性（Subject-Oriented ）
集成性（Integrated）
非易失性（Non-Volatile）
时变性（Time-Variant ）数据集合，用以支持管理决策。

面向主题性

数据库中，最大的特点是 面向应用 进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。

操作型处理（传统数据）对数据的划分并不适用于决策分析。而基于主题组织的数据则不同，它们被划分为各自独立的领域，每个领域有各自的逻辑内涵但互不交叉，在抽象层次上对数据进行完整、一致和准确的描述。

集成性

确定主题之后，就需要获取和主题相关的数据。当下企业中主题相关的数据通常会分布在多个操作型系统中，彼此分散、独立、异构。

因此在数据进入数据仓库之前，必然要经过统一与综合，对数据进行抽取、清理、转换和汇总，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：

要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。

下图说明了保险公司综合数据的简单处理过程，其中数据仓库中与“承保”主题有关的数据来自于多个不同的操作型系统。

这些系统内部数据的命名可能不同，数据格式也可能不同。把不同来源的数据存储到数据仓库之前，需要去除这些不一致。

数据仓库的数据集成*

非易失性

数据仓库是分析数据的平台，而不是创造数据的平台。

数据仓库的主要功能是分析历史数据，而不是实时更新或修改数据。进入数据仓库的数据通常稳定且长期保留，用户主要进行查询和挖掘操作，很少进行修改或删除。

时变性

数据仓库包含各种粒度的历史数据，数据可能与某个特定日期、星期、月份、季度或者年份有关。虽然数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。

分析的结果只能反映过去的情况，当业务变化后，挖掘出的模式会失去时效性。因此数据仓库的数据需要随着时间更新，以适应决策的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程。

数据仓库的数据随时间的变化表现在以下几个方面:

数据仓库的数据时限一般要远远长于操作型数据的数据时限。
操作型系统存储的是当前数据，而数据仓库中的数据是历史数据。
数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。

数据仓库、数据库、数据集市

OLTP、OLAP

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

联机分析处理（OLAP，Online Analytical Processing）系统，也叫DSS决策支持系统，主要目标是做数据分析。一般针对某些主题的历史数据进行复杂的多维分析，支持管理决策。数据仓库是OLAP系统的一个典型示例，主要用于数据分析。

多个不同角度来对比OLTP和OLAP

	OLTP	OLAP
数据源	仅包含当前运行日常业务数据	整合来自多个来源的数据，包括OLTP和外部来源
目的	面向应用，面向业务，支撑事务	面向主题，面向分析，支撑分析决策
焦点	当下	主要面向过去、面向历史实时数仓
任务	读写操作	大量读而很少写操作
响应时间	毫秒	秒、分钟、小时或者天取决于数据量和查询复杂性
数据量	小数据，MB,GB	大数据，TP，PB
示例应用	处理付款、客户数据管理、订单处理	分析趋势、预测客户行为、确定盈利能力

数据仓库、数据库

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

OLTP系统的典型应用就是RDBMS,也就是我们俗称的数据库，特别强调此数据库表示的是关系型数据库，Nosql数据库并不在范围内。

OLAP系统的典型应用就是DW,也就是我们俗称的数据仓库。因此数据仓库和数据库的区别就很好掌握了。但是有几点需要着重强调：

数据仓库不是大型的数据库，虽然数据仓库存储数据规模大。
数据仓库的出现，并不是要取代数据库。
数据库是面向事务的设计，数据仓库是面向主题设计的。
数据库一般存储业务数据，数据仓库存储的一般是历史数据。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

数据仓库、数据集市

数据仓库是面向整个集团组织的数据，数据集市是面向单个部门使用的。可以认为数据集市是数据仓库的子集，也有人把数据集市叫做小型数据仓库。

数据集市通常只涉及一个主题领域，例如市场营销或销售。因为它们较小且更具体，所以它们通常更易于管理和维护，并具有更灵活的结构。

上图所示：

各种操作型系统数据和包括文件在内的等其他数据作为数据源，经过ETL(抽取转换加载)填充到数据仓库中；

数据仓库中有不同主题数据，数据集市则根据部门特点面向指定主题，比如Purchasing（采购）、Sales（销售）、Inventory（库存）；

用户可以基于主题数据开展各种应用：数据分析、数据报表、数据挖掘。

ETL 和 ELT

数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程。但是在实际操作中将数据加载到仓库却产生了两种不同做法：ETL和ELT。

ETL(Extract，Transform，Load):

首先从数据源池中提取数据，这些数据源通常是事务性数据库。数据保存在临时暂存数据库中。然后执行转换操作，将数据结构化并转换为适合目标数据仓库系统的形式。然后将结构化数据加载到仓库中，以备分析。

ELT(Extract，Load，Transform):

使用ELT，数据在从源数据池中提取后立即加载。没有临时数据库，这意味着数据会立即加载到单一的集中存储库中。数据在数据仓库系统中进行转换，以便与商业智能工具和分析一起使用。大数据时代的数仓这个特点很明显。

数据仓库分层架构

数仓分层思想和标准

数据仓库的特点是 本身不生产数据，也不最终消费数据。 按照数据流入流出数仓的过程进行分层就显得水到渠成。

数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层，操作型数据层（ODS）、数据仓库层(DW)和数据应用层(DA)。

企业在实际运用中可以基于这个基础分层之上添加新的层次，来满足不同的业务需求。

为什么要分层?

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

清晰数据结构

每一个数据分层都有它的作用域，在使用表的时候能更方便地定位和理解。
数据血缘追踪

简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，能够快速准确地定位到问题，并清楚它的危害范围。
减少重复开发

规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
把复杂问题简单化

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

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

阿里巴巴数仓3层架构

操作型数据层（ODS，Operation Data Store）

也称之为源数据层、数据引入层、数据暂存层、临时缓存层、贴源层。

此层存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。

主要完成基础数据引入到数仓的职责，和数据源系统进行解耦合，同时记录基础数据的历史变化。
数据仓库层（DW，Data Warehouse）

内部具体包括DIM维度表、DWD和DWS，由ODS层数据加工而成。

主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

公共维度层（DIM，Dimension）：维度表，基于维度建模理念思想，建立整个企业一致性维度。

明细粒度事实层（DWD，Data Warehouse Detail）: 明细层，存储原始明细数据，是数据仓库中最为详细的数据层。

公共汇总粒度事实层（DWS，Data Warehouse Summary、DWB，Data Warehouse Base）：汇总层，以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。
数据应用层（DA或ADS）
面向最终用户，面向业务定制提供给产品和数据分析使用的数据。包括前端报表、分析图表、KPI、仪表盘、OLAP专题、数据挖掘等分析。

美团点评酒旅数据仓库建设实践

下面通过一线互联网企业真实的数仓建设实践案例，来从宏观层面感受

数仓面向主题分析的特点
在企业中数仓是一个不断维护的工程。
数仓分层并不局限于经典3层，可以根据自身需求进行调整
没有好的架构，只有适合自己业务需求的架构
它山之石可以攻玉

美团数仓技术架构：架构变迁

美团点评酒旅事业群内，业务由传统的团购形式转向预订、直连等更加丰富的产品形式，业务系统也在迅速的迭代变化，这些都对数据仓库的扩展性、稳定性、易用性提出了更高要求。基于此，美团采取了分层次、分主题的方式不断优化并调整层次结构，下图展示了技术架构的变迁。

第一代数仓模型层次中，由于当时美团整体的业务系统所支持的产品形式比较单一（团购），业务系统中包含了所有业务品类的数据，所以由平台的角色来加工数据仓库基础层是非常合适的，平台统一建设，支持各个业务线使用，所以在本阶段中酒旅只是建立了一个相对比较简单的数据集市。

第二代数仓模型层次的建设，由建设数据集市的形式转变成了直接建设酒旅数据仓库，成为了酒旅自身业务系统数据的唯一加工者。
随着美团和点评融合，同时酒旅自身的业务系统重构的频率也相对较高，对第二代数仓模型稳定性造成了非常大的影响，原本的维度模型非常难适配这么迅速的变化。核心问题是在用业务系统和业务线关系错综复杂，业务系统之间差异性明显且变更频繁。

于是在ODS与多维明细层中间加入了数据整合层，参照Bill Inmon所提出的企业信息工厂建设的模式，基本按照三范式的原则来进行数据整合，由业务驱动调整成了由技术驱动的方式来建设数据仓库基础层。
使用本基础层的最根本出发点还是在于美团的供应链、业务、数据它们本身的多样性，如果业务、数据相对比较单一、简单，本层次的架构方案很可能将不再适用。

美团数仓业务架构：主题建设

实际上在传统的一些如银行、制造业、电信、零售等行业里，都有一些比较成熟的模型，如耳熟能详的BDWM模型，它们都是经过一些具有相类似行业的企业在二三十年数据仓库建设中所积累的行业经验，不断的优化并通用化。但美团所处的O2O行业本身就没有可借鉴的成熟的数据仓库主题以及模型，所以，在摸索建设两年的时间里，美团总结了下面比较适合现状的七大主题（后续可能还会新增）