在数据网格中构建数据产品

Last reviewed 2022-10-06 UTC

为了确保满足数据使用者的使用场景需要，必须谨慎设计和构建数据网格中的数据产品。数据产品的设计首先定义数据使用者如何使用该产品，以及如何向使用者公开该产品。数据网格中的数据产品是在数据存储区（例如，网域数据仓库或数据湖）基础之上构建的。在数据网格中创建数据产品时，我们建议您在这整个过程中考虑一些关键因素。本文档介绍了这些考虑因素。

本文档是系列文章中的一篇，该系列介绍了如何在 Google Cloud 上实现数据网格。本文档假定您已阅读并熟悉数据网格中的架构和职能以及使用 Google Cloud 构建现代分布式数据网格所述的概念。

本系列文章包含以下部分：

• 数据网格中的架构和职能
• 为数据网格设计自助式数据平台
• 在数据网格中构建数据产品（本文档）
• 在数据网格中发现和使用数据产品

从网域数据仓库创建数据产品时，建议数据提供方精心设计这些产品的分析（使用）接口。这些使用接口是一组关于数据质量和操作参数的保证，以及产品支持模型和产品文档。更改使用接口的成本通常较高，因为数据提供方和多个潜在数据使用者需要更改他们的使用进程和应用。倘若数据使用者很可能位于与数据提供方不同的组织单位中，因此协调更改可能很困难。

以下部分提供了有关在创建网域仓库、定义使用接口以及向数据使用者公开这些接口时必须考虑的背景信息。

创建网域数据仓库

构建独立数据仓库的操作与构建数据提供方团队用于创建数据产品的网域数据仓库的操作区别不大。两者之间唯一的实际区别在于后者通过使用接口公开其部分数据。

在许多数据仓库中，从运营数据源中提取的原始数据会经历丰富和数据质量验证（精选）过程。在 Dataplex 管理的数据湖中，经过挑选的数据通常存储在指定的精选区中。挑选完成后，一部分数据应通过多种类型的接口准备好供在网域外使用。为了定义这些使用接口，组织应该向采用数据网格方法的新手网域团队提供一组工具。这些工具可让数据提供方以自助方式创建新的数据产品。如需了解推荐的做法，请参阅设计自助式数据平台。

此外，数据产品必须满足集中定义的数据治理要求。这些要求会影响数据质量、数据可用性和生命周期管理。由于这些要求建立数据使用者对数据产品的信任并可促进数据产品使用，因此支持实现这些要求的优势十分值得。

定义使用接口

我们建议数据提供方使用多种类型的接口，而不是只定义一两个接口。数据分析中的每种接口类型都各有优缺点，没有任何一种接口可以面面俱到。数据提供方在评估每种接口类型的适用性时，必须考虑以下事项：

• 能够执行所需的数据处理。
• 可以扩展，能够支持当前和未来的数据使用者使用场景。
• 提供数据使用者所需的性能。
• 开发和维护的成本。
• 运行接口的成本。
• 您的组织所用语言和工具的支持。
• 支持存储和计算分离。

例如，如果业务需求是能够针对 PB 级数据集运行分析查询，则唯一实用的接口是 BigQuery 视图。但是，如果要求提供近乎实时的流式数据，则基于 Pub/Sub 的接口更合适。

这些接口中的许多接口都不需要复制现有数据。其中大多数接口还允许您分离存储和计算，这是 Google Cloud 分析工具的关键功能。通过这些接口公开的数据使用者使用可用的计算资源来处理数据。数据提供方无需执行任何额外的基础架构预配。

使用接口很多。下列接口是在数据网格中最常用的接口，接下来的部分将讨论这些接口：

• 授权视图和函数
• 直接读取 API
• 数据作为流
• 数据访问 API
• Looker 块
• 机器学习 (ML) 模型

本文档中的接口列表并不详尽。此外，您还可以考虑其他选择作为您的使用接口（例如，Analytics Hub）。但是，这些接口不在本文档的讨论范围内。

授权视图和函数

数据产品应尽可能通过授权视图和授权函数（包括表值函数）公开。授权数据集提供了一种自动为多个视图授权的简便方式。使用授权视图可阻止直接访问基表，并可让您优化底层表和针对它们的查询，而不会影响使用者使用这些视图。此接口的使用者使用 SQL 来查询数据。下图展示了将授权数据集用作使用接口的情况。

授权数据集和视图有助于轻松实现接口版本控制。如下图所示，数据提供方可以采用两种主要版本控制方法：

这些方法可以总结如下：

