Data Vault玩转数据仓库（一）

简介

国内关于Data Vault的信息很少，所以决定写点什么，纯粹都是自己在这个行业10多年的摸爬滚打。不过为了效率，尽量做到简短，直接上干货。对于各个细节大家有不同的理解欢迎来讨论。

数据仓库建模的方法有哪些。

首先最经典的是数据仓库Inmon基于3NF的方法。这个方法知道概念的人很多，但是实际用的很少，也不建议你去了解更多，因为目前在国内的招聘网站上你会很少找到这个。

其次是Kimball的维度建模方法，这个基本上做过数据仓库的都用过，比如事实表和维度表，基于这种理论也可以构建数据立方体方便分析。其特点是简单快速，适合中小型数据仓库。招聘网站上九成以上关于数据仓库的招聘都会要求这个。

然后是Dan的Data Vault建模方法。这个国内知道的不多。不同于维度方法，它的基本表是LINK，HUB以及SAT表。这个方法论连Inmon都说好，只是圈子实在太小。这个方法论比较适合企业级数据仓库，以及大数据的场景。

为什么要Data Vault

关于DV的各种好处官方站点提了好多，但说得都很marketing。以下是我个人的理解：

- 适合企业级数据仓库。

- 适合大数据项目，是的，在大数据中你怎么去组织数据，直接扔那？还是用维度模型？是不是都不太合适？那你应该考虑Data Vault。

- 比较容易根据元数据系统去自动生成相应的代码。这个在下面我会介绍一些。

谁更爱DV？

这是一个很有意思的问题，同时你也可以看到这个话题在国内是多么冷门。

从我阅读到的文章观察到信息来看，首先是欧洲比较火热，其次是北美，然后是澳洲。

在欧洲，德国人似乎更爱这个话题，在海外网站偶尔能看到德国人写的文章以及在讨论相关的问题，所以，汽车领域会见到的比较多。开源的项目以及商业相关的项目，也大多数都是欧洲的公司。

在国内看到的讨论和文章真的是少之又少，目前我所观察到的是阿里有人在讨论，但是不确定是在哪个部门。

维度模型还是DV？

维度模型和DV的关系，我觉得他俩是不冲突的。在我自己参考别人的方法制定的规范中，核心层用的方法是DV，然后在集市层用到的方法就是维度模型和宽表。

如果你的前端有对应的OLAP Cube工具的话，那么维度模型确实是必要的。

在核心层，相比维度模型，DV就比较容易对各个系统的数据进行整合和关系的管理。

想知道关于Data Vault更多的信息？

首先你可以去都Dan的网站：

对英文多少有点要求，主要是他们的思路和文风有时候真的好飘逸。

其次是Roelant的网站：

里边的干货也很多，当然某些细节对大家的英语也是个挑战。他的博客里有好多细节的实现，其次他也有自己的开源项目可以作为不错的参考。

最后，也可以参考我正在翻译的DV规范：

这里面我按照英文-中文对照的方式，根据自己掌握的知识和理解去进行本地化的翻译。

进度很慢，但是如果你想要知道个大概的话那么看我中文翻译出来的部分基本就够了。

结合Data Vault我也自己编写了一个数据仓库的各方面标准：

Code name 69，我会不断加入更多项目的实施细节进去。

当然实际项目中会有很多实现的分支，比如对数据的变更处理，有SCD2等很多方法，在我的这个规范里就是insert only。

当然没有一个方法能适用所有场景，这个69规范也不见得就是最专业的，如果你的项目是start from zero的话，那么或许可以拿来做一个参考然后制作出自己的项目规范。