《大数据之路》读书笔记：维度设计

大家好，我是小轩

维度设计基础

一、维度的基本概念

维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实”，将环境描述称为“维度”，维度是用于分析事实所需要的多样环境。

维度使用主键标识其唯一性，主键也是确保与之相连的任何事实表之间存在引用完整性的基础。主键有代理键和自然键，它们都是用来表示某维度的具体值。但代理键是不具有业务含义的键，一般用于处理缓慢变化维；自然键是具有业务含义的键。比如商品，在ETL过程中会生成商品维表唯一标识的代理键，但没有业务含义。商品本身的自然键是商品ID。

二、维度的基本设计方法

维度的设计就是确定维度属性的过程，书中用淘宝的商品维度为例对维度设计进行说明：

1、选择维度或新建维度。

2、确定主维表。这里的主维表一般是ODS表，直接与业务系统同步。

3、确定相关维表，确定不同业务系统或者同一业务系统中的哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。

4、确定维度属性，包含两个阶段分别是从主维表中选择维度属性或生成新的维度属性、从相关维表中选择维度属性或生成新的维度属性。

确定维度属性要注意的点：

• 尽可能生成丰富的维度属性。
• 尽可能多地给出包含一些富有意义的文字性的描述。
• 区分数值型属性和事实。
• 尽量沉淀出通用的维度属性。

三、维度的层次结构

维度层次指的是某个维度表中属性之间存在的从属关系问题。比如商品的类目可能是有层次的（一级类目、二级类目、三级类目等，尤其对于宝洁、联合利华等大的快消企业集团），同时类目、品牌和产品实际上也是有层次的。

那么维度建模如何处理这些层次结构呢？

1. 第一种是将所有维度层次结构全部扁平化、冗余存储到一个维度表中，比如商品的一至三级类目分别用三个字段来存储，品牌等的处理也是类似的；（星型模型）

2. 第二种是新建类目维度表，并在维度表中维护父子关系。（雪花模型）

四、规范化和反规范化

规范化：属性层次被实例化为一系列维度，而不是单一的维度。

优点：可以将重复属性移至其自身所属的表中，删除冗余数据。

缺点：从用户角度来看，做统计分析时每次查询都需要进行多表之间的关联，复杂度高，同时查询性能较差。从表之间的角度看，假设需要更新商品表和类目表，且由于商品和类目是一对多的关系，商品表可能每次需要更新几十次甚至上百万条记录。

反规范化：将维度的属性层次合并到单个维度中的操作

优点：从用户角度来看，在做统计分析时，方便、易用且性能好。

缺点：所有的数据都存放在一张表，会出现数据冗余。

如上所述，反规范化的维度仍包含与规 范化模型同样的信息和关系，从分析角度来看，没有丢失任何信息，但复杂性降低了。对于OLAP系统来说可以采用规范化除了可以节约一部分存储外，也没有其他效用。

维度设计高级主题

一、维度整合

维表整合的内容：

• 命名规范统一
• 字段类型统一
• 公共代码及代码值统一
• 业务含义相同的表统一

业务含义相同的表统一，有以下几种集成方式：

• 采用主从表的设计方式将两个表或多个表都有的字段放在主表，从属信息存放在各自的从表中。
• 直接合并，共有信息和个性信息都放在同一个表中。
• 不合并，因为源表的表结构及主键等差异很大，无法合并。

下面看看表级的整合方式：

• 垂直整合，即不同的来源表包含相同的数据集，只是存储的信息不同。
• 水平整合，即不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。

二、水平拆分

维度通常按类别或类型进行细分。在一系列的维表里，有共同的维度属性，也有各自独特的维度属性，针对这种情况，我们主要有两种解决方案：方案一是将维度的不同分类实例化为不同的维度，同时在主维度中保留公共属性；方案二是维护单一维度，包含所有可能的属性。

选择哪个方案，需要考虑以下上原则：

