Data Vault 简介
Data Vault 2.0 不仅是建模技术，也提供了一整套数据仓库项目的方法论。它能提供一套非常可行的方案来满足数据仓库项目中对于历史轨迹和审核两个方面的需求。
多年来，商业智能(BI)项目一直并将继续在瀑布模型下运行。它是由每个阶段的长时间延伸的序列定义的，该序列需要一份详尽的前期需求列表、一个完整的数据模型设计，然后将所有硬业务规则和软业务规则编入ETL流程。可视化层是按顺序构建的，并从最初的开始日期算起，在几个月甚至几年之后提交给最终用户。
我们经常看到团队采用“缩小范围”的瀑布模式，目的是将大型BI计划分解成较小的项目。虽然有助于降低整体的复杂性，但是这种方法在应用于BI时仍然有很大的风险，因为有两个主要的问题:
- 业务需求的变化速度远快于BI研发的交付能力;
- 预算不愿意花在没有短期利益的长期项目.
以上两个原因就是为什么我们设计模式从瀑布转向可迭代敏捷模式，这种模式提供了一些方法来解决问题。但是在数据分析领域，敏捷本身并不能解决我们在更详细的数据仓库或BI项目级别上遇到的重大挑战。这些包括:
- 迭代数据建模
- 减少重构
- 设计ETL或ELT流程，使其能够快速响应业务逻辑的变化或新增数据
- 收集设计决策的输入数据相关的业务需求
为了应对这些问题，Data Vault 2.0应运而生，它定义了一种方法，该方法侧重于从敏捷实践中获得最大收益，并使用其他已被证明有效的规程和技术，看起来是迄今为止最迭代的BI方法
什么是Data Vault
Data Vault (DV)将敏捷、BEAM需求收集、CMMI、TQM、六西格玛和DV建模等方面结合在一起，以定义一种旨在提高BI项目速度和质量的方法。因为它既能提高适应性，又能提高准确性。
DV还包括关于DW项目评估和敏捷任务分级的敏捷方法，以确复杂性或跨DW所涉及的工作。在较低的层次上，它还提供了一种非常简洁和迭代的方法来处理常见的功能需求。这些包括全面的、可重复的、渐进的、基于敏捷的流程，以完成日常的任务。这些任务包括(但不限于)在ETL和建模阶段增加数据属性、切片、新增加数据源、扩大源、历史跟踪、弃用源和源结构更改。
简单地说，DV模型是一个存在于常规维度建模(OLAP、星型模式)和分段之间的层，它根据不断增长的业务需求提供伸缩性，并分解建模和ETL的复杂性。它由中心(业务实体)、链接(关系)和卫星(描述性属性)组成，它们在3NF和星型模式之间建模。该模型被放置在数据仓库的数据集成层(通常称为原始数据库)中，并与Kimball的模型有效地结合使用。
Data Vault 2.0 优点
下面概述了Data Vault 2.0方法的一些主要优点:
- 它假设了数据建模关系的最坏情况。业务对象之间的N:M关系，以消除在将1:M变为M:M时需要更新的情况。因此，当关系的程度发生变化时，几乎不需要再做额外工作。
- 它是为历史跟踪数据而设计的,所有的关系和属性，以及数据在一段时间内的来源都可以被追溯记录。
- 提出了一套设计原则和结构，在数仓中增加历史跟踪性能(坑和桥梁)。数据仓库模型足够灵活，可以在迭代建模过程中的任何时间点采用这些结构，并且不需要进行前瞻规划设计。
- 在逻辑上分隔包含原始数据和修改数据的空间。原始数据仓库是源系统可审计的数据的基础，并且业务仓库为需要访问数据集市下一级数据的高级用户提供了一个查询空间。
- 将软业务规则和硬业务规则分离到数据集成的不同部分。这加强了跨多个终端使用的数据的可重用性。例如，原始数据只在数据仓库中获得一次(较少重新集成到分段中)，可以多次提供给下游需求。
- 对于每个敏捷迭代，存储所有数据历史轨迹的数据仓库模型很容易扩展，而不必担心丢失历史数据。此外，历史轨迹是独立于维度模型存储的。
- Data Vault 2.0提倡业务键使用hash key实现，以减少lookups，从而增加加载并行度。这导致较少的顺序加载依赖性
- 原始数据仓库（ods）被设计为完全可审计的.
- 在数据仓库中作为一个整体，从Staging到星型架构和OLAP的处理变得更加平滑和迭代。
- 它提供了一种全面的方法，将来自异构数据源带有多个不同业务键的数据组合在一起(跨多个源系统在仓库内集成数据)。业务键并不总是1:1或格式相同。
- “及时”建模的心态与敏捷方法非常匹配.
缺点
虽然DV优点很多，但是其缺点也不少, 比如:
- DV 其实就是在数据集市或者星型结构层和临时存储层之间的一层。在ETL开发和建模方面，开发这个层会带来一些额外的开销。如果项目是小规模的，或者项目的生命周期很短，那么就不值得采用数据库模型
- 使用Data Vault背后的主要驱动因素之一是出于审计和历史轨迹的目的。如果这些都不重要，那么将另一层引入到建模中所需要的开销就会变得得不偿失。然而，从长期的需求来看，这可能是一项值得的前期投资。
- DV代表了对关系、业务键和属性的分解方法，因此与非规范化结构(如星型模式)相比，创建的表的数量更多。但是，考虑到Data Vault是对星型模式的补充，所以多也只是相对的。由于这个原因，需要许多 joins 来查看DV中的数据
- 缺少大规模实际应用案例.
- 这种建模方法，一般来说，对于那些使用Kimball和Inmon的模型的人来说是不太常规和方便的。
何时使用DV?
有几个关键变量才是判断的标准。比如，
l 我们认为DV建模是满足数据仓库项目需求的一种非常可行的方法，其中历史轨迹跟踪和审核是两个重要的因素。
l 此外，如果跨业务实体的关系在数据仓库中不断发展(例如1:M到M:M)，那么data Vault将简化这些关系的捕获，并更关注于交付真正的价值。
l 如果计划在仓库中存储PII数据，并受GDPR、HIPPA或其他法规的约束，data Vault将帮助进行数据审计和可追溯性
权衡DV的利弊，找到更好的适用于自身情况的建模方法才是最佳方案。