数据仓库建模概述

数据仓库建模概述

1、数据仓库建模的意义

数据模型就是数据组织和存储方法，它强调从业务，数据存储和使用角度合理存储数据，只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。

2、维度模型

维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，维度通常对应业务过程发生时所处的环境

图为一个典型的维度模型，其中位于中心的SalesOrder为事实表，其中保存的是下单这个业务过程的所有记录。位于周围每张表都是维度表，包括Date（日期），Customer（顾客），Product（产品），Location（地区）等，这些维度表就组成了每个订单发生时所处的环境，即何人、何时、在何地下单了何种产品。从图中可以看出，模型相对清晰、简洁。

维度建模以数据分析为出发点，为数据分析服务，因此它关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。

事实表

特点

通常比较“细长”，即列少，行多，且行的增速快。

分类

事务事实表，周期快照事实表、累积快照事实表

事务型事实表

概述

事务事实表用来记录个业务过程，他保存的是各业务过程的原子操作事件，即最细粒度操作。粒度是指事实表中一行数据所表达的业务细节程度。

设计流程

选择业务过程→声明粒度→确认维度→确认事实

不足

事务型事实表可以保存所有业务过程中的最细粒度的操作事件，故理论上可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求，其逻辑可能会比较复杂，或者效率低下。例如：

1.存量型指标

例如商品库存，账户余额等。此处以电商中的虚拟货币为例，虚拟货币业务包含的业务过程主要包括获取货币和使用货币，两个业务过程各自对应一张事务型事实表，一张存储所有的获取货币的原子操作事件，另一张存储所有使用货币的原子操作事件。

假定有一个需求，要求统计截止当日的各用户虚拟货币余额。由于获取货币和使用货币均会影响到余额，故需要对两张事务型事实表进行聚合，且需要区分两者对余额的影响，另外需要对两张表的全量数据聚合才能得到统计结果。

可以看到，不论是从逻辑上还是效率上考虑，都不是一个很好地方案。

2.多事务关联统计

例如，现需要统计近30天，用户下单到支付的时间间隔平均值。统计思路应该是找到下单事务事实表和支付事务事实表，过滤出最近30天的记录，然后按照订单id对两张表进行关联，之后用支付时间减去下单时间，然后再求平均值。

逻辑上虽然并不复杂，但是效率较低，因为下单事务事实表和支付事务事实表均为大表，大表join大表的操作应尽量避免。

可以看到，上述两种场景下事务型事实表的表现并不理想，下面要介绍的另外两种类型的事实表就是为了弥补事务型事实表的不足的。

周期性快照事实表

概述

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型(例如商品库存，账户余额)或者状态型(空气温度，行驶速度)指标。

对于商品库存、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合了。

对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表。

设计流程

确定粒度→确定事实

累积性快照事实表

概述

累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单，支付，发货，确认收货业务过程。

累积型快照事实表通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程（里程碑）。

订单id	用户id	下单日期	支付日期	发货日期	确认收货日期	订单金额	支付金额
1001	1234	2020-06-14	2020-06-15	2020-06-16	2020-06-17	1000	1000

累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。

设计流程

选择业务过程→声明粒度→确认维度→确认事实

维度表

概述

维度表是维度建模的基础和灵魂。前文提到，事实表紧紧围绕业务过程进行设计，而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段，维度字段称为维度属性。

设计步骤

1、确定维度（表）

在设计事实表时，已经确定了与每个事实表相关的维度，理论上每个相关维度均需对应一张维度表。需要注意到，可能存在多个事实表与同一个维度都相关的情况，这种情况需保证维度的唯一性，即只创建一张维度表。另外，如果某些维度表的维度属性很少，例如只有一个名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为维度退化。

2、确定主维表和相关维表

此处的主维表和相关维表均指业务系统中与某维度相关的表。相关维表的粒度通常与主维表相同。

3、确定维度属性

确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择， 也可通过进一步加工得到。确定维度属性时，需要遵守以下要求：

1.尽可能生成丰富的维度属性

维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。

2.尽量不适用编码，而使用明确的文字说明，一般可以编码和文字共存。

3.尽量沉淀出通用的维度属性。

有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理，可将这些维度属性沉淀到维度表中。