维度建模误区（第一篇）

一、文章概述

刚转型到互联网公司的同学受到规范化建模的思想根深蒂固，往往会计较几个字段的存储资源，采用非常规范的建模方式。笔者一直在有意识的打破传统建模规则，我们需要重点关注模型的易用性和性能，而不是几个字段的存储资源。

二、具有规范化的雪花型模式

带有重复文本的扁平化非规范化维度表，通常会使来自操作型建模世界的同学感到不舒服。他们会认为把所有描述符都规范地放入到不同的维度表中，不但能节省空间，而且杜绝了冗长的描述符。此外，他们还认为维度表越规范越容易管理。例如，如果部门发生变化，只需要维护部门维度表，而不用维护包含部门信息的上万行产品维度表。

规范化的维度表被称为雪花模型。冗余属性从偏平非规范化维度表中移除，放置在不同的维度表中。

雪花模式是维度建模的合法分支，然而我们强烈抵制雪花模型的动机就是：易用性和性能。

• 众多的雪花模型构成了一个复杂的结果。数据分析师和数据开发同学不得不关联这么多表才能取到想要的数据。简单化是维度建模的目标之一。

• 多数数据执行优化器需要考虑雪花型的复杂度。在hive中，多关联一张表会增加一个job。大量的job会导致任务执行缓慢。

• 雪花模型的维度表节省的空间并不明显。目前采用的ORC存储结构是列式存储，能节省很多空间；其次是维度表的数据条数和事实表相比非常小，可以忽略不计。

• 规范化雪花模式维度表不利于多属性浏览。
  

  
  

三、支架表

一般情况下我们不推荐使用雪花模式，但在某些情况下还是可以使用的。如下，可以在某个基本维度表之外建立一个附加的支架维度。

在某些情况下，基本维度表上的指向支架维度的外键的存在导致基本维度爆炸性增长。通常的做法是将支架表中的外键放入事实表中，而不是放在基本维度表中，如下

注意：尽管可以使用支架表，但出于其潜在的影响考虑，维度模型设计尽量不要使用支架表。

四、包含大量维度的蜈蚣事实表

如果不是在事实表上面建立单一的产品外键，而是将产品层次上频繁分析的元素也当成外键，例如，品牌、分类、部门；同样将日期划分为连接不同周、月、季度、年维度表的键。这样原先紧凑的事实表变成了连接大量维度表的怪物，我们将这种事实表称为蜈蚣事实表，因为它们可能会有100条腿。

多数业务过程的事实表不能超过20个维度，如果超过25个维度，需要做维度合并。例如，层级级别，以及具有统计相关性的属性，都应该放在一个维度中。

作者：清和 来源：大数据漫路求索