《流式Data Mesh》第三章：领域所有权-灵析社区

第三章：领域所有权

流数据网格的四个支柱之一是领域所有权。定义数据领域可能会很困难，特别是当数据经常与多个领域共享，或者当一个领域依赖于另一个领域的数据时。然而，在其核心，数据领域的定义是相当简单的。领域是生成逻辑分组的数据所涉及的人员和系统。一个领域指的是与共同目的、对象或概念相关的互相关联的数据领域。这些数据最终会被共享（并可能被转换）为发布的数据产品。数据领域还具有输出端口，定义了数据产品的共享方式，以及输入端口，定义了如何从其他领域消费数据（参见图3-1）。

这些端口构建了领域之间的互连，从而创建了数据网格。这些端口代表数据产品的生成和消费。在流数据网格中，这些端口是流数据产品。领域内部的系统和团队不会暴露给网格。它们帮助支持流数据产品的管理和开发。在本章中，我们将概述一些方法来确定领域，以确保领域在流数据网格中无缝运行。

识别领域

图3-1显示，团队和系统包含在一个领域中，因此可以影响其定义。团队通过成为他们所在业务领域和维护开发的应用程序的专家来影响定义。系统通过其物理位置和所持有的数据来影响定义。团队和系统聚集在一起，作为一个整体来创建流数据产品。

重要的是要理解，影响数据产品生产的因素比影响数据产品消费的因素对领域的识别更为重要。消费领域只期望对数据产品进行保证，而生产者负责提供这种保证。我们将在本书中讨论其中的一些因素。

我们在本书中经常使用的类比是在杂货店购买农产品。作为购物者，您希望在购买和最终消费之前检查农产品。看到农产品受到保护，使购物者对其清洁程度有了保证。例如，看到有机标签可能使消费者对他们的食品产品质量有信心。对于农民和经销商来说，为其产品传达这种保证和质量需要付出很大的努力。

可辨识的领域

根据源对齐的数据来识别领域非常容易。只需在数据产生或生成的地方创建一个领域。使用和理解数据的事物往往会围绕着这些数据聚集。这包括应用程序、工程师和业务专家，他们负责解决业务问题。同样地，基于应用程序团队或业务问题来识别领域也很容易。只需在解决业务问题的团队所在地创建一个领域。

地理区域

团队之间存在大的地理距离，需要通过异步通信（如电子邮件和Slack）交流，这会使得将数据保留在单个领域变得困难。远距离不仅使团队之间的沟通变得困难，还可能导致数据产品的速度变慢。因此，在这种情况下，通过地理区域来确定领域可能是有价值的。

图3-2展示了一个简单的数据流水线，它从两个数据源获取数据，进行连接操作，并将结果数据产品发布到数据网格中。如果其中任何一个箭头需要跨越遥远的地理区域，那么流水线可能无法满足数据产品消费者的SLA期望。流水线还会遇到一些问题，因为许多用于处理数据的工具并不适合被拉伸到如此远的距离。

在这种情况下，如果其中一个数据源位于远程地区，将为其创建一个新的领域并让其为当前领域发布数据产品将是有益的。

在图3-3中，源数据库的摄取由一个新的领域（领域2）执行。然后，领域2将数据产品发布到数据网格中。原始领域（领域1）现在成为领域2的数据产品的消费者，并在发布自己的数据产品之前进行其转换。原始领域的分离强制领域2提供满足领域1 SLA要求的数据产品。

那么，既然领域2仍然需要将其数据从远距离提供给领域1，它如何提供更好的SLA呢？解决方案是领域2在远距离之间复制其数据产品，以便将数据产品本地提供给领域1，而无需扩展其数据流程。数据产品的复制对领域1来说是不可察觉和未知的，数据保持在运动中且实时。有关此模式的详细信息将在第7章中讨论。

在另一个领域内使用另一个领域的数据产品来增强数据产品很容易被误解为子领域。然而，两者之间存在区别。在前面的示例中，我们将领域2视为一流的领域，由专门的团队维护其数据产品，该团队了解数据的业务背景，并能够提供经过转换、高质量可靠的数据产品，以供其他领域使用。子领域在控制领域内的方面发布时采用了更具层次结构的方法。虽然两种方法相似，但存在区别。

