Data Vault 2.0 深度解析：敏捷数仓建模的利与弊

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 还包含了针对数据仓库项目评估和敏捷任务分级的敏捷化手段，用来准确判断任务复杂度或横跨数据仓库的工作量。在更微观的层面，它还提供了一套非常精炼且迭代性强的方式来处理常见的功能性需求。这些涵盖了全面、可重复、渐进式且以敏捷为基石的流程，用以完成日常任务，例如（但不限于）在 ETL 和建模阶段添加数据属性、进行数据切片、新增数据源、扩展源系统、历史轨迹追踪、弃用旧源以及响应源端结构变化等。
简单来说，DV 模型是传统维度建模（OLAP、星型模式）与暂存区之间的一个独立层，它能依据不断增长的业务需求进行灵活伸缩，并化解建模与 ETL 的复杂性。DV 模型由中心（业务实体）、链接（关系）和卫星（描述属性）三类构件组成，其建模范式介于 3NF 与星型模式之间。该层放置在数据集成层（常称为原始数据库或 Raw Data Vault），并能与 Kimball 的维度模型高效协同。

Data Vault 2.0 的优势
以下是 Data Vault 2.0 方法论带来的一些主要收益：

它假定数据建模中的关系存在最坏情形——即业务对象之间普遍为 M:N 关系，以此避免当关系从 1:M 演变为 M:M 时需要进行结构变更。这样一来，关系粒度发生变化时几乎无需额外返工。

它是为原生跟踪数据历史而设计的，所有关系、属性及其在一段时间内的数据来源都可以被完整记录和追溯。

它提出了一组设计原则和配套结构（如坑表和桥表），用以提升数仓内部的历史追踪性能。数据仓库模型足够灵活，可在迭代建模过程的任意时间节点引入这些结构，而无需超前规划和设计预留。

它在逻辑上将存放原始数据的区域与存放已加工数据的区域分隔开来。原始数据仓库（Raw Data Vault）构成了源系统可审计数据的底座，而业务数据仓库（Business Vault）则为需要访问数据集市下一层明细数据的高级用户提供了查询空间。

将软业务规则与硬业务规则剥离到数据集成的不同环节中，这强化了数据在多个下游应用间的可复用性。例如，原始数据只需在数据仓库中整合一次（减少到暂存区的重复整合），便可多次供下游消费。

在每一次敏捷迭代中，存储全量历史轨迹的 DV 模型都容易扩展，不必担心丢失历史数据。此外，历史轨迹是独立于维度模型进行存储的。

Data Vault 2.0 提倡使用业务键的哈希值（Hash Key）来实施数据关联，以减少查找操作，进而提升加载过程的并行度，这降低了顺序加载的依赖。

原始数据仓库（ODS 层）天生具备完全的可审计性。

从整体数据仓库链路看，从暂存区到星型模式和 OLAP 的处理过程变得更加顺畅且具有迭代属性。

它提供了一套综合方法，能够将来自异构数据源且携带多种不同业务键的数据有效融合到一起（即跨多个源系统在仓库内完成数据集成）。因为业务键并不总是呈现 1:1 对应或格式一致。

• “即时建模”的思维模式与敏捷方法高度契合。

Data Vault 的局限性
尽管 DV 优点突出，但其不足也相当明显，例如：

DV 实质上就是在数据集市（或星型模型层）与临时存储层之间多加的一层。在 ETL 开发和建模方面，这一层的构建会带来额外的开销。如果项目规模较小，或者项目生命周期很短，采用 Data Vault 模型就可能得不偿失。

采用 Data Vault 的主要驱动因素之一是满足审计和历史轨迹的需求。若这些目标并非关键，那么额外增加一层建模所产生的成本就变得缺少说服力。但从长期需求来看，它或许是一项值得的前期投资。

DV 的本质是对关系、业务键和属性的分解式表示，因此与星型模式等非规范化结构相比，它会创建更多的表。当然，考虑到 Data Vault 是对星型模式的补充，这种“多”也只是相对而言。正因为如此，在 Data Vault 之上查询数据往往需要大量的表连接。

缺少大规模的真实落地案例。

对于习惯了 Kimball 或 Inmon 模型的人来说，这种建模方法通常不那么常规和顺手。

何时选择 Data Vault？
有几个关键变量可以作为判断的依据，例如：
l 当我们认为数据仓库项目对历史轨迹追溯和审计有刚性需求时，DV 建模便是一种非常值得考虑的选择。
l 此外，如果跨业务实体的关系在数据仓库中持续演化（比如从 1:M 变为 M:M），Data Vault 能够大大简化这类关系的捕捉，使团队更专注于交付真正价值。
l 若计划在仓库中存放个人身份信息（PII），且需遵从 GDPR、HIPAA 等法规约束，Data Vault 将为数据审计和可追溯性提供有力支撑。
权衡 Data Vault 的利弊，结合自身实际场景选择最适合的建模路径，才是更明智的做法。