利用Data Vault对数据仓库进行建模（二）

写在前面

本篇先不讨论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表明删除操做。

建议采用度：五星