子域和子数据网格

在数据网格架构的四个支柱中，并没有禁止我们在较大的域中创建子域。但在数据网格中，子域应该被视为普通的顶级域。域-子域层次结构只是元数据，它将作为额外信息提供给数据产品的消费者，以帮助他们决定是否使用数据产品。我们还可以利用继承和域与子域之间的关系来创造一些创造性的手段。这为创建更易管理的自助工具提供了机会，尽管实现上可能会更加复杂。

类似地，创建一个子数据网格，即存在于域内的数据网格，可能也太复杂了。为了将一个数据网格与其他网格分隔开来，所需的元数据可能过于庞大而难以管理。将域及其产品保持平坦，以便更容易发现和搜索，可能更加简单和优雅。域仍然可以存在于一个类似于总体结构的单一实体中，但将子域模式数据作为元数据提供给域可能更可行。这样，一些子域数据（不是全部）可以仅作为信息提供，成为数据产品的描述的一部分。

数据主权

在多个地理区域存在将需要对每个地区的数据主权法规（如GDPR）具有特定的了解。这些规定强制要求私人数据的物理存储和传输位置，以及数据的使用方式。数据主权是保护敏感的私人数据，并确保其始终在所有者的控制下。数据主权规则是特定于国家的，因此捕获数据起源的位置在每个数据点的传承中也至关重要。在数据网格的上下文中，跨多个地区分割域的原因不仅是技术上的，也涉及法律问题。

对特定地区的治理规则有全面的了解对于避免巨额罚款至关重要。在许多情况下，这些罚款可能适用于受影响的整个数据集中每条违规记录，而不仅仅是暴露的记录。对于单个域，了解多个数据主权规则可能会令人不知所措，难以实施。按照数据主权规则将域分离可使您在任何数据在数据网格中共享之前就开始考虑数据治理。当治理放在首位时，规则集可以立即在代码中强制执行，而不是事后补救，这显然是有风险的。在域的开发早期开始考虑的一些事项包括如何在数据主权规则的范围内加密、标记、混淆或过滤数据，同时仍允许数据的民主化。

随着用户在滥用数据资源方面变得越来越聪明，可以预期数据主权规则将发生变化。规则的实施需要具备灵活、易于部署的特点，以便能够在不涉及大量代码更改和大规模部署的情况下更改需求。还要了解数据主权规则可能仅影响整个数据集中的几个属性或字段。在数据集的元数据层中能够识别或注释这些私有属性将使数据主权规则的实施更具配置能力，并适应变化。有关如何实施安全和治理的更多详细信息将在后续章节中讨论。

混合架构

混合架构与前一节中的地理距离不遵循相同的逻辑，因为本地系统可能具有与基于云的系统不同的安全要求。对于本地数据产品无法向其他域提供公共端点进行消费可能是不可行的，甚至可能是不可能的。在这种情况下，如果一个域既有本地系统又有云提供商的系统，将所有数据资源保留在同一个域中，并对数据产品的消费者隐藏复杂和安全的网络拓扑结构可能更好。

在图3-4中，云和本地数据中心位于同一个域中。本地源数据库的数据被复制到云端，在云端与另一个数据源进行丰富，然后作为数据产品公开。消费者只看到最终的数据产品。不仅数据被复制，元数据也被复制，以保留传承关系。如果本地域没有任何云基础设施，创建一个云基础设施可以使更多的数据消费者能够访问数据，这可能是有益的。

多云

跨多个云提供商扩展业务可以提高对任何单个云提供商中断的弹性。这显然会给付费客户带来更多的信心和保障。对于您的客户来说，以他们选择的云提供服务也是一种成本效益，这将使他们不需要为网络出口相关的成本支付费用（有关成本和后付费的详细信息将在本章后面进行讨论）。

数据的复制再次发挥作用。类似于在地理区域之间进行复制，数据将在云提供商之间进行复制。这可以在单个域内或作为单独的域来完成，具体取决于使用情况。有几种方法可以实现这一点，我们将在以后的章节中讨论。

