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



请遵守《互联网环境法规》文明发言,欢迎讨论问题
扫码反馈

扫一扫,反馈当前页面

咨询反馈
扫码关注
返回顶部