数据仓库维度建模概述

1.数据仓库建模目标

    数据仓库建模的目标是通过建模的方法更好的组织、存储数据，以便在性能、成本、 效率和数据质量之间找到最佳平衡点。

    访问性能：能够快速查询所需的数据，减少数据 I/O;

    数据成本：减少不必要的数据冗余，实现计算结果数据复用，降低大数据系统中的数据 成本和计算成本;

    使用效率：改善用户应用体验，提高使用数据的效率。

    数据质量：整合所有数据源的数据，改善数据统计口径的不一致性，减少数据计算错误

    上述的四点之间是存在冲突的，为了提高访问性能，可能会提高数据冗余(减少 Join)， 这样会降低计算成本，但是会导致数据存储成本很高，并且由于数据的冗余，会提高数据统 计口径不一致的风险，我们的目的是通过合理的设计在性能、成本、效率和数据质量之间找 到平衡点。

 

2.维度模型基本概念

    维度建模的理论由 Ralph Kimball 提出，他提出将数据仓库中的表划分为事实表和维度表两种类型，专门用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种"小型数据仓库"。

2.1 维度表（用来保存该维的元数据，即维的描述信息，包括维的层次及成员类别等）：

    维度表示你要对数据进行分析时所用的一个量,比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析。这样的按..分析就构成一个维度。再比如"昨天下午我在星巴克花费200元喝了一杯卡布奇诺"。那么以消费为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天下午)，地点维度(星巴克), 商品维度(卡布奇诺)。通常来说维度表信息比较固定，且数据量小。

2.2 事实表（用来存储事实的度量(measure)及指向各个维的外键值）：

    表示对分析主题的度量。事实表包含了与各维度表相关联的外键，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。比如上面的消费例子，它的消费事实表结构示例如下：

    消费事实表：Prod_id(引用商品维度表), TimeKey(引用时间维度表), Place_id(引用地点维度表), Unit(销售量)。

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

 

3.维度建模三种模式

3.1 星型模式

    星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。

    星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：

    a. 维表只和事实表关联，维表之间没有关联；

    b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；

    c. 以事实表为核心，维表围绕核心呈星形分布；

 

3.2 雪花模式

    雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用。

 

3.3 星座模式

    星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。

    前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

 

4.维度建模实例 

4.1 背景

    某电商平台，经常需要对订单进行分析，以某宝的购物订单为例，以维度建模的方式设计该模型。

4.2 事实表与维度表的划分

    事实表为订单表、子订单表，维度包括商品维度、用户维度、商家维度、区域维度、时间维度。

4.3 事实表分析 

    订单中包含的度量:商品件数、总金额、总减免金额;

    描述性属性:下单时间、付款时间、订单状态等; 

    子订单包含度量:商品 ID、单价、减免金额; 

    描述性属性:加入购物车时间、下单时间、付款时间、状态;

4.4 维度表分析

    商品维度:商品 ID、商品名称、商品品类、单价、颜色、尺寸、生产商等;

    用户维度:用户 ID、姓名、性别、生日、职业、信用值、收货地址等; 

    时间维度:日期 ID、日期、周几、是否周末、是否假期等;

    区域维度:区域 ID，县/区、县/区 ID、市、市 ID、省、省 ID;

    订单表和子订单表是两张事实表，我们往往会避免事实表之间产生关系，因此会考虑让子订单表中有一定的数据冗余，比如订单表和订单明细表都各自记录着用户 ID，区域 ID，时间 ID 等，这样在查询子订单信息时，就不用通过关联订单表来获取上述数据了，但是子订单表中仍会保存订单 ID 字段。

 

5.建模方法总结

    ER 模型和维度模型是当前主流的建模方法。

5.1 ER 模型常用于 OLTP 数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性、一致性合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。

        ER 模型的特点如下:

        • 需要全面梳理企业所有的业务和数据流; 

        • 实施周期长;

        • 对建模人员要求高;

5.2 维度建模是面向分析场景而生，针对分析场景构建数仓模型;重点关注快速、灵活的 解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓 库构建和 OLAP 引擎低层数据模型。

        • 不需要完整的梳理企业业务流程和数据;

        • 实施周期根据主题边界而定，容易快速实现 demo ;

 

6.模型的选择

    在数据仓库建模时，会涉及到模式的选择，我们要根据不同模式的特点选择适合具体业务的模式:

    冗余:雪花模型符合业务逻辑设计，采用 3NF 设计，有效降低数据冗余;星型模型的维度表设计不符合 3NF(如果是雪花模型改造成了星型模型，那么肯定不符合 3NF，因为 一定发生了表的整合，即降维，一定有传递依赖，但是，并不是所有的星型模型都不符合 3NF，很多星型模型的表是符合 3NF 的)，反规范化，维度表之间不会直接相关，牺牲部分存储空间。(雪花模型的维度之间是有关联的)

    性能:雪花模型由于存在维度间的关联，采用 3NF 降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低;星型模型反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能较雪花模型高。( 星型表的数据冗余大，是用存储空间换取效率 )( BI 的一些工具对于星型模型的支持更规范化 )

    ETL:雪花模型符合业务 ER 模型设计原则，在 ETL 过程中相对简单，但是由于附属模型的限制，ETL 任务并行化较低;星型模型在设计维度表时反范式设计， 所以在 ETL 过程中整合业务数据到维度表有一定难度，但由于避免附属维度，可并行化处理。

    Hive 的分析通过 MapReduce 实现，每多一个 Join 就会多出一个 MapReduce 过程，对于 雪花模型，由于存在着很多维度表之间的关联，这就会导致一次分析对应多个 MapReduce 任务，而星型模型由于不存在维度表的关联，因此一个 MapReduce 就可以实现分析任务。 MapReduce 本身是一个支持高吞吐量的任务，它的每个任务都要申请资源、分配容器、节 点通信等待，需要 YARN 的调度，由于相互关联的维度表本身会很小，join 操作用时很少， YARN 调度的时长可能都大于实际运算的时长，因此我们要尽可能减少任务个数，对于 Hive 来说就是尽可能减少不必要的表的关联。还有一点，雪花模型中拆分出的维度表，每个表对 应至少一个文件，这就涉及到 I/O 方面的性能损耗。

    因此，我们要采用适当的数据冗余，避免不必要的表之间的关联。

    在实际项目中，不会刻意地去考虑雪花模型，而是刻意地去考虑星型模型，特别是大数据领域的建模，倾斜于使用数据冗余来提高查询效率，倾向于星型模型;雪花模型只会应用在一些我们要求模型的灵活性，要求保证模型本身稳定性的场景下，但是雪花模型并不是首选。