灾备

如果采用多云解决方案的原因是为了实现从单个云提供商进行灾难恢复（DR），更合适的做法是将数据复制的两端保持在同一个域内，以便将与DR相关的任务保留在域内。跨云提供商的解决方案（或应用程序）很可能会被设置为主备或主-主模式，如图3-5和3-6所示。

图3-5展示了两个操作数据库位于不同的云服务提供商（CSPs）中。操作数据从CSP1复制到CSP2，以保持CSP2中应用程序的状态，以应对CSP1发生灾难的情况。这是一种主备灾难恢复解决方案：活动状态为CSP1，灾难/备用状态为CSP2。由于其被动状态，此解决方案无法充分利用CSP2的所有资源。只有在CSP1发生故障时，应用程序才会切换到CSP2，从而充分利用CSP2的资源。

图3-6中的主-主灾难恢复（DR）解决方案利用了两个云服务提供商（CSP）的资源。只有使用失败的云提供商的应用程序才会切换到另一个CSP，而不是图3-5中的主备解决方案中的所有应用程序。数据的双向复制使得两个CSP之间所有应用程序的状态保持同步，以实现从任何一个CSP到另一个CSP的故障切换。

在数据网格的背景下，主动-主动（active-active）和主动-被动（active-passive）解决方案均包含具有相同数据的数据库（通过复制考虑延迟）。在主动-被动方案中，从被动数据库捕获数据以作为数据产品进行公开，这将允许您限制对主动数据库的访问。在主动-主动方案中，从其中一个主动操作数据库中捕获数据是可以接受的。在流式数据网格中，这两种情况都有各自的优点，具体取决于产生领域提供的弹性保证。

分析

许多不太具备弹性的应用程序并不需要跨云服务提供商（CSP）的灾难恢复，但仍可能使用其它 CSP 上他们偏好的服务。例如，操作平面的数据存储可能位于一个 CSP 中，而分析平面可能位于另一个 CSP 中。这是一种常见的做法，因为许多数据科学团队更喜欢使用可能仅存在于一个 CSP 中的特定工具。在这种情况下，可以明确将操作和分析平面视为通过数据网格共享数据的不同领域。

避免模糊的领域定义

在没有明确定义的边界的情况下，领域之间似乎相互交织，所有权变得政治化或需要解释。例如，一个大型零售商很可能有多个领域。一个可能是与产品SKU相关的一组产品属性。另一组数据可能与客户有关，包含定义其人口统计信息的属性。这两个领域相互独立，并由各自理解适当业务背景的团队维护。这些领域可以转换和发布为数据产品，供另一个领域（如交易销售数据领域）使用。交易销售数据领域可以提供不仅发布销售数据，还整合有趣的产品属性和客户信息以推动报告和数据科学的数据产品。

为了克服模糊的领域挑战，每个领域边界必须明确而明确。属于一起的业务领域、流程和数据需要保持在一起。此外，每个数据领域应该属于一个且仅属于一个敏捷或DevOps团队。数据领域内的数据集成点应该可管理，并且所有团队成员都能理解。

我们建议将领域边界具体化且不可变。这有助于避免关于谁拥有什么数据的冗长讨论，并防止团队自由解释领域边界以适应自身需求。创建面向领域的结构是一个过渡过程，不仅涉及数据，还涉及人员和资源。在创建领域边界时，资源可能最终会与其他团队对齐，从而破坏和演变当前的团队结构。数据网格的整个概念与资源对齐同样重要，因此，在进行此过程时，重新调整资源不应被视为障碍。

正如我们之前提到的，共享跨领域的数据会引发复杂性。在许多情况下，建议创建一个共享数据领域，以便以一种允许其他领域标准化和受益的方式提供集成逻辑。重要的是，保持此共享领域的规模较小，并将其命名约定概括为适应其他领域的逻辑上下文。

对于重叠的数据需求，领域驱动设计提供了处理此复杂性的模式。表格 3-1 是这些模式的简要总结。

