本章将讨论数据网格的核心架构组件。内容分为两个主要部分。首先，我们讨论数据产品架构，包括支持广泛工件集所需的组件以及开发、运行和操作数据产品所需的组件。其次，我们重点介绍将所有数据产品整合为一个统一整体的更广泛的数据网格架构。
数据产品架构
数据网格中的每个数据产品都设计为可发现、可观测和可操作，确保数据可以在组织的不同部分之间高效共享和利用。图4-1展示了我们将详细阐述的数据产品架构。
在数据产品架构中，有几个关键能力组：包括用于工件的架构以及开发、运行时和操作能力的架构。
数据产品工件
数据产品的内容——即工件——是使数据产品具有价值的核心。工件不仅包括数据，还包括数据产品负责人（DPO）希望提供给用户使用的其他对象。
如图4-2所示，工件的范围从基本数据集到复杂的程序和模型。它们为数据产品增添了显著的价值，使其不仅仅是一个数据存储库。这些工件使数据管理更加集成和用户友好，重点不仅在于提供数据，还在于交付一个完整的、有价值的、可立即使用的数据解决方案。
让我们从最常见的工件类型开始，几乎存在于所有当今的数据产品中：数据库、表格和文件。这些基本组件构成了任何数据产品的骨干，为用户在各种应用中寻找的核心数据提供支持。然而，工件的范围远远超出了这些基本元素，采用了一种更全面和集成的方法，意识到当今“数据”的多种形式。正如我们在第2章中讨论的那样，这些工件还可能包括：
- 图像、视频和音频，这些在现代多模态数据环境中变得越来越普遍
- 文档，如PDF或其他文本导向的非结构化数据
- 指南，帮助消费者理解或使用数据产品
- 模型，包括AI和ML模型以及较新的生成式AI大语言模型
- 经过审核的查询和流（安全、高效等），简化了数据产品的使用
- 报告，提供来自数据产品的预格式化输出
- 笔记本和程序，展示如何有效利用产品中的数据或展示数据产品中的实际处理逻辑
- 元数据，即关于数据产品、其内容、字段和格式的数据
- 转换，包括管道和其他工作流工具，能将数据导入并转化为既可用又方便消费者使用的形式
要支持数据产品中各种现代工件形式，所需的架构能力有哪些？我们在以下三个部分中讨论这些能力：
- 开发架构组件，支持数据产品的定义和开发。
- 运行时架构组件，处理数据产品的运行时考虑因素。
- 操作架构组件，帮助使数据产品可发现、可观测、可治理并可控。
开发架构组件
创建数据产品时首先要考虑的是数据产品的定义和开发，如图4-3所示。这包括对数据产品的详细描述，包括谁拥有它、它包含什么内容以及使用它的规则。这种清晰且全面的定义对于确保数据产品不仅具有功能性和可访问性，还符合组织政策和用户需求至关重要。通过彻底定义每个数据产品，组织可以最大化其数据的价值和效用，这使得该过程成为现代数据管理策略的基础部分。
数据产品开发架构的三大功能组：
- 数据产品定义：描述数据产品。
- 工件定义：描述数据产品内的工件。
- 策略定义：描述数据产品和/或工件的规则和限制。
数据产品定义
数据产品的定义包括以下最少属性：
- 命名空间：命名空间（或领域）标识数据产品所属的领域或类别。命名空间或领域在数据网格中通常是唯一的。
- 名称：名称在其命名空间/领域内唯一标识数据产品。
- 描述：描述数据产品的目的和内容。
- 端点链接：数据产品提供的端点链接，通常包括可发现性、可观测性、管理能力以及DPO希望公开的其他信息。
- 标签：标签是帮助分类和组织数据产品的关键字或标签，在数据网格（尤其是在市场中）简化导航和搜索。标签最好参考一个更广泛的业务词汇表，但并不需要从头开始，许多组织会利用专家创建和验证的公共或商业业务词汇表。
- 所有者：所有者（或发布者）是关键决策者和数据产品的主要知识来源，负责回答问题、接受反馈或解决问题。该信息必须易于获取并显著显示。
工件定义
回顾一下，单个数据产品可以包含许多工件，每个工件可能具有不同的形态、属性、安全性和隐私需求。工件定义比数据产品定义更详细，通常包括以下属性：
- 名称：名称在数据产品中唯一标识工件。
- 描述：描述工件的目的和内容。
- 标签：标签是帮助在数据网格中分类和组织工件的关键字或标签。
- 策略：参考管理数据产品使用的企业、法规、安全、隐私或操作规则和限制。
- 访问权限：描述访问工件所需的权限和角色，在授予访问权限之前应验证这些权限。
- 许可证：许可证规定工件的使用条款，消费者在访问数据产品时应同意这些条款。
- 端点链接：由数据产品提供的端点链接，通常包括元数据、示例数据和工件数据的链接（以及DPO希望公开的其他信息）。工件链接可能需要以创造性方式处理，根据其内容可能需要额外的应用程序来访问（例如，PDF格式的指南链接需要PDF阅读器）。
策略定义
数据产品策略的定义是管理其使用并确保数据安全和隐私的关键组件。通过数据契约（第5章详细讨论）启用的策略，明确数据访问和使用的可接受方式，考虑了诸如访问权限、身份管理、用户授权、服务与质量级别期望、以及遵守安全和隐私法规等各种因素。建立明确且全面的策略对于保持数据产品的完整性以及防止未经授权的访问或滥用至关重要。
访问权限是策略定义中的首要考虑因素。它决定了谁可以访问数据产品以及他们被授予的访问级别。访问权限可以从某些用户的只读访问到其他用户的完全管理权限。定义访问权限需要评估不同用户或用户组的需求、目的和职责，并相应地分配访问级别。有效的访问权限管理对于确保用户能有效执行其职责，同时防止敏感数据的未经授权访问至关重要。
与企业身份管理系统集成是策略定义中的另一个重要方面。通过将数据产品与企业的身份管理系统链接，组织可以简化用户身份验证和授权的过程。这不仅通过确保只有经过身份验证的用户才能访问数据增强了安全性，还简化了管理不同数据产品和系统用户访问的行政流程。
运行时架构组件
如图4-4所示，运行时架构描述了数据产品中的各个组件。
数据产品网关
所有与数据产品的交互——无论是消费者、发布者还是管理员——都通过轻量级的数据产品网关实现接口，如图4-5所示。该网关为与数据产品的所有交互提供了一致的实现。
数据产品网关是一个轻量级框架和代码，用于实现数据产品的各种接口。虽然每个数据产品都不同，并且具备独特的功能，但它们交互的机制和交互签名可以——并且应该——在很大程度上保持一致。
这对于数据摄取（概念上是/ingest接口）和数据消费（概念上是/consume接口）同样适用。虽然这些高流量接口可能只是简单的“直通”（基本不改变地传递请求），但它们的交互参数和机制可以标准化。
对于其他核心和基础接口（如发现接口/discover、可观测性接口/observe、控制或管理能力接口/control），这一做法更为实际。通过这种方式，所有与数据产品的交互变得一致和标准化，这意味着模板化和“工厂化”成为简化和加速数据产品创建和管理的现实考量。
由于所有请求都通过数据产品网关，因此它成为实现跨数据产品的共性问题（或带来益处）的载体，包括访问验证、日志记录、数据血缘、异常通知等功能。数据产品网关还成为数据契约和相关策略执行机制的集成点。数据契约在数据产品网关中设定了所有数据产品需要遵守的策略，并提供了一个一致的策略执行机制。契约定义了数据访问机制的结构和格式，以及安全性和隐私需求、数据质量和完整性要求、数据血缘和版本需求以及服务期望相关的任何需求。简单来说，它们定义了数据产品应满足的策略，甚至包括执行机制。
这大概只是勾起了你对数据契约威力的兴趣——鉴于数据契约在建立符合用户期望的数据网格中的重要性，我们专门用一整章（第5章）来解释数据契约的具体细节及其在数据产品中的实现。
数据摄取接口
将数据摄取到数据产品中是决定数据如何收集、处理并可用的一个基本过程。选择适当的数据摄取方法取决于多个因素，例如数据量、更新频率以及数据产品的具体需求。理解并选择正确的摄取方法对于确保数据产品的效率和效果至关重要。从API到批量摄取和数据管道，每种技术都有其优势和理想的应用场景。
查询是常见的数据摄取方法，特别适用于处理实时或准实时数据更新的情况。它们非常适合需要频繁、小量数据提取的场景。通过查询，可以根据特定条件选择和检索数据，这使其在针对性数据摄取中非常高效。这种方法特别适用于需要最新信息且能够处理频繁增量更新的数据产品。
API是另一种流行的数据摄取方法，尤其适用于较小数据集或需要从外部来源集成数据的场景。API提供了一种受控且安全的方式导入数据，允许访问和传输特定数据集。API在数据源和数据产品需要以标准化、统一方式通信时特别有效。API对于处理结构化数据、以及需要长期保持可扩展性和可维护性的集成也非常有用。
批量摄取方法（如文件传输）适用于需要将大量数据导入数据产品的场景。这种方法通常用于初始数据加载或定期更新，能一次性传输大量数据。批量摄取在资源使用和时间效率方面表现突出，尤其适用于不需要频繁更新的大型数据集。它常与数据仓库结合使用，或用于将历史数据集成到数据产品中。
数据管道，使用如Airflow或dbt（数据构建工具）之类的工具，专为更复杂的数据摄取场景设计。这些工具允许数据工作流自动化，从而以更受控、系统化的方式进行数据的摄取、转换和加载。数据管道特别适用于数据摄取过程包含多个步骤的情况，如数据清洗、转换或来自多个源的集成。它们为管理复杂数据流提供了一个强大的框架，确保数据摄取过程中的一致性和可靠性。
其他摄取方法包括流数据摄取（用于实时数据处理）和网络抓取（用于从网络来源提取数据）。流数据摄取特别适用于连续生成数据并需要实时处理的场景。
消费接口
显然，一旦数据被摄取到数据产品中，便需要让它易于消费。摄取关注的是数据如何进入数据产品，而消费则关注如何将数据以及DPO创建的其他工件提供给最终用户并使其有用。消费侧重于数据的输出和用户交互，而不是数据的输入。消费的方法与摄取方法类似，范围从查询和API到批量传输和数据管道。
查询、流数据和API是常见的数据消费方法，允许用户根据需求检索特定数据子集，或在发生数据事件时（例如，数据库中添加新行）通过流数据接收通知。这些方法提供了高度的灵活性，让用户在需要时精确提取所需数据。
批量消费方法（如文件传输）用于需要访问大量数据的情况，通常用于离线处理或分析。这种方法典型应用于需要整个数据集或其大部分的场景，如数据仓库或大数据分析。批量消费侧重于全面访问，而不是实时交互，适用于需要进行大规模数据处理的用例。
操作架构组件
在数据网格框架内，数据产品的操作考虑因素（如图4-6所示）涵盖了一系列接口和功能，以确保数据产品不仅具备功能性，还符合组织的总体操作标准和预期。这些考虑因素包括可发现性、可观测性、治理和控制接口。每个部分在数据产品的生命周期和实用性中都扮演着关键角色。
可发现性接口
可发现性接口（概念上为/discover端点，如图4-5所示）使得数据产品能够在数据网格中首先注册并随后被找到，确保数据产品对用户可见且可访问。
注册（概念上为/discover/registration端点）类似于在数字地图上放置一个标记，标识数据产品在数据网格中的位置和存在。注册至关重要，因为它确保数据产品不仅仅是一个独立实体，而是更大数据产品生态系统中的公认部分。注册过程中提供的信息通常包括数据产品和工件定义的元数据（命名空间、名称等）。
一旦注册，数据产品便可以在数据网格市场中被找到或“发现”（概念上为/discover/metadata端点）。注册过程中提供的元数据可以在数据网格市场中查看，使得数据产品及其工件更容易被发现、使用和共享。
可观测性接口
相对于相对稳定的数据产品元数据，数据产品的运行特性是不断变化的。可观测性接口（概念上为/observe端点，如图4-5所示）监控数据产品的持续运行特性。可观测性接口为数据产品的各个操作方面提供了全面的视图，包括使用统计、性能指标和总体运行状况。通过提供数据产品实时运行表现的洞察，可观测性接口允许数据产品所有者和用户监控并评估产品的有效性。
可观测性接口的一个重要优势是能够跟踪和报告使用模式，包括数据产品的访问频率、最常使用的部分以及使用者是谁。这些洞察对于理解用户行为和偏好极为宝贵，有助于在未来的产品增强或修改上做出明智决策。这种数据驱动的方法确保产品随着用户需求的变化不断发展，并保持相关性和实用性，同时还帮助进行资源分配和扩展决策，确保在需求波动时仍能保持最佳性能。
可观测性接口还关注性能和操作统计数据，包括加载时间、响应速率等简单指标，及数据吞吐量和处理效率等更复杂的指标。监控这些方面对于维持高质量的服务至关重要，并且可以预先识别潜在的瓶颈或性能问题。通过可观测性接口显示警报并提供日志，有助于问题诊断，快速有效地进行故障排除。这不仅减少了停机时间，还确保数据质量和准确性得以保持，这对于基于数据做出明智决策至关重要。
可观测性接口中暴露的血缘和来源跟踪提供了数据产品内部处理的可追溯性。这一功能详细说明了数据的来源及其历史变化，有助于保持数据的完整性和可信度，并确保数据收集、处理和转换的透明性。
治理接口
治理接口对于维持数据的完整性和合规性至关重要。这些接口旨在简化认证或验证流程，允许所有者声明其数据产品符合特定的数据质量、服务级别期望、法规合规性，甚至是数据血缘记录（其中许多可以在数据契约中定义）。
用户通常通过查看这些接口发起请求，要求查看数据产品的治理或认证状态，并收到一份报告或检查清单。以下是通常需要的一组接口（请注意，端点是概念性的，实际使用时会更详细）：
- /certify：获取数据产品的认证状态或报告。
- /certify/subscribe：请求在达到或未达到某个治理阈值时接收通知。
- /certify/publish：定期主动发布数据产品的治理或认证状态。
这些接口提供了数据管理实践和标准的透明性。通过提供清晰的治理实践洞察，数据产品所有者（DPO）可以增强用户的信心，确保数据按照最佳实践和法规要求进行管理。
控制接口
在数据产品的背景下，控制接口是关键工具，赋予DPO管理其产品运行状态的能力。这些接口涵盖了多种功能，包括启动或停止数据产品（概念上为/control/start或/control/stop接口）以及配置各种设置和参数（概念上为/control/configure接口）。
这种控制能力对于确保数据产品能够有效管理并灵活响应不同的操作需求或情境至关重要。控制接口本质上是DPO的指挥中心，赋予他们对产品的直接监督和管理能力。
此外，控制接口中的配置功能在根据特定需求或条件定制数据产品时发挥了重要作用。所有者可以调整设置以优化性能，根据用户反馈定制功能，或根据变化的数据环境动态调整。随着用户需求和技术环境的不断发展，能够快速配置和重新配置数据产品的能力确保了数据产品能够持续提供价值并满足用户的期望。
数据网格架构
如前所述，数据网格是由众多数据产品组成的生态系统，每个数据产品都是独立的单元，具有各自的目的和功能。然而，使数据网格真正强大的因素是将这些数据产品绑定为一个连贯且集成整体的组件。如图4-7所示，这些组件特别关注许多数据产品，甚至可能是所有数据产品所使用的功能和组件，包括数据网格市场、数据网格注册表以及数据网格骨干服务。它们是将所有组件连接成一个数据网格的“连接组织”。
数据网格市场和注册表
数据网格市场是一个用户界面，它简化了查找、使用、共享数据产品以及建立信任的过程。这个市场是数据网格的窗口，也是一个交互空间，使数据对消费者、生产者、治理专家和管理员更加可访问和可操作。
数据网格市场的密切关联是数据网格注册表，它是关于数据网格信息的存储库，类似于互联网中的DNS，起到“电话簿”的作用。在许多方面，注册表是市场的后端数据库，但它还维护了更多信息。
目前我们就简单介绍到这里。鉴于市场和注册表对数据网格的重要性，我们在第11章专门讨论了这些组件。
数据网格骨干服务
数据网格骨干服务将数据网格组件和数据产品集成为一个连贯的整体，提供必要的基础，使数据产品能够进行通信、交互并提供价值。
数据访问服务包括一组常用的工具和技术，用于联邦查询、数据管道和批量数据传输。这些服务使得可以在数据网格及其数据产品之间高效、灵活地访问数据，无论数据位于何处。例如，联邦查询功能允许用户在不移动数据的情况下从多个来源检索和组合数据，而数据管道和批量传输机制则在需要时提供高效移动大量数据的方式。
通信与交互服务是数据网格骨干服务的另一个关键方面。这些服务包括API（常见的有RESTful和GraphQL API）、流技术（如Kafka）和变更数据捕获机制（如Debezium）。它们促进不同数据产品之间的信息交互和交换，使其能够进行实时通信和数据共享。这种互联性对于创建一个动态、响应迅速的数据生态系统至关重要，在该系统中，数据可以在不同的数据产品（以及其他企业应用或外部系统）之间自由且安全地流动。
在数据网格结构的技术基础层是平台、基础设施和DevSecOps服务。平台包括各种数据管理解决方案，如数据库（例如PostgreSQL）、数据集市、数据仓库、数据湖和数据湖仓（如Snowflake和Databricks提供的解决方案）。
基础设施服务提供了计算、网络和存储能力的基础，构成支持几乎所有数据网格组件的核心平台。它们为数据处理、存储和编排提供了必要的资源，确保数据产品拥有足够的计算能力和空间，以有效运行。
DevSecOps（开发、安全和运营) 确保数据网格内的所有服务，从开发到部署再到生产环境中的管理，都以自动化、安全且可靠的方式进行。将DevSecOps应用于数据网格和数据产品，提供了加速数据产品开发和部署的流程和自动化工具。
Climate Quantum用例考虑
此时，我们已经了解了数据产品的架构，包括如何定义其数据和工件、摄取和消费能力以及核心操作接口。我们还看到了数据网格的组成组件，以及它如何将数据产品绑定到更广泛的生态系统中。
现在，让我们看看如何将这些部分组合成Climate Quantum的高层架构，作为我们的用例。回想一下，Climate Quantum的使命是通过数据产品和更广泛的数据网格生态系统，使气候数据易于查找、使用、共享和信任。Climate Quantum涉及许多气候数据领域；图4-8展示了Climate Quantum数据网格处理特定数据领域的快照。
Climate Quantum从原始气候数据源摄取数据，并创建几个不同的领域：
- 洪水数据领域
捕获原始气候数据（例如，来自气象站、传感器、测量仪和卫星图像），将其转化为更易用的形式（例如，识别非常大的卫星图像中可能受洪水影响的区域）。 - 物理风险领域
解答“我的哪些资产、建筑和人口中心受到气候变化的影响？”这一问题。 - 披露报告领域
满足向监管机构和利益相关者披露物理风险的需求。
每个数据产品都有一致的定义（命名空间、名称和之前提到的其他属性）。每个数据产品都可以通过轻量级的数据产品网关和已发布的API进行发现和观察。每个工件都以一致的方式定义（使用之前提到的工件属性），使得它们易于使用。所有这些处理都得益于多个核心数据网格架构组件的支持：
数据网格市场
所有数据产品及其工件都发布到数据网格市场，使用户和其他数据产品能够轻松查找和使用它们。
数据网格骨干服务
所有数据产品通过构建在多个通用产品（包括Airflow和dbt）上的管道进行交互，数据存储在数据平台中，并通过API平台提供的API进行访问。
希望你能看到，即使在气候数据这样复杂多样的数据环境中，数据网格也能使数据变得灵活。
总结
前几章描述了数据产品的基本要素。在本章中，我们讨论了构成数据网格的各种架构组件、其数据产品及数据产品的工件。
在下一章中，我们将详细介绍数据契约，然后应用这些架构来展示如何实施数据产品。