• 扩展性：当源系统、业务逻辑变化时，能通过较少的成本快速扩展模型，保持核心模型的相对稳定性。即高内聚、低耦合思想。
• 效能：通过牺牲一些存储成本，换取性能和逻辑的优化。
• 易用性：模型可理解性高、访问复杂度低。

三、垂直拆分

根据维度属性的热度不同、使用频率不同来垂直拆分维度字段。按可扩展性、效能和易用性，设计主从维度。主维表存放稳定、产出时间早、热度高的属性；从维表存放变化快、产出晚、热度低的属性。

四、历史归档

定期将历史数据归档至历史维表。

维度变化

一、缓慢变化维

数据仓库的重要特点之一反映历史变化，所以如何处理维度的变化是维度设计的重要工作之一。

第一种处理方式：重写维度值。不需要保留历史数据。

以商品所属类目变化情况为例，具体描述：

第二种处理方式：插入新的维度行。

第三种处理方式：添加维度列。

二、快照维表

数据仓库对来源表进行全量或增量数据抽取，不做任何变动。

三、极限存储

历史拉链存储就是处理维度模型中缓慢变化的一种方式，通过新增两个时间戳字段（start_dt和end_dt），将所有以天为粒度的变更数据记录下来。通常分区字段也是时间戳字段。这种存储方式存在下游数据使用方理解障碍，而且使用start_dt和end_dt做分区，随着时间的推移，分区数量会极度膨胀，而现行的数据库体系都有分区数量限制。

针对上述两个问题，阿里提出采用极限存储方式处理，分月做历史拉链表，及每月月初重现开始做历史拉链表。（极限存储有局限性，不太适合高变化率的数据，不太建议使用）

四、微型维度

微型维度的创建是通过将一部不稳定的属性从主维度中移除，并将它们放置到拥有自己代理键的新表中来实现。（不建议使用，ETL加工逻辑复杂）

特殊维度

一、递归层次

维度递归层次，按照层次是否固定分为均衡层次结构和非均衡层次结构。例如：地区，分别是乡镇/街道、区县、城市、省份、国家，这类有固定层次为均衡层次结构；公司之间的关系，每个公司可能存在一个母公司，但可能没有一级、二级等层级关系，对这种没有固定层次为非均衡层次结构。

在递归层次中进行上钻和下钻，会使用到递归。而在很多数据仓库系统和商业智能工具不支持递归SQL，且用户使用递归SQL的成本较高。所以，建议对层次结构进行处理：

1. 层次结构扁平化

通过建立维度固定数量级别的属性来实现，可以一定程度上解决上钻和下钻的问题。但可能存在以下上方面问题：

（1）针对上钻和下钻之前，必须知道所属的类目层次。

（2）所此层次为叶子层（即没有下层），则无法下钻和上钻。针对这个问题，可以此层次的上层或下层填本层科目，虚拟科目。（3）扁平化仅包含固定数量的级别，对均衡层次结构，可以通过预留级别的方式解决，但扩展性较差。

2. 层次桥接表

针对扁平化所存在的问题，可以使用桥接表的方式解决，即中间设置中间对照表，关联两者。该方法适合解决更宽泛的分析问题，灵活性好；但复杂性高，使用成本高。

二、行为维度

对于行为维度，有两种处理方式，一种是将其冗余至现有的维表中；另一种是加工成单独的行为维表。

选择哪种方式主要参考下两个原则：

• 避免维度过快增长。
• 避免耦合度过高。

三、多值维度

常见处理方式有三种：

• 降低事实表的粒度。
• 采用多字段。
• 采用较为通用的桥接表。

四、多值属性

• 保持维度主键不变，将多值属性放在维度的一个属性字段中。
• 保持维度主键不变，将多值属性放在维度的多个属性字段中。
• 维度主键发生变化，一个维度值存放多条记录。

五、杂项维度

将很多字段建立到一个维表中，在事实表中只需保存一个外键即可。

注意：多个字段的不同取值组成一条记录，生成代理键，存入维表中，并将该代理键保存到相应的事实表字段下。建议不要直接使用所有的组合生成完整的杂项维表，在抽取遇到新的组合时生成相应的记录即可。