智能体 AI 用例：构建无边界的开放式数据湖仓一体平台

Last reviewed 2026-04-22 UTC

本文档提供了一个高级架构，用于构建无边界开放式数据湖仓一体，该架构可建立从原始无边界数据孤岛直接到 AI 驱动型行动的高度受监管的安全流水线。该简报介绍了如何统一 Google Cloud、其他云服务提供商和实时运营数据库中分散的企业数据，而无需依赖可能会复制数据的脆弱提取、转换和加载 (ETL) 流水线。

本文档的目标受众群体包括需要设计使用开放标准的高性能联邦系统的数据工程师、数据架构师和 AI 开发者。目标受众群体可能还需要应对企业限制，例如无边界网络路由以及严格的身份和访问管理隔离。

本文档的部署部分提供了一个代码示例，可帮助您构建和部署本文档中所述的架构。

架构

下图展示了在 Google Cloud中使用中央数据湖仓的无边界架构。

一种架构，显示了 Google Cloud中具有中央数据湖仓的无边界架构。

上图中的架构包含两个子系统：数据提取和部署。

  • 数据注入子系统从外部来源注入数据。它使用中央湖仓一体架构来统一处理分散的数据库，从而在 Google Cloud中形成统一的客户资料。
  • 借助服务子系统，用户可以查询 AI 助理和数据分析代理，以分析整合的数据。

以下部分介绍了各个子系统的组件。

数据注入子系统

数据注入子系统包含以下组件：

Managed Service for Apache Spark 搭配 Lightning Engine

一项服务，提供可处理复杂分析工作负载（例如大规模无边界数据联接和转换）的分布式处理引擎。为了最大限度地提高计算效率，Managed Service for Apache Spark 使用 Lightning Engine 来处理大规模多路联接、复杂的窗口化和行为聚合，这些都是合并无边界数据源所必需的。

Managed Service for Apache Spark 使用 Lightning Engine 通过从以下路径提取数据来执行分布式联接：

  • 来自 Amazon S3 的 Parquet 文件。
  • Cloud Storage 事件日志。
  • 通过 BigQuery 连接 获取 AlloyDB for PostgreSQL 中的实时事务数据。
外部数据源

位于其他云环境中的企业数据资产。在本文档介绍的架构中，外部数据源如下：

连接到外部数据源后，您就可以直接分析数据，而无需进行耗时且成本高昂的数据迁移。虽然此架构示例使用 Databricks Unity Catalog 和 Amazon S3 存储分区，但您可以将此架构模式与其他外部 Iceberg Catalog 服务和云存储服务提供商搭配使用。

AlloyDB
一种高性能数据库，用于混合事务和分析处理 (HTAP)，例如在管理实时库存或实时客户资料时。借助 BigQuery AlloyDB 联合，分析引擎可以直接从 BigQuery 向存储在 AlloyDB 中的实时事务数据发送查询。这种方法消除了与变更数据捕获 (CDC) 流水线相关的延迟和开销。
Cloud Storage
一种可伸缩的对象存储服务，适用于高吞吐量数据，例如点击流事件。为确保各种处理引擎都能访问数据，请使用 Cloud Storage 将数据与特定计算服务分离，并以开放的 Apache Iceberg 格式（例如 Apache Parquet）存储数据。
Borderless Lakehouse

可实现统一的无边界联盟的中央元数据和治理系统。为了建立与 Lakehouse 元数据的连接，Lakehouse 会执行以下操作：

  1. 连接到 Databricks Unity Catalog 以解析无边界数据的架构和路由信息。
  2. 向 Secret Manager 发送请求以验证凭据。
    • 如果凭据获得批准，则建立与 Lakehouse 元数据的直接连接。
    • 如果凭据被拒绝，则返回错误消息并中止操作。
Cloud NAT 和 Cloud Router
可让 Google Cloud网络中的资源安全地访问外部云来源的数据，而无需将这些资源暴露在公共互联网上。
Virtual Private Cloud (VPC)
一项服务，可为作为此架构一部分部署的所有 Google Cloud 资源提供私密、安全且隔离的网络。
Secret Manager
一种安全存储 Databricks 服务正文凭据（例如客户端 ID 和密钥）的服务，用于实现无边界身份验证。

服务子系统

服务子系统包含以下组件：

统一的客户资料
一个 BigQuery 数据库，用于整合分布式 Spark 作业的输出。BigQuery 表会将碎片化的无边界指标转换为复杂的非规范化数据类型，并充当用于分析的中央受监管数据存储区。
BigQuery 数据代理
一种对话式分析代理，可让用户直接在 BigQuery 中查询数据并生成企业数据洞见。代理会针对查询强制执行安全和治理防护措施。
BigQuery MCP 服务器
由 Google 管理的 Model Context Protocol (MCP) 服务器，可提供对 BigQuery 数据的访问权限。BigQuery MCP 服务器可安全地向本地或外部 AI 模型（例如 Gemini CLI）公开受治理的数据湖仓上下文。它支持端到端的智能体工作流，而无需 AI 工程师构建和维护自定义 REST API 中间件。
Gemini CLI
一款命令行 AI 助理，可让用户与统一的客户资料互动，生成个性化、数据驱动的内容，例如个性化营销活动。Gemini CLI 充当 BigQuery MCP 服务器的客户端，用于访问存储在统一客户资料中的数据。

使用的产品

