关于数据仓库:干货-万字详解整个数据仓库设计体系

数据仓库的基本概念

数据仓库概念:

英文名称为 Data Warehouse，可简写为 DW 或 DWH。数据仓库的目标是 构建面向剖析的集成化数据环境，为企业提供决策反对（Decision Support）。它出于剖析性报告和决策反对目标而创立。

数据仓库自身并不“生产”任何数据，同时本身也不须要“生产”任何的数据，数据来源于内部，并且凋谢给内部利用，这也是为什么叫“仓库”，而不叫“工厂”的起因。

基本特征:

数据仓库是 面向主题的 、 集成的 、 非易失的 和时变的 数据汇合，用以反对管理决策。

注：文章首发于公众号：五分钟学大数据

1. 面向主题:

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

1. 集成性:

通过对扩散、独立、异构的数据库数据进行 抽取、清理、转换和汇总 便失去了数据仓库的数据，这样保障了数据仓库内的数据对于整个企业的一致性。

数据仓库中的综合数据不能从原有的数据库系统间接失去。因而在数据进入数据仓库之前，必然要通过对立与综合，这一步是数据仓库建设中最要害、最简单的一步，所要实现的工作有：

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

下图阐明一个保险公司综合数据的简略处理过程，其中数据仓库中与“保险”主题无关的数据来自于多个不同的操作型零碎。这些零碎外部数据的命名可能不同，数据格式也可能不同。把不同起源的数据存储到数据仓库之前，须要去除这些不统一。

1. 非易失性（不可更新性）

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

数据非易失性次要是针对利用而言。数据仓库的用户对数据的操作大多是数据查问或比较复杂的开掘，一旦数据进入数据仓库当前，个别状况下被较长时间保留。数据仓库中个别有大量的查问操作，但批改和删除操作很少。因而，数据经加工和集成进入数据仓库后是极少更新的，通常只须要定期的加载和更新。

1. 时变性

数据仓库蕴含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份无关。数据仓库的目标是通过剖析企业过来一段时间业务的经营情况，开掘其中暗藏的模式。尽管 数据仓库的用户不能批改数据，但并不是说数据仓库的数据是永远不变的。剖析的后果只能反映过来的状况，当业务变动后，挖掘出的模式会失去时效性。因而数据仓库的数据须要更新，以适应决策的须要。从这个角度讲，数据仓库建设是一个我的项目，更是一个过程。数据仓库的数据随工夫的变动体现在以下几个方面：

（1）数据仓库的数据时限个别要远远长于操作型数据的数据时限。
（2）操作型零碎存储的是以后数据，而数据仓库中的数据是历史数据。
（3）数据仓库中的数据是依照工夫程序追加的，它们都带有工夫属性。

1. 数据仓库与数据库的区别

数据库与数据仓库的区别理论讲的是 OLTP 与 OLAP 的区别。

操作型解决，叫联机事务处理 OLTP（On-Line Transaction Processing，），也能够称面向交易的解决零碎，它是针对具体业务在数据库联机的日常操作，通常对多数记录进行查问、批改。用户较为关怀操作的响应工夫、数据的安全性、完整性和并发反对的用户数等问题。传统的数据库系统作为数据管理的次要伎俩，次要用于操作型解决，像 Mysql，Oracle 等关系型数据库个别属于 OLTP。

剖析型解决，叫联机剖析解决 OLAP（On-Line Analytical Processing）个别针对某些主题的历史数据进行剖析，反对管理决策。

首先要明确，数据仓库的呈现，并不是要取代数据库。数据库是面向事务的设计，数据仓库是面向主题设计的。数据库个别存储业务数据，数据仓库存储的个别是历史数据。

数据库设计是尽量避免冗余，个别针对某一业务利用进行设计，比方一张简略的 User 表，记录用户名、明码等简略数据即可，合乎业务利用，然而不合乎剖析。数据仓库在设计是无意引入冗余，按照剖析需要，剖析维度、剖析指标进行设计。