• 数据集版本控制：在这种方法中，您需要对数据集名称进行版本控制。您不不需要对数据集中的视图和函数进行版本控制。无论版本如何，您都将为视图和函数保留相同的名称。例如，销售数据集的第一个版本是在名为 sales_v1 的数据集中定义的，该数据集有两个视图：catalog 和 orders。在它的第二个版本，销售数据集已重命名为 sales_v2，并且数据集中的所有先前视图都保留其先前的名称，但具有新的架构。数据集的第二个版本也可能会添加新视图，或者移除先前的任何视图。
• 视图版本控制：在这种方法中，是对数据集内的视图进行版本控制，而不是对数据集本身进行版本控制。例如，无论版本如何，销售数据集都会保留 sales 这个名称。但是，数据集内的视图名称会更改，以反映视图的每个新版本（例如 catalog_v1、catalog_v2、orders_v1、orders_v2、orders_v3）。

最适合您的组织的版本控制方法取决于您的组织的政策以及随着底层数据的更新而过时的视图数。如果需要主要产品更新，并且大多数视图必须更改，则数据集版本控制非常合适。视图版本控制可使得不同数据集中的同名视图较少，但可能会导致不明确，例如，如何判断数据集之间的联接是否正常工作。混合方法可能是不错的折衷方案。在混合方法中，可以在单个数据集中使用兼容的架构更改，而不兼容的更改需要新的数据集。

BigLake 表考虑事项

授权视图不仅可以在 BigQuery 表上创建，也可以在 BigLake 表上创建。BigLake 表允许使用者使用 BigQuery SQL 接口查询 Cloud Storage 中存储的数据。BigLake 表支持精细的访问权限控制，而无需数据使用者拥有底层 Cloud Storage 存储桶的读取权限。

对于 BigLake 表，数据提供方必须考虑以下内容：

• 文件格式和数据布局的设计会影响查询性能。与 JSON 或 CSV 格式相比，基于列的格式（例如 Parquet 或 ORC）通常更适合分析查询。
• 借助 Hive 分区布局，您可以删减分区并加快使用分区列的查询的速度。
• 在设计阶段，还必须考虑文件数量和文件大小的首选查询性能。

如果使用 BigLake 表的查询不符合接口的服务等级协议 (SLA) 要求并且无法调整，则建议您执行以下操作：

• 对于必须向数据使用者公开的数据，请将该数据转换为 BigQuery 存储空间。
• 重新定义授权视图以使用 BigQuery 表。

通常，此方法不会导致数据使用者中断，也不需要对其查询进行任何更改。BigQuery 存储空间中的查询可以使用一些技术进行优化，这是 BigLake 表无法实现的。例如，借助 BigQuery 存储空间，使用者可以查询与基表不同的分区和聚簇的具体化视图，并且可以使用 BigQuery BI Engine。

直接读取 API

虽然我们通常不建议数据提供方为数据使用者提供对基表的直接读取权限，但有时出于性能和费用等原因，需要允许此类访问。在这些情况下，应特别注意确保表架构的稳定。

您可以通过以下两种方式直接访问典型仓库中的数据。数据提供方可以使用 BigQuery Storage Read API 或 Cloud Storage JSON 或 XML API。下图展示了使用这些 API 的两个使用者示例。一个是机器学习 (ML) 使用场景，另一个是数据处理作业。

对直接读取接口进行版本控制非常复杂。通常，数据提供方必须创建另一个具有不同架构的表。它们还必须维护表的两个版本，直到弃用版本的所有数据使用者迁移到新版本。如果使用者可以容忍重新构建表中断并切换到新架构，则可以避免数据重复。如果架构更改可以向后兼容，则可以避免迁移基表。例如，如果只是添加新列，并且这些列中的数据针对所有行进行回填，则不必迁移基表。

下面总结了 Storage Read API 与 Cloud Storage API 之间的差异。一般来说，我们建议数据提供方尽可能将 BigQuery API 用于分析应用。

• Storage Read API：Storage Read API 可用于读取 BigQuery 表中的数据以及读取 BigLake 表。此 API 支持过滤和精细的访问权限控制，可以用作稳定的数据分析或机器学习使用者的理想选项。

• Cloud Storage API：数据提供方可能需要直接与数据使用者共享特定 Cloud Storage 存储桶。例如，如果数据使用者由于某种原因而无法使用 SQL 接口，或者存储桶具有不受 Storage Read API 支持的数据格式，则数据提供方可以共享存储桶。