此示例架构使用以下 Google Cloud 产品和工具：

  • Lakehouse：一种高性能存储引擎，可让您构建开放式数据湖仓一体架构，并为高级分析和 AI 提供统一的接口。
  • BigQuery：一种企业数据仓库，可帮助您使用机器学习、地理空间分析和商业智能等内置功能管理和分析数据。
  • AlloyDB for PostgreSQL：与 PostgreSQL 兼容的全托管式数据库服务，专为要求苛刻的工作负载（包括混合事务和分析处理）而设计。
  • Managed Service for Apache Spark：一项代管式服务，可在托管计算基础设施上运行 Apache Spark 批量工作负载。
  • Cloud Storage：适用于各种数据类型的费用低廉且不受限制的对象存储。数据可从 Google Cloud内部和外部访问，并且跨位置进行复制以实现冗余。
  • Gemini：Google 开发的一系列多模态 AI 模型。
  • Google Cloud MCP 服务器：由 Google 管理的远程服务，用于实现 Model Context Protocol (MCP)，以便为 AI 应用提供对 Google 和 Google Cloud 产品和服务的访问权限。
  • Cloud NAT：一种提供 Google Cloud管理的高性能网络地址转换的服务。
  • Cloud Router：一项分布式全托管式服务，可提供边界网关协议 (BGP) 发言者和响应者功能。Cloud Router 可与 Cloud Interconnect、Cloud VPN 和路由器设备配合使用，根据 BGP 收到的路由和自定义已知路由在 VPC 网络中创建动态路由。
  • Virtual Private Cloud (VPC)：为您的 Google Cloud 工作负载提供全球可扩缩的网络功能的虚拟系统。VPC 包括 VPC 网络对等互连、Private Service Connect、专用服务访问通道和共享 VPC。

此示例架构使用以下第三方产品：

  • Databricks Unity Catalog：Databricks 平台上数据和 AI 资产的统一治理和元数据目录。
  • Amazon S3：Amazon Web Services (AWS) 提供的一项存储服务，可将数据存储为对象并进行管理。

使用场景

此参考架构专为需要统一来自多个云环境和本地系统的孤立数据以推动分析和 AI 计划的组织而设计。此架构具有以下优势：

  • 无边界的统一资料：可让分析师和决策者全面了解业务实体的单一、全面的视图。 这种统一的视图可提高分析的准确性，并确保无论数据存储在何处，都能保持一致且最新。
  • 降低了运营复杂性并降低了总拥有成本 (TCO)：Lakehouse 无需构建和维护脆弱的数据流水线。借助此方法，您可以直接查询位于不同云平台上的数据。它避免了与物理数据移动相关的运营开销、存储费用和延迟时间。
  • 智能体 AI 工作流：AI 智能体可帮助数据分析师直接将复杂的行为汇总转化为可行的业务策略。借助代理，分析师可以通过标准协议安全地访问受治理的结构化 lakehouse 数据。

以下是本文档中描述的架构的一些用例示例：

  • 实时零售分析：一家零售公司需要根据销售和库存情况立即做出决策。借助此架构，他们可以将在 AWS 中管理的静态产品目录数据与 Google Cloud上运营 AlloyDB 数据库中的实时销售交易数据相结合。分析师和商店经理可以按预定义的批处理间隔查询此统一视图，以监控促销活动的成效、确定需要补货的热销商品，或分析新出现的区域购买模式。
  • 客户个性化：一家金融服务公司希望为其客户关系经理提供客户的完整统一视图。该公司可以使用此架构将 AWS 上数据湖中的历史营销互动数据与 AlloyDB 中的实时客户账号信息整合在一起。然后，客户关系经理可以使用 AI 助理提出问题，例如“总结此客户的最后三笔交易，并撰写一封个性化电子邮件，建议客户开立新的高收益储蓄账户”。

设计考虑事项

如需在生产环境中实现此架构，请考虑以下建议：

  • 网络拓扑和出站流量策略：为了确保可靠的性能并最大限度地降低无边界网络上的数据传输费用，请使用 Cross-Cloud Interconnect 在 Google Cloud 和 AWS 之间建立专用连接。否则，通过公共互联网从 Google Cloud 到 AWS 的数据查询可能会产生高昂的出站流量费用和不可预测的延迟时间。
  • 计算选择：为了优化性能和费用，请选择最适合工作负载各个部分的计算服务。现代数据湖仓不依赖于单一的计算服务。如需对运营数据库执行完全匹配过滤，请使用 BigQuery 联合查询。如需分流内存密集型和复杂的数据操作（例如矢量化无边界联接），请使用 Managed Service for Apache Spark with Lightning Engine。
  • AI 模型接地：为了减少 AI 模型出现幻觉的情况，请让模型基于统一的客户资料，以强制执行业务定义和统计验证。如果您让 AI 模型接触数以十亿计的原始无边界未汇总数据，可能会导致令牌消耗过多和幻觉率过高。

  • 身份和访问权限管理：为了强制执行最小权限原则，请通过系统管理的身份来管理访问权限。

    使用这些身份和访问权限管理策略有助于防止未经授权的数据渗漏，并为所有数据访问权限提供统一的审核跟踪记录。

部署

如需部署此架构，请参阅构建无边界开放数据湖仓一体 Codelab。此示例实现可帮助您预配特定的网络基础设施、执行 C++ PySpark 工作流，以及配置 AI 代理以安全地与您的数据湖仓进行交互。

后续步骤

贡献者

作者：Hyunuk Lim | 开发技术推广工程师

其他贡献者：