内容简介:本篇先不讨论Data Vault其本身,因为不见得所有人都接受这个。但是里边有一些很不错的东西跟主流的数据仓库方法是有共同点的,所以这里主要讨论这些共同的方法,在笔者看来,无论是Kimball还是DV,这些方法都是很有用的。这个系列为作者本人哥本哈士奇的个人理解和总结,可能会有理解上的偏差,也欢迎大家一起来讨论。常用的哈希计算,HASH KEY, HASH FULL, HASH DIF,这里会有简单的介绍。关于如何做哈希计算,可以参考这个链接:
写在前面
本篇先不讨论Data Vault其本身,因为不见得所有人都接受这个。但是里边有一些很不错的东西跟主流的数据仓库方法是有共同点的,所以这里主要讨论这些共同的方法,在笔者看来,无论是Kimball还是DV,这些方法都是很有用的。这个系列为作者本人哥本哈士奇的个人理解和总结,可能会有理解上的偏差,也欢迎大家一起来讨论。
哈希计算
常用的哈希计算,HASH KEY, HASH FULL, HASH DIF,这里会有简单的介绍。
关于如何做哈希计算,可以参考这个链接:
https://www.hansmichiels.com/2016/04/09/hash-diff-calculation-with-sql-server-datavault-series/
HASH KEY
哈希键,通常是根据业务键来生成的,比如车辆的唯一识别号,如果已知一个系统的业务键跟另外一个系统的业务键可能有重合,那么可以考虑把RECORD SOURCE(后面会有介绍)也加进来参与计算。
在传统的数据仓库方法论里,出于性能角度的考虑,会在维度加载的时候去维护一个维度键和代理键的映射表,生成一个数值作为代理键,然后在维度表里只保留这个数值。维度加载完毕之后,加载事实表的时候,遇到了这个维度键,先会去映射表里查对应的代理键,然后在维度表里也只会保留这个代理键。这样可以确保事实表和维度表做JOIN时的性能。
同样在Data Vault的最初1.0版本中,也是先建议先加载HUB表,然后有对应的映射表,最后保留代理键。
这种方法确保了查询时的性能,但是有一个不好的地方就是维度表和事实表,或者HUB表对LINK和SAT表的加载顺序就有了要求。所以在Data Vault版本2.0里,没有再沿用这种方法,而是采用HASH KEY的方式,这样HUB,LINK和SAT三类表就可以同时加载。
是的,你会对这样做同样有性能上的疑虑,因为生成的HASH KEY从数据表的底层组织上不是最优的,相比于用数值类型的代理键,由于数值类型是连续的,所以底层的数据保存也是连续的,HASH KEY的生成很明显不是连续的,所以在数据的保存上不如数值类型的代理键效率好,会有页分裂导致的性能问题。
这个问题Dan有一个讨论在此:
http://roelantvos.com/blog/using-a-natural-business-key-the-end-of-hash-keys/
从我个人来理解,如果说其好的一面,虽然这样会降低ETL加载的性能,但是这个方法使并行加载变得可行,而且避免了ETL过程中的key look up,所以总体来说对ETL的性能收益是正向的还是负面的,需要具体去看。
另外还有一种情况可以不使用哈希键,比如公民身份证号,这个是绝对不会重复的,还有比如车辆识别编码等。
建议采用度:四星(五星满星)
HASH DIF
这是一个很有用的列。其做计算的时候会根据除了业务键列之外的所有列,生成一个唯一串。其好处就是在于,当源端系统不能自己告诉你数据是否变化了的时候,通过这个方法就可以很容易的判断。
比如一个表有20个列,为了判断新来的数据是否发生了变化,你是会去一列一列的对比呢,还是将这些列先计算成一个哈希值,然后只对这个哈希列去进行比对?很明显后者更高效。
Dan提到过一点,对于有些数据平台比如Teredata,其本身是自带这个列的,所以不需要去自己生成这个列。所以我觉得Dan是从此借鉴过来的吧。
建议采用度:五星
RECORD SOURCE
记录这个数据是从哪个数据来的。
在需要对大量的系统做整合的时候,这个列就很有用,比如在快消领域,标识一个产品的编码到底是从产品系统中来的,还是从价格管理系统中来。
这里我想强调的一点是,很多人都误以为这个字段是记录数据怎么来的,实际上不是,这个只记录数据从哪里来,通常都是源系统的名称,而不是你期望的A+B这种信息。
它的作用也更在于如前面提到,当生成HASH KEY的时候,如果已知业务键在不同的系统间可能有重复,为了能将他们整合到一起,需要用到RECCORD SOURCE来参与计算。
建议采用度:五星
LOAD DATE
数据加载时间,这个是指数据在第一次加载到数据仓库的时间,而这个范围要从STAGE层算起。
提及这个字段不得不说另外一个字段,LOAD END DATE,就是数据在哪次加载时消失或者被更改了。
按照SCD2的规则,如果是删除的数据,会先把历史记录的LOAD END DATE更新,这样这条记录的时间线在数据仓库中中止。如果是更新的数据,首先还是会去更新历史数据的LOAD END DATE,然后会再新加一条更新后的记录。
这样根据这个记录的生效开始时间和结束时间,就可以在时间线上看到一条数据的变更历史线。
在很多我看到的Data Vault社区讨论中,尤其是对于PSA的设计,都倾向于只插入,不更新历史记录的方法。也就是说,没有LOAD END DATE。其中一个理由就是对于记录的物理更新,在大量ETL数据操作的时候对性能影响会很大。
这样做不会耽误对历史数据的变更追溯,因为根据LOAD DATE,同样能拉出一条时间线。只是需要配合CHANGE INDICATOR列,不然删除的数据只靠LOAD DATE是无法辨识的。
建议采用度:五星
DATE EXPORT DATE
数据导出或者生成的时间。通常是针对无法直接连接到源数据库的情况,比如源系统需要把数据导出来,或者通过中间的ESB或者webservice之类的接口。这个主要是为了数据审计的目的,有时候对于数据问题的排查也很重要。
这个信息需要源系统端带过来,不过确实很难指望所有的系统都能带过来这个信息,所有可以考虑置空。
建议采用度:三星
CHANGE INDICATOR
数据变更的指示器。
很多源系统很难提供这个列,而且即使源系统提供了也不见得跟数据仓库的加载周期一致,所以会在数据仓库比对得出,这个时候LOAD_DTS和HASH KEY以及HASH DIFF就发挥了作用。
通常用I代表数据是第一次插入的,U代表数据这次加载是一个更新操作,D代表删除操作。
建议采用度:五星
以上所述就是小编给大家介绍的《利用Data Vault对数据仓库进行建模(二)》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 数据仓库的几种建模方法
- 卡通ufo模型建模,C4D建模教程
- 数据建模NoSQL数据库的概念和对象建模符号
- 小商店建模教程,C4D零基础建模教程
- 面向NLP场景应用的智能辅助建模(二)--本体树建模
- 面向NLP场景应用的智能辅助建模(三)要素树和概念树建模
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
XML、JSON 在线转换
在线XML、JSON转换工具
Markdown 在线编辑器
Markdown 在线编辑器