领域驱动设计

对于源对齐的领域数据和应用团队技术来识别领域，如果您的应用程序和相关数据源尚未定义，您需要一种方法来帮助定义它们。领域驱动设计（DDD）是一种方法论，通过将数据模型本身与核心业务概念相连接，帮助我们理解复杂的领域模型。从DDD中获得的理解为设计基于分布式、基于微服务的面向客户的应用程序奠定了基础。

DDD将软件和其组件的实现与不断演化和变化的数据模型相连接。领域是您正在处理的业务世界和您试图解决的问题。这通常涉及需要作为解决方案的一部分进行集成的规则、流程和现有系统。

DDD最初由Eric Evans在《Domain-Driven Design》一书中首次提出。该书关注三个原则：

主要关注核心领域和领域逻辑。
复杂的设计基于领域模型。
技术和领域专家之间的协作对于创建能够解决定义的领域问题的应用程序模型至关重要。

在进行DDD时，理解以下术语非常重要：

领域模型
领域逻辑
边界上下文
共通语言（Ubiquitous language）

领域模型

领域模型涵盖与您正在解决的问题相关的所有思想、知识、指标和目标。领域模型代表问题领域的词汇和关键概念，并应该确定领域范围内所有实体之间的关系。许多软件项目在开发初期就缺乏共同的术语、目标和提出的解决方案。这就是领域模型的作用所在，它作为问题解决和提出解决方案的清晰描述。此外，领域是您业务的世界，模型成为解决方案，而领域模型则充当关于问题的结构化知识。

领域逻辑

领域逻辑代表领域存在的原因或目的。其他可能使用的术语包括业务逻辑、业务规则或领域知识。领域逻辑在领域实体中定义，这些实体是数据和行为的结合体。它们在实体内部和之间强制执行逻辑，最终为领域所面临的问题提供解决方案。

边界上下文

在领域驱动设计（DDD）中，边界上下文是逻辑和复杂性聚集在一起的边界。它们有助于将业务逻辑和实体组织成组，以增加模块化和灵活性，从而可以创建领域和子领域。最终，这些边界上下文可以成为数据网格的领域或子领域。

共通语言

共通语言建立了一种术语，使领域专家和开发人员在设计领域时能够简化沟通。如果没有建立共通语言，领域的各个角色之间可能会出现沟通障碍，例如，在领域模型中明确表达问题，以便工程师能够将技术问题传达到业务逻辑层面。反之，领域专家能够将业务逻辑问题明确到更低级别的技术异常同样重要。这使得所有角色能够理解整个问题范围以及如何处理和向用户提供解决方案。

DDD的结果是构建遵循事件驱动架构（EDA）的应用程序的解决方案。工程师使用EDA模式设计应用程序，该模式基于事件、关系、业务规则、边界上下文和在DDD过程中定义的共通语言。应用程序中生成的事件和实体成为业务领域中的数据，潜在地可以成为流式数据网格中的数据产品。

在遵循DDD的过程中，领域专家帮助定义业务对象，并确保它们符合业务的整体背景。例如，在一个领域中，账户和员工可以被视为业务对象。这些业务对象在数据网格中被转化为数据产品。这可能需要与可能声称拥有相同或类似业务对象的其他领域团队会面，而该领域正在计划提供服务。正如本章前面讨论的那样，根据业务需求，创建共享数据领域或创建共享数据的副本可能是合理的选择。

数据网格的领域角色

一个领域有两个主要角色：数据产品工程师（或称数据工程师）和数据产品负责人（或数据产品经理、数据管控人员）。这些角色可以是同一个人，也可以是领域中专门的人员担任。

数据产品负责人必须深入了解他们的数据消费者是谁，数据是如何被使用的，以及使用数据的方法。这将有助于确保数据产品满足使用案例的需求。数据产品工程师负责创建高质量、可靠且可被消费者使用的数据产品。可以通过最小的努力将这些领域角色纳入现有的领域角色中。

数据产品工程师

