干货 | 万字详解整个数据仓库设计体系

数据仓库的基本概念

数据仓库概念:

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

数据仓库自己并不“生产”任何数据，同时自身也不须要“消费”任何的数据，数据来源于外部，而且开放给外部应用，这也是为何叫“仓库”，而不叫“工厂”的缘由。

基本特征:

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

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

1. 面向主题:

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

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
2021-03-18 06:31:42

为了分析方便，能够事实表中的一个字段切割提取多个属性出来构成新的字段，由于字段变多了，因此称为宽表，原来的成为窄表。

将上述的local_time字段扩展为以下6个字段：

year	month	day	hour	m	s
2021	03	18	06	31	42

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

2．维度表

每一个维度表都包含单一的主键列。维度表的主键能够做为与之关联的任何事实表的外键，固然，维度表行的描述环境应与事实表行彻底对应。维度表一般比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。

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

总的说来，在数据仓库中不须要严格遵照规范化设计原则。由于数据仓库的主导功能就是面向分析，以查询为主，不涉及数据更新操做。事实表的设计是以可以正确记录历史信息为准则，维度表的设计是以可以以合适的角度来聚合主题内容为准则。

2. 维度建模三种模式

1. 星型模式

星形模式(Star Schema)是最经常使用的维度建模方式。星型模式是以事实表为中心，全部的维度表直接链接在事实表上，像星星同样。
星形模式的维度建模由一个事实表和一组维表成，且具备如下特色：
a. 维表只和事实表关联，维表之间没有关联；
b. 每一个维表主键为单列，且该主键放置在事实表中，做为两边链接的外键；
c. 以事实表为核心，维表围绕核心呈星形分布；

2. 雪花模式

雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表能够拥有其余维度表的，虽然这种模型相比星型更规范一些，可是因为这种模型不太容易理解，维护成本比较高，并且性能方面须要关联多层维表，性能也比星型模型要低。因此通常不是很经常使用

3．星座模式

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

3. 维度建模过程

咱们知道维度建模的表类型有事实表，维度表；模式有星形模型，雪花模型，星座模型这些概念了，可是实际业务中，给了咱们一堆数据，咱们怎么拿这些数据进行数仓建设呢，数仓工具箱做者根据自身60多年的实际业务经验，给咱们总结了以下四步，请务必记住！

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

请牢记以上四步，无论什么业务，就按照这个步骤来，顺序不要搞乱，由于这四步是环环相扣，步步相连。下面详细拆解下每一个步骤怎么作

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

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

三、确认维度
维度表是做为业务分析的入口和描述性标识，因此也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢，若是该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性每每是维度属性，数仓工具箱中告诉咱们紧紧掌握事实表的粒度，就能将全部可能存在的维度区分开，而且要确保维度表中不能出现重复数据，应使维度主键惟一

四、确认事实
事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的全部度量必须具备相同的粒度。这样能确保不会出现重复计算度量的问题。有时候每每不能肯定该列数据是事实属性仍是维度属性。记住最实用的事实就是数值类型和可加类事实。因此能够经过分析该列是不是一种包含多个值并做为计算的参与者的度量，这种状况下该列每每是事实。

实际业务中数仓分层

数仓分层要结合公司业务进行，而且须要清晰明确各层职责，要保证数据层的稳定又要屏蔽对下游影响，通常采用以下分层结构：

数据层具体实现

使用四张图说明每层的具体实现

• 数据源层ODS

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

• 数据明细层DW

事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的全部度量必须具备相同的粒度。这样能确保不会出现重复计算度量的问题。

维度表通常都是单一主键，少数是联合主键，注意维度表不要出现重复数据，不然和事实表关联会出现数据发散问题。

有时候每每不能肯定该列数据是事实属性仍是维度属性。记住最实用的事实就是数值类型和可加类事实。因此能够经过分析该列是不是一种包含多个值并做为计算的参与者的度量，这种状况下该列每每是事实；若是该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性每每是维度属性。可是仍是要结合业务进行最终判断是维度仍是事实。

• 数据轻度汇总层DM

此层命名为轻汇总层，就表明这一层已经开始对数据进行汇总，可是不是彻底汇总，只是对相同粒度的数据进行关联汇总，不一样粒度可是有关系的数据也可进行汇总，此时须要将粒度经过聚合等操做进行统一。

• 数据应用层APP

数据应用层的表就是提供给用户使用的，数仓建设到此就接近尾声了，接下来就根据不一样的需求进行不一样的取数，如直接进行报表展现，或提供给数据分析的同事所需的数据，或其余的业务支撑。

最后

技术是为业务服务的，业务是为公司创造价值的，离开业务的技术是无心义的。因此数仓的建设与业务是息息相关的，公司的业务不一样，数仓的建设也是不一样的，只有适合的才是最好的。

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

---

推荐阅读：

结合公司业务分析离线数仓建设

数仓建设中最经常使用模型--Kimball维度建模详解