在数据网格中，自助式数据平台使用户能够自主构建、共享和使用数据产品，从而从数据中挖掘价值。为了充分实现这些优势，我们建议自助式数据平台提供本文档中所述的功能。
本文档是系列文章中的一篇，该系列介绍了如何在 Google Cloud 上实现数据网格。本文档假定您已阅读并熟悉使用 Google Cloud 构建现代化分布式数据网格以及数据网格中的架构和职能所述的概念。
本系列文章包含以下部分：
- 数据网格中的架构和职能
- 为数据网格设计自助式数据平台（本文档）
- 在数据网格中构建数据产品
- 在数据网格中发现和使用数据产品
数据平台团队通常创建中央自助式数据平台，如本文档中所述。该团队构建网域团队（数据提供方和数据使用方）可用于创建和使用数据产品的解决方案和组件。领域团队代表数据网格的功能部分。通过构建这些组件，数据平台团队可以实现流畅的开发体验，并降低构建、部署和维护既安全又可以互操作的数据产品的复杂性。
最终，数据平台团队应支持网域团队加快行动速度。他们为网域团队提供一组有限的工具（用于满足其需求），帮助其提高效率。通过提供这些工具，数据平台团队可消除让网域团队自行构建和获取这些工具的负担。工具选项应该可以自定义以满足不同的需要，并且不会强制数据网域团队采用不灵活的工作方式。
数据平台团队不应专注于为数据流水线编排器或持续集成和持续交付 (CI/CD) 系统构建自定义解决方案。CI/CD 系统等解决方案可作为托管式云服务（例如 Cloud Build）轻松获取。使用托管式云服务可以降低数据平台团队的运营开销，让他们能够专注于满足作为平台用户的数据领域团队的特定需求。减少运营开销后，数据平台团队可以腾出更多时间来满足数据网域团队的特定需求。
架构
下图展示了自助式数据平台的架构组件。该图还显示了这些组件如何在团队开发和使用数据网格中的数据产品时为其提供支持。
如上图所示，自助式数据平台提供以下功能：
平台解决方案：这些解决方案由可组合的组件组成，用于预配 Google Cloud 项目和资源，用户可以以不同的组合来选择和组合这些项目和资源以满足其特定要求。平台用户可以与平台解决方案交互，以帮助他们实现特定目标，而不是直接与组件交互。数据网域团队应设计平台解决方案来解决导致数据产品开发和消耗减慢的常见痛点和摩擦区域。例如，刚开始使用数据网格的数据领域团队可以使用基础架构即代码 (IaC) 模板。借助 IaC 模板，该团队可以快速创建一组具有标准 Identity and Access Management (IAM) 权限、网络、安全政策以及为数据产品开发而启用的相关 Google Cloud API 的 Google Cloud 项目。我们建议每个解决方案都随附文档，例如“使用入门”指导和代码示例。数据平台解决方案及其组件必须默认处于安全和合规状态。
通用服务：这些服务提供数据产品的可检测性、管理、共享和可观测性。这些服务有助于数据使用方信任数据产品，并且是数据提供方向数据使用方提醒其数据产品问题的有效方式。
数据平台解决方案和通用服务可能包括以下各项：
- IaC 模板，用于设置基础数据产品开发工作区环境，其中包括：
- IAM
- 日志记录和监控
- 网络
- 安全和合规性护栏
- 用于结算归因的资源标记
- 数据产品存储、转换和发布
- 数据产品注册、编目和元数据标记
- IaC 模板，遵循组织安全保护措施和最佳实践，可用于将 Google Cloud 资源部署到现有数据产品开发工作区。
- 应用和数据流水线模板，可用于引导新项目或用作现有项目的参考模板。此类模板的示例包括：
- 常用库和框架的使用
- 与平台日志记录、监控和可观测性工具集成
- 构建和测试工具
- 配置管理
- 用于部署的打包和 CI/CD 流水线
- 凭据的身份验证、部署和管理
- 提供数据产品可观测性和治理的通用服务，其中可能包括以下各项：
- 拨测，用于显示数据产品的整体状态。
- 自定义指标，用于提供有关数据产品的有用指标。
- 中央团队的运营支持，以便数据使用方团队收到有关其使用的数据产品的变化提醒。
- 产品统计信息摘要图表，用于展示数据产品的性能。
- 用于发现数据产品的元数据目录。
- 一组集中定义的计算政策，可在整个数据网格中全局应用。
- 一个数据市场，用于促进网域团队之间的数据共享。
使用 IaC 模板创建平台组件和解决方案介绍了 IaC 模板公开和部署数据产品的优势。提供通用服务介绍了为网域团队提供由数据平台团队构建和管理的常见基础架构组件很有帮助的原因。
使用 IaC 模板创建平台组件和解决方案
数据平台团队的目标是设置自助式数据平台，以便从数据中挖掘更多价值。为了构建这些平台，他们需要为网域团队提供经过审核、安全、自助式的基础架构模板。领域团队使用这些模板来部署其数据开发和数据使用环境。IaC 模板可帮助数据平台团队实现该目标并扩大规模。使用经过审核的可信 IaC 模板可让网域团队重复使用现有的 CI/CD 流水线，从而简化网域团队的资源部署流程。这种方法让领域团队能够快速上手，并在数据网格中高效工作。
您可以使用 IaC 工具创建 IaC 模板。虽然有多个 IaC 工具（包括 Cloud Config Connector、Pulumi、Chef 和 Ansible，但本文档仅为基于 Terraform的 IaC 工具提供了示例。Terraform 是一个开源 IaC 工具，可让数据平台团队高效地为 Google Cloud 资源创建可组合使用的平台组件和解决方案。使用 Terraform，数据平台团队可以编写代码以指定所选择的最终状态，并让该工具确定如何实现该状态。通过此声明式方法，数据平台团队能够将基础架构资源视为跨环境进行部署的不可变工件。还有助于降低已部署的资源与源代码控制中声明的代码之间出现不一致的风险（称为配置偏移）。对基础设施的临时和手动更改导致的配置偏移会阻碍 IaC 组件安全且可重复地部署到生产环境。
可组合平台组件的通用 IaC 模板包括使用 Terraform 模块来部署 BigQuery 数据集、Cloud Storage 存储桶或 Cloud SQL 数据库等资源。Terraform 模块可以合并为端到端解决方案，以部署完整的 Google Cloud 项目，包括使用可组合的模块部署的相关资源。如需查看 Terraform 模块示例，请参阅适用于 Google Cloud 的 Terraform 蓝图。
默认情况下，每个 Terraform 模块都应符合您的组织使用的安全保护措施和合规性政策。这些保护措施和政策也可以表示为代码，并且可使用自动化合规性验证工具（例如 Google Cloud 政策验证工具）自动执行。
您的组织应使用与促进生产变更相同的自动化合规保护措施来持续测试平台提供的 Terraform 模块。
要使 IaC 组件和解决方案可供对 Terraform 有最低经验的网域团队发现和使用，我们建议您使用 Service Catalog 等服务。具有重要自定义要求的用户应能够根据现有解决方案使用的相同可组合 Terraform 模板，创建自己的部署解决方案。
使用 Terraform 时，我们建议您遵循使用 Terraform 的最佳实践中所述的 Google Cloud 最佳实践。
为了演示如何通过 Terraform 创建平台组件，以下部分讨论了如何通过 Terraform 公开使用界面和使用数据产品的示例。
公开使用界面
数据产品的使用界面是数据网域团队为使其他团队能够发现和使用其数据产品提供的一套数据质量和运营参数保证措施。每个使用界面还包括产品支持模型和产品文档。数据产品可能具有不同类型的使用界面，例如 API 或数据流，如在数据网格中构建数据产品中所述。最常见的使用界面可能是 BigQuery 授权数据集、授权视图或授权函数。此界面公开一个只读虚拟表（表示为数据网格中的查询）。该界面不会授予读取者直接访问底层数据的权限。
Google 提供了一个用于创建授权视图的示例 Terraform 模块，而无需向团队授予对底层授权数据集的权限。此 Terraform 模块的以下代码授予 dataset_id 授权视图的这些 IAM 权限：
module "add_authorization" {
source = "terraform-google-modules/bigquery/google//modules/authorization"
version = "~> 4.1"
dataset_id = module.dataset.bigquery_dataset.dataset_id
project_id = module.dataset.bigquery_dataset.project
roles = [
{
role = "roles/bigquery.dataEditor"
group_by_email = "ops@mycompany.com"
}
]
authorized_views = [
{
project_id = "view_project"
dataset_id = "view_dataset"
table_id = "view_id"
}
]
authorized_datasets = [
{
project_id = "auth_dataset_project"
dataset_id = "auth_dataset"
}
]
}
如果您需要向用户授予对多个视图的访问权限，则授予对每个授权视图的访问权限可能非常耗时且更难维护。您可以使用已获授权的数据集自动授权在已获授权的数据集中创建的任何视图，而不是创建多个已获授权的视图。
使用数据产品
对于大多数分析使用场景，使用模式由使用数据的应用决定。集中提供的使用环境的主要用途是在使用应用中使用数据之前进行数据探索。如发现和使用数据网格中的数据产品中所述，SQL 是查询数据产品最常用的方法。因此，数据平台应该为数据使用方提供 SQL 应用来探索数据。
根据分析应用场景，您可以使用 Terraform 为数据使用方部署使用环境。例如，数据科学是数据使用方的常见应用场景。您可以使用 Terraform 部署 Vertex AI 用户管理的笔记本，以用作数据科学开发环境。从数据科学笔记本中，数据使用方可以使用其凭据登录数据网格，以探索自己有权访问的数据，并根据这些数据开发机器学习模型。
如需了解如何使用 Terraform 在 Google Cloud 上部署和帮助保护笔记本环境，请参阅在企业中构建和部署生成式 AI 和机器学习模型。
提供通用服务
除了自助式 IaC 组件和解决方案之外，数据平台团队还可能负责构建和运营多个数据网域团队使用的通用共享平台服务。共享平台服务的常见示例包括自托管的第三方软件，例如商业智能可视化工具或 Kafka 集群。在 Google Cloud 中，数据平台团队可能会选择代表数据领域团队管理 Dataplex 和 Cloud Logging 接收器等资源。通过为数据网域团队管理资源，数据平台团队可以在整个组织内推动集中政策管理和审核。
以下部分介绍了如何使用 Dataplex 在 Google Cloud 上的数据网格内进行集中管理和治理，以及在数据网格中实现数据可观测性功能。
用于数据治理的 Dataplex
Dataplex 提供了一个数据管理平台，可帮助您在跨组织的数据网格内构建独立的数据网域。Dataplex 允许您维护中央控制以跨网域管理和监控数据。
使用 Dataplex，组织可以在逻辑上将其数据（支持的数据源）和相关工件（如代码、笔记本和日志）组织到表示数据网域的 Dataplex 湖。在下图中，销售网域使用 Dataplex 将其资产（包括数据质量指标和日志）组织到 Dataplex 区域中。
如上图所示，Dataplex 可用于管理以下资产中的网域数据：
- Dataplex 允许数据网域团队一致地在名为 Dataplex 湖的逻辑组中管理其数据资源。数据网域团队可以将其 Dataplex 资产组织到同一 Dataplex 数据湖内，而无需以物理方式移动数据或将其存储在单个存储系统中。Dataplex 资产可以引用存储在多个 Google Cloud 项目（包含 Dataplex 湖的 Google Cloud 项目除外）中的 Cloud Storage 存储桶和 BigQuery 数据集。 Dataplex 资产可以是结构化资产，也可以是非结构化资产，或者可以存储在分析数据湖或数据仓库中。在该图中，有销售领域、供应链领域和产品领域的数据湖。
- 借助 Dataplex 区域，数据网域团队可以进一步将数据资源组织到同一 Dataplex 湖内的较小子组中，并添加用于捕获子组关键方面的结构。例如，Dataplex 区域可用于对数据产品中的关联数据资源进行分组。通过将数据资源分组到单个 Dataplex 区域，数据网域团队能够以单一数据产品的形式跨区域一致地管理访问权限政策和数据治理政策。在该图中，有离线销售、在线销售、供应链仓库和产品的数据区域。
借助 Dataplex 湖和区域，组织可以统一分布式数据并根据业务上下文对其进行整理。此安排构成了管理元数据、设置治理政策和监控数据质量等活动的基础。通过此类活动，组织可以大规模管理分布式数据，例如在数据网格中。
数据可观测性
每个数据网域都应实施自己的监控和提醒机制，最好采用标准化方法。每个网域都可以应用服务监控中的概念所述的监控实践，从而对数据网域进行必要的调整。可观测性是一个很大的主题，不在本文档的讨论范围内。本部分仅介绍了数据网格实现中有用的模式。
对于具有多个数据使用方的产品，向每个使用方及时提供有关产品状态的信息可能会成为运营负担。基本解决方案（例如手动管理的电子邮件分发）通常容易出错。它们对于通知使用方计划内服务中断、即将进行的产品发布和弃用很有帮助，但不会提供实时运营认知度。
中央服务在监控数据网格中产品的健康状况和质量方面发挥着重要作用。虽然不是成功实现数据网格的前提条件，但实现可观测性功能可以提高数据生产方和使用方的满意度，并降低总体运营和支持费用。下图展示了基于 Cloud Monitoring 的数据网格可观测性架构。
以下部分介绍了图中所示的组件，如下所示：
- 拨测，用于显示数据产品的整体状态。
- 自定义指标，用于提供有关数据产品的有用指标。
- 由中央数据平台团队提供的运营支持，以便数据使用方收到有关其使用的数据产品的变化提醒。
- 产品统计信息摘要和信息中心，用于显示数据产品的性能。
拨测
数据产品可以创建实现拨测的简单自定义应用。这些拨测可以作为产品整体状态的简要指标。例如，如果数据产品团队发现其产品的数据质量突然下降，则可以将该产品标记为健康状况不佳。接近实时的拨测对于衍生产品的数据使用方尤其重要，这些产品依赖于上游数据产品中数据的持续可用性。数据提供方应构建其拨测，以便检查其上游依赖项，从而准确地向数据使用方提供其产品的运行状况。
数据使用方可以在其处理过程中添加产品拨测。例如，根据数据产品提供的数据生成报告的 Composer 作业可以先验证该产品是否处于“运行”状态。我们建议您的拨测应用在其 HTTP 响应的消息正文中返回一个结构化载荷。此结构化载荷应指示是否存在问题、人类可读形式的问题的根本原因，以及可能的恢复服务估计时间。此结构化载荷还可以提供有关产品状态的更精细信息。例如，可以包含已获授权数据集中公开为产品的每个视图的健康状况信息。
自定义指标
数据产品可以有各种自定义指标来衡量其实用性。数据提供方团队可以将这些自定义指标发布到指定的网域专用 Google Cloud 项目。为了在所有数据产品中创建统一监控体验，您可以为中央数据网格监控项目提供对这些网域专用项目的访问权限。
每种类型的数据产品使用界面都有不同的指标来衡量其实用性。指标还可以特定于业务网域。例如，通过视图或 Storage Read API 公开的 BigQuery 表的指标可以如下所示：
- 行数。
- 数据新鲜度（以测量时间前的秒数表示）。
- 数据质量得分。
- 可用的数据。此指标可以指示数据可用于查询。另一种方法是使用本文档前面提到的拨测。
这些指标可视为特定产品的服务等级指标 (SLI)。
对于数据流（以 Pub/Sub 主题的形式实现），此列表可以是通过主题提供的标准 Pub/Sub 指标。
由中央数据平台团队提供的运营支持
中央数据平台团队可以公开自定义信息中心，向数据使用方显示不同级别的详细信息。通过简单的状态信息中心列出产品在数据网格中的产品和正常运行时间状态，有助于回答多个最终用户请求。
中央团队还可以充当通知分发中心，以通知数据使用方他们使用的数据产品中的各种事件。通常，此中心是通过创建提醒政策建立的。集中管理此功能可以减少每个数据提供方团队必须完成的工作。创建这些政策不需要了解数据网域，并且应该避免数据使用中的瓶颈。
数据网格监控的理想结束状态是数据产品标记模板公开产品在产品可用时支持的 SLI 和服务等级目标 (SLO)。然后，中央团队可以结合使用服务监控和 Monitoring API 自动部署相应的提醒。
产品统计信息摘要图表
作为中央治理协议的一部分，数据网格中的四个功能可以定义为数据产品创建统计信息摘要图表的标准。这些统计信息摘要图表可以成为数据产品性能的目标衡量指标。
用于计算统计信息摘要图表的许多变量是数据产品满足其 SLO 的时间百分比。有用的标准可以是正常运行时间百分比、平均数据质量得分以及数据新鲜度不低于阈值的产品百分比。如需使用 Monitoring Query Language (MQL) 自动计算这些指标，自定义指标和来自中央监控项目的拨测结果应该就足够了。
后续步骤
- 详细了解 BigQuery。
- 了解 Dataplex。
- 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。