数据仓库维度建模概念解析

Bill Inmon：数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。

Ralph Kimball：数据仓库是一个将源系统数据抽取、清洗、规格化、提交到维度数据存储的系统，为决策的制定提供查询和分析功能的支持与实现。

Inmon的表述侧重于数据仓库的性质和特点，Kimball的表述侧重于数据仓库建设的过程，综合而言，数据仓库是从源系统通过一系列操作汇集的、为管理决策提供支持的数据集合，具有面向主题、集成、随时间变化、信息相对稳定的特点。

如其定义所言，数据仓库的目的是为管理决策提供支持，因此数据仓库的建设需要围绕这个目的进行。

那么如何为管理决策提供支持呢？假设是一家销售公司，那最基本的支持就是提供销售业绩数据。如果没有数据仓库，那么当管理者需要查询这些数据并以此制定相应决策时，就需要从生产库中直接拉取，那么显然存在两个问题：

1、影响生产业务

2、数据不可复用

因此需要有一个仓库存储数据实现联机分析处理（OLAP，Online Analytical Processing）。

既然是一个仓库，那么里面无论是货物还是数据都不能杂乱无章地堆放，而如何有效组织数据就成了研究数据仓库的重点，不同的组织方式形成了关于数据仓库的不同建模理论。

1、ER模型（Entity-Relationship Modeling）

ER模型常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合， 站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。缺陷：需要全面梳理企业所有的业务和数据流，周期长，人员要求高。

ER模型是站在企业的角度从上往下按主题进行相似性组合和合并，并进行一致性处理，最经典的实践就是Teradata公司基于金融业务发布的FS-LDM（Finacial Services Logical Data Model），它将金融业务划分为10大主题，企业可基于这个模型快速落地自己的数据仓库。

2、维度模型（Dimensional Modeling）

维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。优点：不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo，而且相对来说便于理解、提高查询性能、对称并易扩展。

维度模型更侧重于完成具体的分析决策需求，是一种从下往上的构建思路。同时，它关注大规模复杂查询的响应性能，星型模型是其具体形式。

以事实表为中心，用代理键把维度表关联起来

除了以上两种外，还有Dan Linstedt提出的Data Valut模型和对其做进一步规范化处理的Anchor模型，但就目前实际使用情况而言，普遍采用的都是Kimball的维度模型及其变型，因此下面主要介绍维度模型框架下的相关概念。

开展维度建模首先需要理解两个最重要的概念：维度和事实。

维度

维度建模的语境下，维度指的是环境，如你所处的城市、小区、公司、部门，商品所归属的一级大类、二级大类等。更通俗地理解是，维度指的是where和by后面跟着的字段，用来查询约束、分类汇总和排序。

事实

维度建模中的事实比维度更难理解，其实这里的事实指的是度量，如商品数量、成交金额、利润率等。度量业务过程的事实，一般为整型或浮点型的十进制数值，可分为可加、半可加和不可加三种类型。可加的事实指能够以任意维度直接汇总；半可加事实只能以特定维度汇总，如房屋面积可以按小区汇总，但不能按时间汇总，因为今天的房屋面积加昨天的房屋面积是没有意义的；不可加事实不具有可加性，如比率型事实，在任何维度下利润率加利润率都不具有实际含义。

维度表

维度表又称维表，维表存储的一般是对事实描述的信息。每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等。

维度表的简单示例

缓慢变化维

缓慢变化维指维度并不是静态的，而是会随着时间的推移发生缓慢变化。通用的处理方法是，在不考虑存储成本的情况下可通过每天保留一份全量的快照数据来处理变化的维度，当有需要的时候取最近的维度表进行关联。除此之外，还有全量重写、增加行、增加列、开发拉链表等方法来处理这个问题。

事实表

事实表主要围绕业务过程设计，表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键。通常具有两个和两个以上的外键，外键之间表示维表之间多对多的关系。

事实表的简单示例

就应用场景而言，事实表主要包括如下三种类型：

1、事务事实表

用于描述业务过程，按业务过程的单一性或多业务过程可进一步分为单事务事实表和多事务事实表。其中单事务事实表分别记录每个业务过程，如下单业务记入下单事实表，支付业务记入支付事实表。多事务事实表在同一个表中包含了不同业务过程，如下单、支付、签收等业务过程记录在一张表中，通过新增字段来判断属于哪一个业务过程。

2、周期快照事实表

在一个确定的时间间隔内对业务状态进行度量，如用户每月使用信用卡的消费情况。

3、累计快照事实表

用于查看不同事件之间的时间间隔，例如分析用户从购买到支付的市场、从下单到订单完结的时长等，一般适用于有明确时间间隔的业务过程。

雪花模型

雪花模型是用以组织事实表和维度的模型之一。如上图，雪花模型的维度表会分得较为细碎，往往一张维度表下会包含好几个外键用以与下层的维度进行关联。

星型模型

星型模型是雪花模型的退化形式。如上图，星型模型的地域维度表收敛成一张，当需要地域维度时事实表只需与这一张地域维度表关联即可。

退化和冗余

雪花模型和星座模型的组织形式很重要的目的就是节省存储空间。如中国可以用CHN表示，当有需要的时候再与维度表关联上展示全称“中华人民共和国”，假设通过这个方法每条记录可节省11个字节的话，那么一百万条记录就可节省约1MB，这在二十年前硬盘容量较少的情况下还是需要考虑的。

但是严格按照星型模型或雪花模型组织事实表和维度度带来的问题就是查询和应用事实表时需要多层关联，影响分析效率，因此目前实际采用的做法普遍都是把一些通用和使用频繁的维度表信息退化进事实表里形成一定程度的冗余，这样做法的原因如下：

1、从过去20的技术发展来看，存储成本的下降幅度要大于cpu和内存的下降幅度，同时存储成本占企业开销的占比也在不断下降，因此节约存储空间不是目前数仓建设最主要考虑的因素之一。

2、时间成本变得越来越重要。如果严格区分事实表和维度表，当需要事实表和维度表关联时join的时间开销是不得不考虑的。当业务急需某数据时，明明是一个select就能解决的事情，却要join好几张表花上好几倍时间才能得到相同的结果，这其实是很划不来的，更遑论需要维护的表的数量也是冗余后的好几倍乃至几十倍。

3、目前所采用的Hadoop框架下，担心的不是存储空间的大小，而是需要考虑如何减少MR启动的次数和查询时所用的到job的数量，这些会严重影响查询和统计的效率。由于每次join都要增加一个job，而严格按照星型模型和雪花模型组织时是需要大量join的，这就与目前的技术路线相悖了。

数据域

指面向业务分析，将业务过程或维度进行抽象的集合。业务过程是一个个不可拆分的行为事件，维度指度量的环境。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中。常见的数据域划分：商品域、日志域、交易域、互动域等。

业务过程

指企业的业务活动事件，如下单、支付、退款都是业务过程，通俗地讲，业务过程就是企业活动中不可拆分的行为事件。

粒度

粒度指的就是每一行的含义，如日志表中的粒度就是用户每一次的操作记录，订单表中的粒度就是用户所下的订单。

以上便是目前数据仓库领域中最为重要的一些概念了，掌握这些概念有助于对数仓建设形成全面的认识。