数据库是为捕捉数据而设计，数据仓库是为剖析数据而设计。

以银行业务为例。数据库是事务零碎的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，能够简略地了解为用数据库记账。数据仓库是剖析零碎的数据平台，它从事务零碎获取数据，并做汇总、加工，为决策者提供决策的根据。比方，某银行某分行一个月产生多少交易，该分行以后贷款余额是多少。如果贷款又多，生产交易又多，那么该地区就有必要设立 ATM 了。

显然，银行的交易量是微小的，通常以百万甚至千万次来计算。事务零碎是实时的，这就要求时效性，客户存一笔钱须要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而剖析零碎是预先的，它要提供关注时间段内所有的无效数据。这些数据是海量的，汇总计算起来也要慢一些，然而，只有可能提供无效的剖析数据就达到目标了。

数据仓库，是在数据库曾经大量存在的状况下，为了进一步开掘数据资源、为了决策须要而产生的，它决不是所谓的“大型数据库”。

2. 数据仓库分层架构

依照数据流入流出的过程，数据仓库架构可分为：源数据 、 数据仓库 、 数据利用

数据仓库的数据来源于不同的源数据，并提供多样的数据利用，数据自下而上流入数据仓库后向下层凋谢利用，而数据仓库只是两头集成化数据管理的一个平台。

源数据：此层数据无任何更改，间接沿用外围零碎数据结构和数据，不对外开放；为长期存储层，是接口数据的长期存储区域，为后一步的数据处理做筹备。

数据仓库：也称为细节层，DW 层的数据应该是统一的、精确的、洁净的数据，即对源零碎数据进行了荡涤（去除了杂质）后的数据。

数据利用：前端利用间接读取的数据源；依据报表、专题剖析需要而计算生成的数据。

数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都能够认为是 ETL（抽取 Extra, 转化 Transfer, 装载 Load）的过程，ETL 是数据仓库的流水线，也能够认为是数据仓库的血液，它维系着数据仓库中数据的推陈出新，而数据仓库日常的治理和保护工作的大部分精力就是放弃 ETL 的失常和稳固。

那么为什么要数据仓库进行分层呢?

• 用空间换工夫，通过大量的预处理来晋升利用零碎的用户体验（效率），因而数据仓库会存在大量冗余的数据；不分层的话，如果源业务零碎的业务规定发生变化将会影响整个数据荡涤过程，工作量微小。
• 通过数据分层治理能够 简化数据荡涤的过程，因为把原来一步的工作分到了多个步骤去实现，相当于把一个简单的工作拆成了多个简略的工作，把一个大的黑盒变成了一个白盒，每一层的解决逻辑都绝对简略和容易了解，这样咱们比拟容易保障每一个步骤的正确性，当数据产生谬误的时候，往往咱们只须要部分调整某个步骤即可。

3. 数据仓库元数据的治理

元数据（Meta Date），次要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的工作运行状态。个别会通过元数据资料库（Metadata Repository）来对立地存储和治理元数据，其次要目标是使数据仓库的设计、部署、操作和治理能达成协同和统一。

元数据是数据仓库管理系统的重要组成部分，元数据管理是企业级数据仓库中的要害组件，贯通数据仓库构建的整个过程，间接影响着数据仓库的构建、应用和保护。

• 构建数据仓库的次要步骤之一是 ETL。这时元数据将施展重要的作用，它定义了源数据系统到数据仓库的映射、数据转换的规定、数据仓库的逻辑构造、数据更新的规定、数据导入历史记录以及装载周期等相干内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据高效地构建数据仓库。
• 用户在应用数据仓库时，通过元数据拜访数据，明确数据项的含意以及定制报表。
• 数据仓库的规模及其复杂性离不开正确的元数据管理，包含减少或移除内部数据源，扭转数据荡涤办法，管制出错的查问以及安顿备份等。