一般来说，我们不建议数据提供方允许通过 Storage API 直接访问，因为直接访问不允许过滤和精细的访问权限控制。但是，直接访问方法可能是稳定、小型（千兆字节）数据集的可行选择。

如果允许 Pub/Sub 访问此存储桶后，数据使用者就可以轻松将数据复制到其项目中并在其中处理数据。一般来说，我们建议尽量避免复制数据。多次复制数据会增加存储费用，并且会增加维护和沿袭跟踪开销。

数据作为流

网域可以通过将数据发布到 Pub/Sub 主题来公开数据。想要使用这些数据的订阅者会创建订阅，以使用发布到该主题的消息。每个订阅者都会独立接收并使用数据。下图展示了此类数据流的示例。

在该图中，提取流水线会读取原始事件，丰富（挑选）这些事件，并将这些经过挑选的数据保存到分析数据存储区（BigQuery 基表）。同时，流水线会将经过丰富处理的事件发布到专门的主题。此主题由多个订阅者使用，每个订阅者可能会过滤这些事件，以仅获取与其相关的事件。该流水线还会将事件统计信息聚合并发布到它自己的主题，以供其他数据使用者处理。

下面是 Pub/Sub 订阅的示例使用场景：

• 经过丰富处理的事件，例如提供完整的消费者个人资料信息以及特定消费者订单的数据。
• 近乎实时的聚合通知，例如过去 15 分钟的总订单统计信息。
• 业务级提醒，例如在订单数量与前一天的类似时间段相比下降 20% 时生成提醒。
• 数据变更通知（类似于变更数据捕获通知的概念），例如特定订单变更状态。

数据提供方用于 Pub/Sub 消息的数据格式会影响费用以及这些消息的处理方式。对于数据网格架构中的大量流，可以选择 Avro 或 Protobuf 格式。如果数据提供方使用这些格式，就可为 Pub/Sub 主题分配架构。这些架构有助于确保使用者收到格式正确的消息。

因为流式数据结构会不断变化，所以此接口的版本控制需要协调数据提供方和数据使用者。数据提供方可以使用多种常见方法，如下所示：

• 每次消息结构发生变化时，系统都会创建一个新主题。此主题通常具有显式 Pub/Sub 架构。需要新接口的数据使用者可以开始使用新数据。消息版本隐含在主题名称中，例如 click_events_v1。消息格式经过强类型化。同一主题中的消息之间的消息格式没有变化。这种方法的缺点是，可能存在数据使用者无法切换到新订阅的情况。在这种情况下，数据提供方必须在一段时间内继续向所有活跃的主题发布事件，并且订阅该主题的数据使用者必须处理消息流中的缺口或删除重复的消息。
• 数据始终发布到同一主题。但是，消息的结构可能会发生变化。Pub/Sub 消息特性（与载荷分开）定义消息的版本。例如 v=1.0。这种方法无需处理缺口或重复的情况：但是，所有数据使用者都必须准备好接收新类型的消息。数据提供方也无法将 Pub/Sub 主题架构用于此方法。
• 混合方法。消息架构可以包含可用于新字段的任意数据部分。这种方法可以在具有强类型化数据以及频繁和复杂的版本更改之间提供合理的平衡。

数据访问 API

数据提供方可以构建自定义 API 以直接访问数据仓库中的基表。这些提供方通常会将此自定义 API 公开为 REST 或 gRPC API，并在 Cloud Run 或 Kubernetes 集群上部署。Apigee 等 API 网关可以提供其他附加功能，例如流量限制或缓存层。在向 Google Cloud 组织外部的使用者公开数据访问 API 时，这些功能非常有用。数据访问 API 的潜在候选项是延迟敏感型查询和高并发查询，它们都会在单个 API 中返回相对较小的结果，并且可有效地缓存。

此类用于数据访问的自定义 API 的示例如下所示：

• 表或产品的 SLA 指标的组合视图。
• 来自特定表的前 10 个（可能缓存的）记录。
• 表统计信息数据集（总行数，或键列中的数据分布）。

组织有关构建应用 API 的任何准则和治理也适用于数据提供方创建的自定义 API。组织的准则和治理应涵盖托管、监控、访问权限控制和版本控制等问题。

自定义 API 的缺点是，数据提供方负责托管此接口所需的任何其他基础架构，以及自定义 API 编码和维护。我们建议数据提供方在决定创建自定义数据访问 API 之前调查其他选项。例如，数据提供方可以使用 BigQuery BI Engine 来缩短响应延迟时间并提高并发性。

Looker 块

