第三部分数仓建模- OneData 体系之维度表设计（一）

概述

    上一篇主要阐述了 OneData 建模体系中的模型设计，而本篇主要阐述是怎么创建维度表。当了解到数仓每层的设计目的时，对于每层模型设计有了进一步的掌握；在此之前所提及到的维度模型设计概念比较模糊，而接下来则是深入阐述维度模型设计。例如：什么是缓慢维变化，以及规范化与反规范化的区别；后续内容将展开说明。

What（什么是维度表）

    维度表可以理解为是对数据抽象的一个实体，它是维度建模的基础和灵魂。维度表是围绕业务过程所处环境进行设计的，它主要包含一个主键和各种维度字段（维度属性）；其中主键分为业务主键与代理键，业务主键指的是类似于用户ID、订单ID；而代理键指的是业务主键可能会出现慢维变化（指的是订单的状态发生变化，形成多条记录），导致出现两条相同的业务主键；而这个时候就需要代理键来维护表的唯一键。

Why（为什么创建维度表）

    维度表的主要目的是可以从不同的角度对数据进行分析，以及查询约束、分类汇总与排序使数据易用性更好。例如：可以通过买卖家、商品和时间维度描述交易环境，或者可以查询男性用户购买商品的情况等等。

How（怎么创建维度表）

设计步骤

第一步：选择维度或者新建维度。在构建数仓时必须保证维度的唯一性，如果出现多个事实表关联同一个维度的情况，需要保证维度的唯一性，即重新创建一张维度表。

第二步：确认主维表与相关维表。主维表和相关维表均指业务系统中与某维度相关的表，主维表通常指的是粒度分的更细的表，如商品的详情表则比商品类别表粒度更细。主维表外的其他表则都是相关维表，相关维表与主维表有关，用于帮助确定主维表的部分属性。而维度表的粒度通常和主维表保持一致。

第三步：确认维度表属性。维度表属性可以由主维表和相关维表的字段产生以及字段拼接产生，属性的确定应该注意以下几点：

1. 尽可能使用丰富（多）的维度属性，丰富的维度属性为下游的数据统计、分析提高良好的基础；
2. 文字和编码共存，数据的存储以编码方式存更为合适，但是以纯编码形式我们又不懂其中的含义，因此需要文字和编码的共存；例如商品 ID 对应的商品是什么。
3. 沉淀通用的维度属性，某些指标需要维度表通过复杂计算才能得到，就可以考虑将其加入维度表中下沉；一方面可以提高下游使用的方便性，以及减少后续的重复计算；另一方面可以避免下游使用是各自逻辑不同而导致的口径不一致问题。

设计要点

规范化与反规范化

    规范化指的是按照范式设计数据库的过程，主要目的是为了减少数据冗余，增强数据的一致性；通常情况下一张表规范化之后，会将一张表的字段拆分成多张表；如果规范化设计维度表，该维度模型称之为雪花模型。

    反规范化指的是多张表的数据冗余到一张表中，主要目的是为了减少 Join 操作，提高查询速度。如果反规范化设计维度表，该维度模型称之为星型模型。

    数仓设计的主要目的是为了数据分析和统计，因此如何高效的实现统计与分析是设计模型的优劣评判。如果采用雪花模型设计，在统计与分析的过程中大量 Join 操作，会使得查询的效率大大降低；而采用星型模型设计，则易用性更好。所以基于易用性与效率上，维度表一般采用反规范化设计。

维度退化

    维度退化指的是某个维度对应的维度属性很少（或者没有），那么该表的维度属性直接合并到与之相关的事实表中。例如：订单编号ID、或者支付类型等等，就没有必要单独创建一张维度表来进行存储；而直接下沉在事实标准中更有利数据进行查询与过滤。但是对于缓慢变化维度的维度表，则不建议进行维度退化；否则会对原有的事实表造成冗余现象，例如一个订单ID会出现多条记录。

缓慢维度变化

    维度属性通常不是静态的，而是会随时间变化的；数仓一个重要的特点就是反应数据的历史变化，因此如何保存数据的历史状态也是维度设计的重要环节。解决这一问题有三种处理缓慢变化的方式，如下

• 第一种：重写维度值，不保留历史数据。
• 第二种：插入新的维度行，可以保留历史数据；但要进行数据 Join 是就会对应多条数据。
• 第三种：添加维度列，也可以保留历史数据；但对于慢维变化需要新增的维度列数量不确定。

因此一般情况下会选择第一种方式，而全量快照表和拉链表是处理缓慢维度变化的常用方法。

全量快照表：通俗的来说就是每天全量同步一份维度表数据，这种方式简单粗暴优缺点也特别明显。

• 优点：开发和维护成本低，方便理解和使用；
• 缺点：存储成本高，特别是数据变化比例不高时，存储性价比较低；

拉链表：它存在的意义就是为更高效的保存维度信息的历史数据。

• 优点：数据不会冗余，节省存储空间；
• 缺点：开发和维护成本高，计算资源相对消耗较多；

全量快照表与拉链表如何选择：具体使用什么方式处理缓慢维度变化主要看数据的场景，如下说明：

• 维表每日变化大：这种情况一般采用全量快照表的方式；
• 维表每日变化小：这种情况可以采用拉链表，但如果维表整体数据量不大的话还是建议使用全量快照，因为相比开发与维护的高成本，存储成本可以不优先考虑；

多值维度

    多值维度指的是如果事实表中一条记录在某个维度表中有多条记录与之对应。例如，下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，所会商品维度表中就可能有多条数据与之对应。多值维度不利于表的设计，因此通常采用以下两种方案解决：

• 降低事实表的粒度，例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项；
• 在事实表中采用多字段保存多个维度值，每个字段保存一个维度 id（这种方案只适用于多值维度个数固定的情况）；

建议尽量采用第一种方案解决多值维度问题，第二张维度的个数不太好确定。

多值属性

    多值属性指的是维表中的某个属性同时有多个值。例如：商品维度的平台属性和销售属性，每个商品均有多个属性值。通常有可以采用以下两种方案解决：

• 将多值属性放到一个字段，该字段内容为 keyl:valuel，key2:value2 的形式，例如：一个手机商品的平台属性值为“品牌:华为，系统:鸿蒙，CPU:麒麟990”。
• 将多值属性放到多个字段，每个字段对应一个属性；这种方案只适用于多值属性个数固定的情况。

什么样的场景才创建事务事实表或者周期快照表呢？

=》 第三部分数仓建模-OneData体系之事实表设计（二）

---

以上示例与内容仅是个人观点，如有误十分感谢提出；内容还在完善中！！！

参考链接：

尚硅谷数仓5.0

数仓笔记UP

《大数据之路：阿里巴巴大数据实践》