了解数据网格中的数据建模

本文旨在解决数据网格上下文中数据建模的有趣主题。具体来说，它将阐明企业数据模型是否持久存在于数据网格框架中。

在深入研究数据模型的复杂性之前，我建议阅读我的前一篇文章“数据集成和数据建模去神秘化”。如果您已经熟悉概念数据模型、逻辑数据模型和物理数据模型，可以直接阅读以下内容。此外，“数据域-我从哪里开始？”为本次讨论提供了重要的上下文。

为了更好地理解数据网格和数据模型之间的关系，让我们从图开始。请注意，该图有点学术性，但理解不同类型的数据模型至关重要。

Conceptual diagram showing how business capabilities, domains, application domains, data models and data domains relate.

上图说明了两个不同的域。每个域都与业务功能图中的业务功能相关联。业务能力非常重要，因为它们代表了组织的运营职能，并主要解决问题空间。当实现业务功能时，它将具体化为特定上下文的功能实例。该实例充当我们的域，包括一个明确的边界，其中包括应用程序解决方案空间、域模型和数据域。让我们更深入地研究这三项。

深入数据模型

首先，您看到一个应用程序域。这些是紧密协作以提供特定业务价值的应用程序和组件。应用程序域中的这些应用程序具有逻辑和物理数据模型。这些模型通常非常具体和复杂，具体取决于手头的问题。例如，OLTP系统的物理数据模型可能由数千个3NF形式的表组成。与特定业务功能相一致的应用程序和组件与与其他业务功能相协调的应用程序保持解耦。这允许更大的灵活性和相互依存性。

其次，有一个（概念）领域模型。这是应用程序域和数据域中使用的上下文模型。上下文数据模型通常存储在业务目录中，如Microsoft Purview。

第三，有一个数据领域，开发数据产品。该领域包含可以在域之间共享的技术和结果数据，也称为数据产品。与应用程序域中的应用程序非常相似，这些数据产品也具有逻辑和物理数据模型。例如，不受技术限制的逻辑数据模型概述了数据元素的结构，并建立了它们之间的关系。这可以定义为使用DBT等工具的实体关系数据模型。另一方面，物理数据模型描述了如何实现数据模型，例如对于驻留在Lakehouse的黄金层中的数据产品。
在上下文中，数据域和应用程序域重叠，因为它们共享与构建业务功能所基于的域模型相同的语义。然而，物理数据产品可能看起来不同，因为它们是专门为在域之间共享数据而设计的。因此，这些物理模型通常更方便用户使用，通常表现为非规范化的事实和维表。
最后，域模型之间存在虚线，表示域之间的上下文重叠。这种重叠表明，某些术语和概念可能具有相同的定义或密切相关。

实现域之间的一致性

现在我们知道了域是如何建模的，问题就经常出现：我们如何实现域之间的一致性？是否有中央数据模型？让我们在接下来的部分中找到答案。

正如我们所讨论的，数据产品存在于有界上下文中，并从域模型继承上下文。例如，可以通过业务词汇表来管理和检测有界上下文之间的重叠。如果发生重叠，则在构建数据产品时可以应用某些构象。例如，可以要求域符合相同的参考数据，例如国家代码、货币代码、会计代码和产品代码。这使数据产品中的这些元素标准化。当关键数据元素重叠时，也可以要求域标准化命名约定，例如，根据事物在数据目录中的定义方式。然而，由于数据产品仅限于一个域，因此数据仍然是不集成的。因此，与数据管理和数据产品创建相关联的任务在域本身中执行。

Conformation and standardization can occur in different areas of your architecture: at the source system, within aggregated data, or on the consumer side.

在研究重叠数据时，可能会遇到不同程度的重叠。一些上下文（和数据！）被密集地共享并扩展到许多域，而其他数据只能跨越两个或三个域。根据重要性、规模和范围，如我们所讨论的，构造可以在企业范围内实现。在这种情况下，您可以考虑将此模型作为企业数据模型进行文档化和管理，该模型规定了应如何在所有域的数据产品中组织数据。理解构象发生在域内是至关重要的，因此需要广泛的配位。
一些数据从业者会认为，企业参考值的使用或关键数据元素的管理不符合真正的数据网格实现。在某种程度上这是正确的，但如果没有任何（引用）完整性，您将看到在所有域中进行协调和集成的重复努力！

了解数据网格中的聚合

在数据网格中，还有一个概念称为聚合或聚合域。假设我们注意到消费者端的数据消费方式有相当大的重叠。在这种情况下，我们可以选择合并、集成和协调新数据域中域之间的所有重叠数据。这甚至可能涉及更改数据的语义上下文，从而产生新的域模型。

我们也有新的应用程序模型吗？不，可能不是，因为这个练习的主要目标是提高一致性。
这是否会产生新的业务能力？事实上，我们可以将这些确定为支持能力，对组织的运营至关重要，但与产生核心业务价值没有直接联系。

所需骨料的数量或尺寸不是用石头设定的。您可能有几个较小的聚合域，它们简单地连接和组合来自不同主题领域的多个上游源的数据。或者，可以有许多聚合来满足消费者方面的广泛领域。甚至有可能拥有一个集成和协调大量数据的非常大的聚合域，其功能非常类似于大型数据仓库系统。这不是一种罕见或被禁止的做法，在金融部门尤其普遍。大型机构必须确保整个企业的报告一致，因为法规要求会计、财务和集团报告以及审计和风险管理等领域必须使用相同的维度。该协调问题的一个常见解决方案是将许多数据放在一起，这在某种程度上与数据网格方法形成了对比。

数据消费和确认

最后，在消费者方面，我们见证了数据消费。这引入了另一个域模型，因为上下文不同于所有其他域。我们还看到存储或用于消费活动的报告、分析模型和数据的应用程序域。
现在，如果这个新创建的上下文与其他域共享，该怎么办？在这种情况下，我们很可能会看到新数据产品的开发，导致包括支持技术服务的数据领域的出现。这些数据产品将有自己的（逻辑和）物理模型，理想情况下应该是用户友好的。
这些数据产品是否也可能进行确认？事实上，例如，如果存在参考数据的重叠，则促使消费领域对其进行标准化是合乎逻辑的。这与我们在体系结构的提供者端建立的相同原则相一致。

企业数据模型

现在，我们了解了数据如何跨域分布，以及如何聚合数据。但与企业数据模型的相关性是什么？这个问题没有一个简单的答案。
对于某些组织，企业数据模型是大型聚合中数据模型的有形表示，详细说明了大量数据需要如何协调以供下游使用。因此，消费端域必须将其数据源的相当一部分与该聚合中管理的数据对齐。
对于其他组织，企业数据模型充当跨不同领域构建数据的战略大纲，描述各种数据产品之间的关系，包括参考数据、数据类型、标识符等的标准。
对于一些人来说，企业数据模型充当架构蓝图，说明跨域的数据产品的标准化和某些区域内的聚合过程。

总结

总之：断言数据网格不适应企业数据模型要微妙得多。正如我们所探索和观察到的，有一个重大的重叠，需要管理。数据网格和企业数据模型之间的相互作用不是二元的；它并没有严格遵循要么或要么的范式。相反，它们以共生关系共存，每一个都通知和塑造另一个，以确保数据在域之间和域集合内有效地结构化、标准化和协调。因此，断言数据网格和企业数据模型不能共存，过于简化了数据架构的这两个关键组件之间复杂而微妙的关系。

这篇博客文章的很大一部分内容来源于《大规模数据管理》一书。对于有兴趣更深入地了解数据管理及其相关挑战的读者，有专门介绍这一主题的综合章节。我强烈建议你自己去看看。