数据仓库建模设计用途

Data Vault 实际上是一种设计范式，而非一项技术。它可以用于任何关系数据库或数据湖。它的诞生源于人们渴望找到一种更好的数据仓库方式，摆脱数据仓库中常用的星型/星团/星座型和雪花型（并非数据库公司）模式设计。

但这样做实际上提供了一种不同的模式，实际上将最终用户排除在外，或者至少限制了他们。查询最终用户可能很困难，而且实体的组织方式也不直观。如果主要受众是工程师而不是最终用户，它可以取代仓库或操作数据存储。但它绝对不是数据集市的替代品。

为什么要抛弃它们呢？它们不是真的有效吗？就像科技行业的许多事情一样，它们是否“有效”取决于用例。你打算用它做什么？它的功能是什么？消费者和生产者角色的参与者通常决定了用例的参数，也就是焦点和边界在哪里。

就我上面提到的星型模式的变体而言，用例的焦点是最终用户。他们要么使用交互式工具和查询以临时方式访问数据，要么同时使用生成的报告。为了让您直观地了解上述模式，我在下面绘制了一个简单的星型图。顶部的三个表是星型模式的源数据，以绿色突出显示。

下图展示了除雪花模型之外的其他变体。雪花模型基本上是在下图的基础上添加了无量纲参考表，这些参考表在大多数情况下与维度相关。例如，各种类型的表用于对维度内的数据进行分类。思考一下货运类型（空运、陆运、海运）以及每种货运的特点。

明星：一个事实，多个维度

Typical Star Schema Pattern

星团 - 具有维度的多重事实

Depiction of Potential Star Cluster Pattern

星座：多重相关事实和维度

Multiple related Facts and Dimensions

您可能可以推断，所有这三种设计都专注于为消费者创建和提供分析，无论它是使用查询还是报告的交互式工具。

从最终用户的角度来看，在后台，需要进行大量的数据质量清理和转换，才能将数据写入维度表 (Dim)。这还是在将分析数据填充到事实表 (Facts) 之前。

由于所有维度和事实都使用“哑键”或代理键（这在集市和仓库设计中几乎是标准做法），因此存在创建重复项的可能性。这是因为在某些情况下重复项是有效的，而代理键设计模式可以适应这种情况。当使用时间序列数据时，代理键尤其有用，因为时间戳值可以相同，但序列会区分它们。

数据质量

数据质量控制必须精准，否则很容易导致数据“失真”。如果您使用失真的数据运行机器学习模型，它们就会出现偏差，无法提供预期的结果。偏差的过度出现通常表明数据质量问题或机器学习模型存在敏感性。这至少是使用数据仓库设计模式的部分优势之一——它可以防止重复数据并确保某些数据类别的唯一性，从而帮助减少数据质量方面的工作量。理论上，它应该能够进一步帮助防止偏差问题。

它只涉及一个方面，即唯一性，并没有具体解决数据内容验证问题。例如，如果某列的值只能包含 9 个字母数字字符，则需要进行验证；如果某列的值被限制为值列表，则仍然需要进行检查。在我看来，最常见的数据质量验证类型是检查由于约束条件而产生的列值。例如，长度、数据类型、字数等等。如果所有数据源都是关系数据库，并且对列应用了约束条件，那么数据质量工作就会容易得多。但这种情况非常罕见。

数据来源于结构化、半结构化和非结构化格式。因此，可以说，数据检查工具的生命周期还很长。对于需要构建“自主研发”解决方案的人来说，以各种形式（从 Python 脚本到 SQL）使用正则表达式（简称 regex）非常常见。市面上有各种 Python 数据验证框架和工具，例如pydantic和cerberus 。多年来，市面上出现了许多数据质量工具，但它们似乎因价格昂贵而无法被采用，因此被规模更大的公司收购并集成到其产品中。过去二十年， Informatica 、 IBM 、 SAS和Ab Initio一直在收购数据质量和商业智能产品。

Data Quality Remediation

其他最常见的数据质量检查是记录计数，本质上是检查加载过程中输入和输出是否匹配。这是您可以执行的少数几个通用数据质量检查之一，因为一旦开始对数据进行转换，具体的计数就不再重要了。您需要了解转换的输入/输出比率，以便计算转换结果的计数范围。正如我之前提到的，Data Vault 的创建因素之一是数据质量，但还有其他几个因素。

数据仓库

它的创建者Dan Linstedt将其描述为“一组注重细节、具有历史追踪功能且相互关联的唯一规范化表，用于支持一个或多个功能区域。它是一种混合方法，融合了第三范式 (3NF) 和星型模式的精华”。据 Dan 所说，它的灵感来源于对神经元、树突和突触的简化理解。

Data Vault 有诸多优点，例如所有关系均由键驱动，且设计模式可扩展至数 PB 级数据库。Data Vault 是锚点建模的一个例子，锚点建模是一种敏捷的数据建模方法，因此它可以捕获变更，且不会对现有模型造成广泛影响。此外，它还由业务流程驱动，理想情况下，星型模式及其变体也应如此。

建模方法类似于创建实体关系数据模型：创建一个逻辑模型来表示业务流程及其涉及的数据元素。Data Vault 是一种高度规范化的基于实体的模型创建方法，由于您无需在整个架构中重复数据元素，因此它提供了很大的灵活性。

这种建模实践的另一个好处是，它确保了完整的可审计性和可追溯性。它还符合 SEI CMM 5 级标准（可重复、一致、冗余架构），并提供符合萨班斯-奥克斯利法案 (Sarbanes-Oxley)、健康保险隐私及责任法案 (HIPPA) 和 BASIL II 标准的模型。

Data Vault Hubs, Satellites, and Links

