利用Data Vault对数据仓库进行建模(二)

栏目: IT技术 · 发布时间: 4年前

内容简介:本篇先不讨论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对数据仓库进行建模(二)》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

数据之巅

数据之巅

涂子沛 / 中信出版社 / 2014-5-1 / 65.00元

《数据之巅:大数据革命,历史、现实与未来》从美国建国之基讲起,通过阐述初数时代、内战时代、镀金时代、进步时代、抽样时代、大数据时代的特征,系统梳理了美国数据文化的形成,阐述了其数据治国之道,论述了中国数据文化的薄弱之处,展望了未来数据世界的远景。 “尊重事实,用数据说话”,“推崇知识和理性,用数据创新”,作者不仅意在传承黄仁宇“数目字”管理的薪火,还试图把数据这个科技符号在中国转变为文化符号......一起来看看 《数据之巅》 这本书的介绍吧!

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码