对于在商业智能 (BI) 工具中大量使用的产品（如 Looker），维护一组特定于 BI 工具的微件可能很有用。因为数据提供方团队知道网域中使用的底层数据模型，所以该团队最适合创建和维护一组预先构建的可视化。

对于 Looker，此可视化可以是 Looker 块（预构建的 LookML 数据模型）。Looker 块可以轻松集成到使用者托管的信息中心中。

机器学习模型

因为在数据领域工作的团队对其数据了如指掌，所以他们通常最适合构建和维护基于网域数据训练的机器学习模型。这些机器学习模型可以通过多个不同的接口公开，包括以下接口：

• BigQuery ML 模型可以在专用的数据集中部署，并与数据使用者共享以进行 BigQuery 批量预测。
• BigQuery ML 模型可以导出到 Vertex AI 中以用于在线预测。

使用接口的数据位置考虑事项

当数据提供方为数据产品定义使用接口时，一个重要的考虑因素是数据位置。一般来说，为了最大限度地降低费用，应在存储数据的同一区域中对其进行处理。此方法有助于防止跨区域数据出站流量费用。此方法的数据延迟时间最短。出于这些原因，存储在多区域 BigQuery 位置的数据通常最适合作为数据产品公开。

但是，考虑到性能原因，存储在 Cloud Storage 中并通过 BigLake 表或直接读取 API 公开的数据应存储在区域级存储桶中。

如果一个产品中公开的数据位于一个区域中，并且需要与另一个区域中另一个网域中的数据联接，则数据使用者必须考虑以下限制：

• 不支持使用 BigQuery SQL 的跨区域查询。如果数据的主要使用方法是 BigQuery SQL，则查询中的所有表必须位于同一位置。
• BigQuery 固定费率承诺是区域性的。如果某个项目仅在一个区域中使用固定费率承诺，但在另一个区域中查询数据产品，则按需价格适用。
• 数据使用者可以使用直接读取 API 从其他区域中读取数据。但是，跨区域网络出站流量费用适用，并且对于大型数据传输，数据使用者很可能会遇到延迟。

可将经常跨区域访问的数据复制到这些区域，以降低给产品使用者带来的费用和延迟。例如，BigQuery 可以复制数据集到其他区域。但是，请仅在需要时复制数据。在复制数据时，建议数据提供方仅将一部分可用的产品数据的提供给多个区域。此方法有助于最大限度地缩短复制延迟并降低费用。此方法可能会导致需要提供多个版本的使用接口以及明确指明数据位置区域。例如，BigQuery 授权视图可以通过命名（如 sales_eu_v1 和 sales_us_v1）公开。

使用 Pub/Sub 主题的数据流接口无需任何额外的复制逻辑即可使用与消息存储区域不同的区域中的消息。但是，在这种情况下，需要支付额外的跨区域出站流量费用。

向数据使用者公开使用接口

本部分介绍如何让潜在使用者发现使用接口。Data Catalog 是一项全托管式服务，组织可以使用它来提供数据发现和元数据管理服务。数据提供方必须使其数据产品的使用接口可搜索，并使用适当的元数据对接口进行注释，使得产品使用者能够以自助方式访问它们。我们

以下部分讨论如何将每种接口类型定义为 Data Catalog 条目。

基于 BigQuery 的 SQL 接口

系统会自动为通过 Storage Read API 提供的授权视图、BigLake 视图和 BigQuery 表注册技术元数据（如完全限定表名称或表架构）。我们建议数据提供方同时在数据产品文档中提供更多信息，以帮助数据使用者。例如，为了帮助用户查找产品文档以了解某个条目，数据提供方可以将网址添加到已应用于该条目的某个标记。提供方还可以提供以下内容：

• 聚簇列集，应在查询过滤条件中使用。
• 具有逻辑枚举类型的字段的枚举值（如果未在字段说明中提供类型）。
• 支持与其他表联接。

数据流

Pub/Sub 主题会自动向 Data Catalog 注册。但是，数据提供方必须在数据产品文档中描述架构。

Cloud Storage API

Data Catalog 支持 Cloud Storage 文件条目及其架构的定义。如果数据湖文件集由 Dataplex 管理，则该文件集会自动在 Data Catalog 中注册。不与 Dataplex 关联的文件集通过其他方法添加。

其他接口

您可以通过创建自定义条目来添加在 Data Catalog 中没有内置支持的其他接口。

后续步骤

• 查看数据网格架构的参考实现。
• 详细了解 BigQuery。
• 了解 Dataplex。
• 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。