元数据可分为技术元数据和业务元数据。技术元数据 为开发和治理数据仓库的 IT 人员应用，它形容了与数据仓库开发、治理和保护相干的数据，包含数据源信息、数据转换形容、数据仓库模型、数据荡涤与更新规定、数据映射和拜访权限等。而 业务元数据 为管理层和业务剖析人员服务，从业务角度形容数据，包含商务术语、数据仓库中有什么数据、数据的地位和数据的可用性等，帮忙业务人员更好地了解数据仓库中哪些数据是可用的以及如何应用。

由上可见，元数据不仅定义了数据仓库中数据的模式、起源、抽取和转换规则等，而且是整个数据仓库零碎运行的根底，元数据把数据仓库零碎中各个涣散的组件分割起来，组成了一个有机的整体。

数仓建模办法

数据仓库的建模办法有很多种，每一种建模办法代表了哲学上的一个观点 ，代表了一种演绎、概括世界的一种办法。常见的有 范式建模法、维度建模法、实体建模法 等，每种办法从实质上将是从不同的角度对待业务中的问题。

1. 范式建模法（Third Normal Form，3NF）

范式建模法其实是咱们在构建数据模型罕用的一个办法，该办法的次要由 Inmon 所提倡，次要解决关系型数据库的数据存储，利用的一种技术层面上的办法。目前，咱们在关系型数据库中的建模办法，大部分采纳的是三范式建模法。

范式 是合乎某一种级别的关系模式的汇合。结构数据库必须遵循肯定的规定，而在关系型数据库中这种规定就是范式，这一过程也被称为规范化。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyce-Codd 范式（BCNF）、第四范式（4NF）和第五范式（5NF）。

在数据仓库的模型设计中，个别采纳第三范式。一个合乎第三范式的关系必须具备以下三个条件 :

• 每个属性值惟一，不具备多义性 ;
• 每个非主属性必须齐全依赖于整个主键，而非主键的一部分 ;
• 每个非主属性不能依赖于其余关系中的属性，因为这样的话，这种属性应该归到其余关系中去。

依据 Inmon 的观点，数据仓库模型的建设办法和业务零碎的企业数据模型相似。在业务零碎中，企业数据模型决定了数据的起源，而企业数据模型也分为两个档次，即主题域模型和逻辑模型。同样，主题域模型能够看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化。

2. 维度建模法（Dimensional Modeling）

维度模型是数据仓库畛域另一位巨匠 Ralph Kimall 所提倡，他的《数据仓库工具箱》是数据仓库工程畛域最风行的数仓建模经典。维度建模以剖析决策的需要登程构建模型，构建的数据模型为剖析需要服务，因而它重点解决用户如何更疾速实现剖析需要，同时还有较好的大规模简单查问的响应性能。

典型的代表是咱们比拟熟知的星形模型（Star-schema），以及在一些非凡场景下实用的雪花模型（Snow-schema）。

维度建模中比拟重要的概念就是 事实表（Fact table）和维度表（Dimension table）。其最简略的形容就是，依照事实表、维度表来构建数据仓库、数据集市。

目前在互联网公司最罕用的建模办法就是维度建模，稍后将重点解说

3. 实体建模法（Entity Modeling）

实体建模法并不是数据仓库建模中常见的一个办法，它来源于哲学的一个流派。从哲学的意义上说，主观世界应该是能够细分的，主观世界应该能够分成由一个个实体，以及实体与实体之间的关系组成。那么咱们在数据仓库的建模过程中齐全能够引入这个形象的办法，将整个业务也能够划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的阐明就是咱们数据建模须要做的工作。

尽管实体法粗看起来如同有一些形象，其实了解起来很容易。即咱们能够将任何一个业务过程划分成 3 个局部，实体，事件，阐明，如下图所示：

上图表述的是一个形象的含意，如果咱们形容一个简略的事实：“小明开车去学校上学”。以这个业务事实为例，咱们能够把“小明”，“学校”看成是一个实体，“上学”形容的是一个业务过程，咱们在这里能够形象为一个具体“事件”，而“开车去”则能够看成是事件“上学”的一个阐明。

