数仓 | Kimball的维度建模过时了吗？-kimball维度建模

本文转载自微信公众号「大数据技术与数仓」，作者西贝。转载本文请联系大数据技术与数仓公众号。

从20世纪80年代中期以来，kimball一直是数据仓库和商业智能行业维度建模方法的思想开拓者。维度建模之初假设数据仓库仅限于单服务器数据库，随着大数据时代的到来，分布式计算和分式存储成为了新的趋势，所以Ralph Kimball所普及的维度数据建模方法和技术需要一些修订，这样才能更好地满足大数据建模的需求。需要注意的是，在数据仓库领域， Inmon和Kimball是两大主要阵营，但是Kimball的维度建模理论对于现代数仓建设的影响可谓是非常深远的，所以本文主要讨论维度建模的相关问题。

不要使用代理键

在KimBall的维度建模中，必须使用代理键作为每个维表的主键，用于处理缓慢变化维。

这个问题对于初学数仓维度建模的人而言，很容易陷入Kimball提出的代理键的漩涡之中，以至于把时间都浪费了。其实代理键在大数据仓库环境下显得很不合时宜，并且很难维护。在实际的建模中使用自然键是一个很好的选择，如果维度有一个复合主键，只需将它们与合理的分隔符连接在一起，即可根据多个自然键生成单个键。

总结下来不使用代理键主要有一下两个原因：

分布式计算系统，淡化了事务的概念，生成代理键的代价会很高
代理键会大大增加ETL的复杂性，对于ETL任务的开发和维护成本很高

避免使用 Type-2 SCD

缓慢变化维是维度建模理论的一个非常重要的概念，大多数情况下，Type-0 或 Type-1 SCD 可以解决问题。除非有特别关键的原因，否则我会避免使用 Type-2 SCD。尤其是在大数据环境下的数据建模，几乎很少使用Type-2 SCD。

关于SCD的解释如下：

SCD1：通过更新维度记录直接覆盖已存在的值，它不维护记录的历史。SCD1一般用于修改错误的数据。
SCD2：在源数据发生变化时，给维度记录建立一个新的“版本”记录，从而维护维度历史。SCD2不删除、修改已存在的数据。
SCD3：通常用作保持维度记录的几个版本。它通过给某个数据单元增加多个列来维护历史。例如，为了记录客户地址的变化，customer_dim维度表有一个 customer_address列和一个previous_customer_address列，分别记录当前和上一个版本的地址。SCD3可以有效维护有限的历史，而不像SCD2那样保存全部历史。SCD3 很少使用。它只适用于数据的存储空间不足并且用户接受有限维度历史的情况。

如果非得需要实现 Type-2 SCD(不建议使用)，也不要使用代理键。相反，将自然键与表示 SCD 中的有效日期和到期日期字段结合使用。这只是查询稍微复杂一点，但更灵活，更容易实现，并且避免了对代理键的需要。

维表快照

在关系型数据仓库时代，快照维度显得没有意义，但在大数据环境中却非常有意义。简单将就是使用分区表，每个分区内存储的是截止当前时间的全量维度信息。

通过快照的方式处理缓慢变化维，是在大数据环境的数据仓库实践中常用的方式。以离线数仓为例，计算周期一般是每天一次，基于此周期，处理缓慢变化维的方式就是每天保留一份全量的快照数据。以商品维度为例，就是每天保留一份全量的商品快照数据。在下游的使用过程中，可以获取每天的维度信息，使用起来非常方便。

优点

简单，开发和维护成本低
方便，很容易理解，下游使用数据时只需要限定所需要的日期即可

缺点

存储浪费
综合看来，由于存储成本远低于CPU、内存的成本，此方法是牺牲存储获取ETL效率优化和逻辑上的简单，显然是利大于弊的。

数据建模的非规范化

所谓的非规范化，即是将某些维度属性冗余至事实表。过去之所以不赞成这样做，部分原因是因为 RDBMS 将数据存储在表中的方式。随着 Parquet 和 ORC 等列式数据存储格式的出现;这不再是一个大问题。

在传统的维度建模的星型模型中，对于维度的处理是将其单独存放在专门的维表中，然后通过事实表的外键获取维度。这样做的目的是为了减少事实表的冗余，从而减少存储消耗。

但是在大数据背景下，考虑到提高下游任务的使用效率，降低获取数据的复杂性，减少关联表的数量，通常的做法是将常用的维度冗余至事实表中。

善于使用复杂的数据类型

通常，作为数据工程师，我们的工作是将非结构化数据集重新组织为结构化(或半结构化)数据集，但是在一些场景下，非结构化是一个很好的选择。

复杂的数据类型违反了最重要的范式(原子列)规则，其实你会发现，维度数据建模的许多传统理论都违反了其中的一些规则。由于复杂数据类型使用起来非常灵活，其在现代数据仓库中功能是非常强大的。

当某个实体的详细信息在不久的将来发生变化时，使用一个 JSON来保存这些字段是很有必要的，直到schema的细节可以固化。

对于一对多的情况，使用数组或许是一个很好的方案，例如，如果在商品维度中存储一些标签字段，我们就可以将这些字段存在在一个数组字段中，而不是将标签存储在一张标签表中。

值得注意的是，对于一些特殊的场景，要善于使用复杂类型，而不是滥用复杂数据类型。结构化依然是建模过程中需要考虑的重点。

总结

Ralph Kimball的维度建模理论对于当今数据仓库建模的影响可谓是非常深远的，我们现在主流的数仓建模都是基于维度建模的。随着大数据技术的不断发展，维度建模的一些方法需求随之做出一些调整，但是其核心思想是不变的。另外，作为数仓开发者，我们要遵循一个准则：数据仓库的设计是为了业务服务的，是为了发挥数据运营的优势而存在的，所以彰显数据价值，赋能业务增长才是我们需要考虑的最根本问题。