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代表删除操作。

建议采用度：五星