维度建模

维度建模是专门利用于剖析型数据库、数据仓库、数据集市建模的办法。数据集市能够了解为是一种 ” 小型数据仓库 ”。

1. 维度建模中表的类型

1. 事实表

产生在事实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。

事实表示意对剖析主题的度量。比方一次购买行为咱们就能够了解为是一个事实。

图中的订单表就是一个事实表，你能够了解他就是在事实中产生的一次操作型事件，咱们每实现一个订单，就会在订单中减少一条记录。
事实表的特色：表里没有寄存理论的内容，他是一堆主键的汇合，这些 ID 别离能对应到维度表中的一条记录。事实表蕴含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数会一直减少，表数据规模迅速增长。

明细表（宽表）：

事实表的数据中，有些属性独特组成了一个字段（糅合在一起），比方年月日时分秒形成了工夫, 当须要依据某一属性进行分组统计的时候，须要截取拼接之类的操作，效率极低。
如：

为了剖析不便，能够事实表中的一个字段切割提取多个属性进去形成新的字段，因为字段变多了，所以称为宽表，原来的成为窄表。

将上述的 local_time 字段扩大为如下 6 个字段：

又因为宽表的信息更加清晰明细，所以也能够称之为明细表。

2．维度表

每个维度表都蕴含繁多的主键列。维度表的主键能够作为与之关联的任何事实表的外键，当然，维度表行的形容环境应与事实表行齐全对应。维度表通常比拟宽，是扁平型非标准表，蕴含大量的低粒度的文本属性。

维度示意你要对数据进行剖析时所用的一个量，比方你要剖析产品销售状况，你能够抉择按类别来进行剖析，或按区域来剖析。每个类别就形成一个维度。上图中的用户表、商家表、时间表这些都属于维度表，这些表都有一个惟一的主键，而后在表中寄存了具体的数据信息。

总的说来，在数据仓库中不须要严格遵守规范化设计准则。因为数据仓库的主导性能就是面向剖析，以查问为主，不波及数据更新操作。事实表的设计是以可能正确记录历史信息为准则，维度表的设计是以可能以适合的角度来聚合主题内容为准则。

2. 维度建模三种模式

1. 星型模式

星形模式 (Star Schema) 是最罕用的维度建模形式。星型模式是以事实表为核心，所有的维度表间接连贯在事实表上，像星星一样 。
星形模式的维度建模由一个事实表和一组维表成，且具备以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表主键为单列，且该主键搁置在事实表中，作为两边连贯的外键；
c. 以事实表为外围，维表围绕外围呈星形散布；

2. 雪花模式

雪花模式 (Snowflake Schema) 是对星形模式的扩大。雪花模式的维度表能够领有其余维度表的，尽管这种模型相比星型更标准一些，然而因为这种模型不太容易了解，保护老本比拟高，而且性能方面须要关联多层维表，性能也比星型模型要低。所以个别不是很罕用

3．星座模式

星座模式是星型模式延长而来，星型模式是基于一张事实表的，而 星座模式是基于多张事实表的，而且共享维度信息 。
后面介绍的两种维度建模办法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在 业务倒退前期，绝大部分维度建模都采纳的是星座模式。

3. 维度建模过程

咱们晓得维度建模的表类型有事实表，维度表；模式有星形模型，雪花模型，星座模型这些概念了，然而理论业务中，给了咱们一堆数据，咱们怎么拿这些数据进行数仓建设呢，数仓工具箱作者依据本身 60 多年的理论业务教训，给咱们总结了如下四步，请务必记住！

数仓工具箱中的维度建模四步走：

请 牢记 以上四步，不论什么业务，就依照这个步骤来，程序不要搞乱，因为这四步是环环相扣，步步相连。上面具体拆解下每个步骤怎么做