数据网格领域中最重要的角色之一是数据产品工程师，他负责构建、维护和提供数据领域的数据产品。这包括从操作性数据库中摄取数据、转换这些数据资产并将其发布到数据网格的相关任务。请参阅表3-2以获取数据产品工程师的任务列表。

数据产品负责人或数据管控人员

数据产品负责人或数据管控人员的角色是半技术性的，主要是为了理解数据使用模式，并确保数据产品能够满足消费者的需求。我们将使用数据产品负责人这个术语。这个人与最终用户和数据产品工程师进行沟通，并努力改进和演进产品。请参阅表3-3，了解与数据产品负责人相关的任务列表。

数据产品负责人还负责确保基础设施的规划（使用自助服务工具），并确保具备适当的资源来开发和交付数据产品到数据网格，并确保数据高可用性、符合服务级别协议（SLA）并实施所有必要的安全措施。该角色不断监控使用情况和成本，确保客户满意，同时最大限度地减少任何产生的费用。

流数据网格工具和平台的考虑

为了实施流数据网格，我们将寻找现有的工具和平台。表3-4列出了一些最有用和流行的工具和平台。

所选择的工具和平台决定了领域的接口将如何实施，换句话说，即领域之间如何生产和消费流数据产品。

领域费用分摊

在企业中，每个业务线都有预算来保持运营的顺利进行。在标准的数据仓库环境中，支付所需数据服务的责任方相对明确。然而，在数据所有权分散和分布的情况下，例如在数据网格中，谁来支付所有这些内容的费用就变得不清楚了。随着建立数据领域和数据产品的成本增加，将这些成本分摊给数据网格的消费者变得重要。以下是一些将数据网格部署所产生的费用按领域级别划分的示例：

基于使用量的费用分摊

一种领域费用分摊的解决方案是将特定的容器实例与下游用户或团队关联起来。当您希望限制下游消费者的服务托管级别时，这种解决方案非常有效。然而，该方法存在一些缺点。首先，当一组实例最初为终端用户进行配置时，很容易过度配置，导致消费者为比实际需要更多的资源付费。其次，由于服务在数据领域中共享，可能会发现消耗了一些最初未计费的资源。因此，可能需要对某些数据产品施加资源约束，可能会影响服务级别协议（SLA）。

任务级别的资源费用分摊

另一种解决方案是开发一种机制，让数据领域所有者计算每个数据产品的总成本。这种解决方案需要开发计量机制和费用分摊测量。当计量机制部署后，它跟踪请求的使用情况，包括网络、虚拟CPU和内存，以提供这些请求的服务。然后，通过费用分摊测量，领域所有者可以根据领域所运行的容器实例所产生的成本轻松地将成本与这些任务关联起来。这种解决方案允许领域所有者在共享基础设施上部署整个解决方案，而无需考虑基于使用量的费用分摊及其局限性。可以在任何时间点、任何集群和任何数据产品上计算领域使用的成本。

成本分摊费用分摊

在一个领域内可能有一些已知的数据产品消费者。在这种情况下，与其按照每个请求或基于使用量的模式计算领域使用的成本，也许更合理的是让各个团体同意在领域级别分摊数据产品消费的成本。各个团体将同意将领域运营的整体计算成本分摊给多个消费者，每个消费者负责固定百分比的成本。这种方法的优点是部署简便，因为不需要监控使用情况的机制。缺点包括无法预测和意外的使用量波动；消费者使用错误计算的总资源百分比，从而导致过度或不足计费；以及无法跟踪实际的消费者使用模式。

数据产品费用分摊

要实施费用分摊，需要配置一个监控工具来帮助衡量数据产品的使用情况和所使用的资源。这个监控工具可以作为数据网格控制平面的一部分，并随着在表3-4中描述的工具的配置而自动提供。在第4章中，我们将讨论如何监控数据产品并向消费者收费。

总结

在定义领域时，架构师需要考虑的不仅仅是在领域驱动设计中定义的业务对象。在本章中，我们提供了其他需要考虑的策略，这些策略将影响领域，例如地理区域、混合云、多云和灾难恢复需求。在第4章中，我们将展示这些领域如何构建并发布流式数据产品到流式数据网格中。