Data Vault Model笔记

数据模型的演变

3NF

3NF最一开始是应用于OLTP系统中,后来Inmon采用3NF来构建企业数据仓库。

优点

  1. 可以很方便的扩展
  2. 减少数据冗余
  3. 与源系统结构基本保持一致,易于理解,同于也方便进行数据加载
  4. 可以支持实时的数据加载

缺点

  1. 数据查询的成本比较高,需要关联多张表
  2. 父子关系的处理会比较复杂;而且当父表发生变化时,所有的子表都会进行相应的处理
  3. 构建企业数据仓库的时间会比较长
  4. 为了适用于数据仓库,保留历史数据,需要在主键中增加时间,增加了处理的复杂度

Star Schema

Star Schema,是一种反范式,由事实表与多个维度表组成。Kimball的维度建模就是基于它来构建。

优点

  1. 面向主题,对需求方更加易懂
  2. 可以很方便地做多维分析
  3. 聚集等复杂查询性能较好
  4. 相比3NF,构建起来更加迅速
  5. 可以高效地存储历史数据

缺点

  1. 无法实时加载数据,而且加载处理的成本会比较高
  2. 由于是反范式,数据有所冗余
  3. 不太灵活,无法及时响应业务规则的变更
  4. 事实表粒度的问题
    • Fact granularity
      事实表的统计粒度越小,其记录条数就越多
    • Fact table size
      每在事实表中增加一项维度,其记录数就要再乘上新维度的条数
    • Changing attributes
      如果维度的属性发生了变化,则需要记录维度的历史信息,否则则会导致历史的统计信息有误

Data Vault

Data Vault是一种混合的构建方式,它不是一种adaption,而且专门解决数据仓库领域问题的一种方案。它结合了3NF与Star Schema两种方式的优点,比如:
1. 结构灵活,易于扩展,可以自由地增删
2. 可以实时加载数据
3. 可以方便地追溯历史
4. 由于不同表之间的解耦,ETL的任务可以并发执行,效率提升
5. 很方便地转换为维度模型

但是也会存在一些缺点:
1. 同样会存在大量的join,影响性能
2. Link表一直是append,导致已经过期的关系无法清理。但是其实过期的关系,反映的也是历史上曾经发生过的关联,在回溯历史的时候,同样会用到。
3. 由于将关系、属性从实体中抽取了出来,属性还会继续做拆分,那么其对象的数量是要比3NF多很多的。
4. 从源系统的表,抽象到Hub、Link等,需要资深专业数据建模人员的参与建设。

Data Vault架构

Data Vault由Hub、Link、Satellite三部分组成。

Hub

Hub对应着业务中的一个实体,但是Hub表中一般只有业务主键,不包含其他属性字段。
除了业务主键,一般还会包含以下字段:

Surrogate Key

代理主键,是可选的,可以是一个自增序列

Load Date Time Stamp

记录了这条记录第一次加载到数据仓库中的时间

Record Source

为了方便追溯,还记录了该条记录的来源

总结

源系统的数据加载到Hub表中后,Hub表的记录就不会再变动了。因为它只包含了业务主键,属性的变动不会影响到Hub表,这样源系统新增的记录就可以实时地加载到Hub表中。

Link

Link对应着业务中实体之间的关系,或者业务系统中发生的事务。它会包含以下字段:

Surrogate Key

代理主键,可选。因为一般Link表的主键是由多个Hub Key组成的复合主键,为了性能等方面的考虑,可以考虑增加代理主键。

Hub Keys

Link所关联的Hub表的主键

Load Date Time Stamp

记录关系第一次创建的时间

Record Soure

方便追溯,记录来源

总结

Link表的记录同样是只允许append,且创建后就不会变动,同样支持实时加载。和3NF不同的是,不管是1:N,还是N:N的关系都会抽取出来做为Link。如果业务规则是必须要1:N,就需要额外的特殊处理了。

Satellite

Satellite存储的是Hub或Link的上下文,或者说是描述信息。这些信息会随时间发生变动,而这些变动都应该被有效地存储起来。Satellite包含如下字段:

Satellite Primary Key

Satellite表的主键由两部分组成,因为其上下文信息经常变动,而每次变动都要被记录下来,因为主键上还要额外带上时间戳。

Hub/Link Primary key

与Hub/Link表的主键保持一致

Load Date Time Stamp

记录这一条记录是何时加载到数据仓库中的

Satellite Optional Primary Key

如果Satellite表比较特殊,比如用户由多个地址,那么地址的顺序号可以作为主键的一部分。

Record Source

方便追溯,记录来源

总结

Satellite由于需要记历史,通常会采用SCD的拉链记历史方式。但是如果某个表的属性变化频率不太一致,都放在同一个Satellite表中,就会造成存储的浪费。所以,一般会根据变化频次,相关性等原则,将属性分组,放在不同的satellite表中。

Point In Time

如果一个Hub表有多个Satellite表,不同的Satellite的更新频率不同。为了数据一致性,也就是说如果要统计某一天的指标,那么所有的Satellite表都应该能回溯到指定的那一天。这样,就需要一个Point In Time,在每一次属性发生变更时,对所有的Satellite表进行“拍照”,记录当时每个表的Load Date,以确定Satellite表的主键。

但是,如果Satellite表采取拉链记历史的方式来追溯历史,那么其实这个PIT是不需要的。PIT有个好处,就是所有的关联都是等值关联,查询的性能会比较好。

参考文章

  1. Comparisons between Data Warehouse modelling techniques
  2. 深入对比数据仓库模式:Kimball vs Inmon
  3. Data Vault Overview

发表评论