1、抉择业务过程
维度建模是紧贴业务的，所以必须以业务为根基进行建模，那么抉择业务过程，顾名思义就是在整个业务流程中选取咱们须要建模的业务，依据经营提供的需要及日后的易扩展性等进行抉择业务。比方商城，整个商城流程分为商家端，用户端，平台端，经营需要是总订单量，订单人数，及用户的购买状况等，咱们抉择业务过程就抉择用户端的数据，商家及平台端暂不思考。业务抉择十分重要，因为前面所有的步骤都是基于此业务数据开展的。

2、申明粒度
先举个例子：对于用户来说，一个用户有一个身份证号，一个户籍地址，多个手机号，多张银行卡，那么与用户粒度雷同的粒度属性有身份证粒度，户籍地址粒度，比用户粒度更细的粒度有手机号粒度，银行卡粒度，存在一对一的关系就是雷同粒度。为什么要提雷同粒度呢，因为维度建模中要求咱们，在 同一事实表 中，必须具备 雷同的粒度，同一事实表中不要混用多种不同的粒度，不同的粒度数据建设不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度可能接受无奈预期的用户查问。然而上卷汇总粒度对查问性能的晋升很重要的，所以对于有明确需要的数据，咱们建设针对需要的上卷汇总粒度，对需要不明朗的数据咱们建设原子粒度。

3、确认维度
维度表是作为业务剖析的入口和描述性标识，所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，如果该列是对具体值的形容，是一个文本或常量，某一束缚和行标识的参与者，此时该属性往往是维度属性，数仓工具箱中通知咱们 牢牢把握事实表的粒度，就能将所有可能存在的维度辨别开 ，并且要 确保维度表中不能呈现反复数据，应使维度主键惟一

4、确认事实
事实表是用来度量的，基本上都以数量值示意，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的外围准则之一 是同一事实表中的所有度量必须具备雷同的粒度 。这样能确保不会呈现反复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住 最实用的事实就是数值类型和可加类事实。所以能够通过剖析该列是否是一种蕴含多个值并作为计算的参与者的度量，这种状况下该列往往是事实。

理论业务中数仓分层

数仓分层要联合公司业务进行，并且须要清晰明确各层职责，要保证数据层的稳固又要屏蔽对上游影响，个别采纳如下分层构造：

数据层具体实现

应用四张图阐明每层的具体实现

• 数据源层 ODS

数据源层次要将各个业务数据导入到大数据平台，作为业务数据的快照存储。

• 数据明细层 DW

事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的外围准则之一是 同一事实表中的所有度量必须具备雷同的粒度。这样能确保不会呈现反复计算度量的问题。

维度表个别都是繁多主键，多数是联结主键，留神维度表不要呈现反复数据，否则和事实表关联会呈现 数据发散 问题。

有时候往往不能确定该列数据是事实属性还是维度属性。记住 最实用的事实就是数值类型和可加类事实。所以能够通过剖析该列是否是一种蕴含多个值并作为计算的参与者的度量，这种状况下该列往往是事实；如果该列是对具体值的形容，是一个文本或常量，某一束缚和行标识的参与者，此时该属性往往是维度属性。然而还是要联合业务进行最终判断是维度还是事实。

• 数据轻度汇总层 DM

此层命名为轻汇总层，就代表这一层曾经开始对数据进行汇总，然而不是齐全汇总，只是对雷同粒度的数据进行关联汇总，不同粒度然而有关系的数据也可进行汇总，此时须要将粒度通过聚合等操作进行对立。

• 数据应用层 APP

数据应用层的表就是提供给用户应用的，数仓建设到此就靠近序幕了，接下来就依据不同的需要进行不同的取数，如间接进行报表展现，或提供给数据分析的共事所需的数据，或其余的业务撑持。

最初

技术是为业务服务的，业务是为公司发明价值的，来到业务的技术是无意义的。所以数仓的建设与业务是非亲非故的，公司的业务不同，数仓的建设也是不同的，只有适宜的才是最好的。

更多大数据精品文章，可关注公众号：五分钟学大数据

举荐浏览：

联合公司业务剖析离线数仓建设

数仓建设中最罕用模型 –Kimball 维度建模详解