那么它到底是什么？Data Vault 是由 Hub、Satellite 和 Link 组成的集合，它们代表了在逻辑数据模型阶段（先决条件）建模的业务流程。它应该能够代表您正在处理的领域；以下是假设的业务案例。它的最佳用例是用于操作型数据存储或数据仓库；它们不能替代星型模式。

下图是一个假设的数据流，它来自一个从事股票、债券、期货、期权等交易的资产管理公司。由于一些金融交易现在是全天候的，而且很大一部分是算法交易，因此图中的“交易员”实际上就是软件。此外，经纪商和做市商可以是单一方（一家企业），大型机构交易中也可以有多家托管银行参与。

有时，托管银行是第三方，其唯一目的是在两家或多家托管银行之间转移资金。这在国际市场上很常见。这些细微差别只是增加了交易的参与方，但并不会改变交易流程本身。

Asset Manager Trade Flow

下图基于上面的数据流图，展示了一个属性逻辑数据模型。我添加了一些我认为比较突出的常见属性，但这通常会包含一些额外的元素，使模型更加精细，但可能会给这个例子带来干扰。所以我把它们去掉了。

Trade Logical Data Model (LDM)

将上面的 LDM 转换为数据仓库的物理格式如下。通常，LDM 转换为物理格式时，实体到表的转换过程非常相似，除非需要使用关联表在物理上实现多对多逻辑关系。物理格式中也可能存在反规范化，但该阶段通常是在测试周期中发现性能问题后进行的。我无意双关，但反规范化并非常规做法——你本身并非从这里开始；它是一种被动反应，或者遵循既定模式。

物理模型的数据仓库实现与 LDM 非常不同。您会注意到，它看起来不像星型模式或其任何衍生模型。

Trading Data Vault Example Schema

数据仓库在设计模式中遵循几个核心概念：

• Data Vault 设计并非星型模式及其衍生模型中实现的 OLAP 的替代品，它们也并非OLTP 的“最佳选择”，而是作为数据仓库或操作型数据存储。它在某种程度上是一种混合体。

• 它针对存储而不是用户驱动的查询进行了优化，这在某种程度上是由于严格遵守第三范式（3NF）。

• 三种实体类型：枢纽、卫星和链接。您可以拥有支持静态卫星的参考表，例如国家/地区或货币表、邮政编码、度量衡。

• 中心表是指数据更改较少的表。它们应该包含一个业务键。在某些方面，你可以将它们想象成变化非常缓慢的维度。

• 链接是业务键之间的关联，这些键通常是枢纽，但并非总是如此。它是一个关联实体，用于解析键之间的关系。

• 卫星节点用于存储时间和描述性属性，例如生成的日期/时间数据，类似于交易内容。卫星节点可以与其他卫星节点建立关系、提供参考数据，并链接到枢纽节点。

• 枢纽节点之间存在链接，链接表吸收了枢纽节点的主键。枢纽节点可以拥有卫星节点作为子节点。

• 链接可以以卫星作为子级，但不能以卫星作为父级。链接主键会被卫星吸收。

• 每个表的每一行都有一个加载日期和记录来源。当它们添加到表中的“自然”键或“业务”键时，应该创建一个唯一键。对于没有“自然”键的表，可以使用代理键。假设您使用的是关系型数据库管理系统 (DBMS)，可以使用唯一键约束或唯一键索引来强制执行此约束（最后一个是我自己的一点建议）。

• 如果您在没有约束或索引的数据湖中实现模型，则可以改用分区定义，并且显然可以将逻辑写入代码中以强制执行分区定义。除非您正在编写 Apache Iceberg，因为约束可以在其元数据层中实现。

• 根据您使用的文档数据库，您还可以使用约束。

数据加载实践

加载表的顺序很重要，尤其是在使用键/索引进行约束的情况下。首先要加载的是集线器，可以并行执行，创建新的代理键。下一步是链接，加载任何属性值并在集线器之间创建关联。最后是卫星，它们位于链接或集线器的接收端，可以彼此并行加载。

为了确保记录的唯一性，请记住 3NF 原则。哈希值通常用作 ETL/ELT 处理的一部分，用于将传入记录的哈希值与表中当前记录的哈希值进行比较。记录永远不会从数据仓库中删除。

用例： Data Vault 设计的主要用例是操作数据存储 (ODS) 和企业数据仓库 (EDW)。由于以下几个因素，这两种情况都很适合：

• 严格遵守第三范式 (3NF) 不会在表中出现非规范化或重复的字段，从而实现最高效的存储利用。

• 数据唯一性检查内置于加载过程中，使用哈希值来确认是否已存储该特定记录，从而避免记录重复。这也减少了存储空间。

• 对于最终用户来说，查询可能比较困难。与典型的最终用户相比，您需要更高级的 SQL 知识才能查询数据仓库设计中的表。它更适合工程师访问数据，也就是说，它不够用户友好。如果您想将数据公开给最终用户，在传统的关系数据库管理系统 (RDBMS) 中，您可以创建视图来简化他们的访问。

• 存储的记录越少，意味着查询扫描的数据就越少，因此与非规范化结构相比，使用高效查询进行输出的检索时间所需的工作量就越少。

• 它的表设计更适合工程师。它严格注重规范化，其结构反映的是高效的数据存储，而不是业务流程。

我认为 Data Vault 设计模式绝对有其适用之处，尤其是在你确实想要保存尽可能多数据的情况下。无论是在数据湖还是关系型数据库 (RDBMS) 中。与任何星型模式或星型模式的衍生模式相比，它可能是解决这个问题最有效的方法。ODS 的情况通常是保存一周到几个月的数据，它也非常适合这种情况，因为规范化在各方面都有帮助。这些特殊用途值得评估。