Cross-cloud conversational analytics made simple with open standards

跨云对话分析与无边界的Lakehouse | Google Cloud Blog

数据与分析

使用开放标准简化跨云对话分析

2026年10月14日

##### Praveen Kumar

数据与AI客户工程师

##### 11月4日：智能数据云活动

与我们的产品负责人共同规划您的智能未来

注册

对大多数组织而言，数据无处不在。随着工程团队扩展并为工作负载采用专用平台，企业数据自然会分散在多个云平台和运营系统中。当分析和AI项目需要从整个组织获取上下文时，这些团队通常面临艰难的权衡：构建复杂的数据抽取管道将数据复制到中央仓库，或接受碎片化的报告。

传统架构通过定时抽取管道解决这种碎片化问题，将远程数据集复制到中央暂存仓库。这种方法会导致同步延迟，增加重复存储成本，并触发可变的网络出口费用。当上游模式发生变化时，管道会中断，团队需要花费数小时在不同仪表板间对齐指标。

BigQuery和Google Cloud的无边界Lakehouse通过基于开放的Apache Iceberg REST目录规范构建的底层架构，提供了一种更简洁的解决方案。您无需将数据移动到计算引擎，而是可以直接将Google Cloud的计算和生成式AI带到数据所在位置，通过Databricks、Snowflake和AWS Glue进行原地查询。

在本文中，我们将逐步演示如何配置Databricks Unity Catalog以实现与BigQuery的联邦查询（AWS Glue和Snowflake的设置见附录），运行一个跨三个外部目录的联合查询，并使用BigQuery的对话分析功能通过自然语言探索整合后的数据。

图1：通过Lakehouse架构，BigQuery能够跨外部Apache Iceberg REST目录同步元数据，实现无需数据迁移的原地对话分析。

无边界Lakehouse架构

该解决方案使用Lakehouse运行时目录同步其他云提供商的元数据，使您能够通过Apache Iceberg REST目录端点使用BigQuery或外部开源引擎查询数据，而无需迁移数据。由于Databricks Unity Catalog、Snowflake Horizon Catalog和AWS Glue Data Catalog均支持开放的Apache Iceberg REST目录规范，您可以在所有三个平台上应用一致的连接模式。

当执行联邦查询时，Lakehouse运行时目录将元数据同步与存储访问分离：

• 元数据同步：Lakehouse运行时目录根据您定义的刷新计划定期从远程目录同步模式、快照指针和表定义。

• 直接存储访问：在查询运行时，兼容的引擎会使用远程平台颁发的临时凭证，直接从远程对象存储（如Amazon S3）读取Parquet数据文件。

所有查询处理均在Google Cloud计算资源（如BigQuery或Apache Spark托管服务）中运行。在执行过程中不会调用远程Databricks集群、Snowflake虚拟仓库或AWS计算实例。

身份验证遵循显式的三步部署模式：在 Google Cloud 中创建联合目录，检查其配置以获取自动生成的服务账号，并在远程平台内授予访问权限。

您可以使用 AI 生成示例数据。表的模式详细信息如下所示。

配置 Databricks Unity Catalog

我们从 Databricks 开始，准备目录和表。在 Unity Catalog 中，联合访问要求您的目标模式必须与在 Databricks 中注册的外部位置相关联：

加载中...

-- 在 Databricks SQL 工作区中运行 CREATE CATALOG IF NOT EXISTS dbx_retail_db; -- 在模式级别声明托管目标位置 CREATE SCHEMA IF NOT EXISTS dbx_retail_db.dbx_core MANAGED LOCATION 's3://my-databricks-bucket/retail/data/'; -- 创建 Iceberg 维度表 CREATE TABLE IF NOT EXISTS dbx_retail_db.dbx_core.dim_products ( product_key INT, product_id STRING, product_name STRING, category STRING, subcategory STRING, brand STRING, price DOUBLE, cost DOUBLE ) USING iceberg;

• 您可以使用 AI 生成示例数据。每个部分中都提供了表的模式详细信息。

在外部引擎能够读取此表之前，Databricks 元存储管理员必须在元存储详细信息选项卡中启用外部数据访问。

前往 Databricks 管理员账户，进入用户管理，创建 Databricks 服务主体并记下其 UUID "6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx"

将 Databricks 连接到 BigQuery

接下来，使用 gcloud 命令行工具在 Google Cloud 内部创建联合目录。您需要 Databricks 工作区 URL 和 Databricks 服务主体的应用程序 ID：

export GCP_PROJECT_ID="my-lakehouse-project" export GCP_REGION="us-central1" gcloud alpha biglake iceberg catalogs create dbx_retail_db \ --project="$GCP_PROJECT_ID" \ --primary-location="$GCP_REGION" \ --catalog-type="federated" \ --federated-catalog-type="unity" \ --unity-instance-name="dbc-xxxxxxxx-xxxx.cloud.databricks.com" \ --unity-catalog-name="dbx_retail_db" \ --unity-service-principal-application-id="6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx" \ --refresh-interval="300s"

创建完成后，使用以下命令描述目录以查看分配的服务账号：

gcloud alpha biglake iceberg catalogs describe dbx_retail_db \ --project="$GCP_PROJECT_ID"

返回 Databricks 为您的服务主体分配权限：

-- 授予目录遍历权限 GRANT USE CATALOG ON CATALOG dbx_retail_db TO 6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx; -- 授予模式和读取权限 GRANT USE SCHEMA,EXTERNAL USE SCHEMA, SELECT ON SCHEMA dbx_retail_db.dbx_core TO 6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx;

您必须在目标模式或目录上向 Databricks 服务主体授予 EXTERNAL USE SCHEMA 权限，以启用外部数据访问的凭证分发。

最后，要完成连接，请使用以下详细信息在 Databricks 服务主体上配置联合策略 -

• 发行者 URL* - https://accounts.google.com
• 主题* - 由目录描述命令返回的数字主题 ID，例如 1124251400450xxxxxxxx
• 受众 - https://accounts.cloud.databricks.com

跨三个云平台运行一个查询

BigQuery 中使用四部分路径访问联邦 Iceberg 表：project.catalog.namespace.table 。

在我们的环境中，销售交易原生存储在 BigQuery 中：

CREATE SCHEMA IF NOT EXISTS local_retail_dataset OPTIONS(location="us-central1"); CREATE OR REPLACE TABLE my-lakehouse-project.local_retail_dataset.fact_sales ( sale_id STRING, sale_date DATE, customer_key INT64, product_key INT64, store_key INT64, quantity INT64, unit_price NUMERIC, discount NUMERIC, total_revenue NUMERIC, total_cost NUMERIC, margin NUMERIC ) PARTITION BY sale_date CLUSTER BY store_key, product_key;

我们现在可以运行一个单一的SQL查询，将本地销售交易与Snowflake中的客户记录、Databricks中的产品线以及AWS Glue中的商店位置进行连接：

SELECT c.first_name || ' ' || c.last_name AS customer_name, -- 来自Snowflake Iceberg p.product_name, -- 来自Databricks Iceberg s.store_name, -- 来自AWS S3 Iceberg SUM(f.quantity) AS total_units_sold, -- 来自BigQuery本地事实表 SUM(f.total_revenue) AS total_sales_revenue -- 来自BigQuery本地事实表 FROM my-lakehouse-project.local_retail_dataset.fact_sales f INNER JOIN my-lakehouse-project.sf_retail_db.CORE.DIM_CUSTOMERS c ON f.customer_key = c.customer_key INNER JOIN my-lakehouse-project.dbx_retail_db.dbx_core.dim_products p ON f.product_key = p.product_key INNER JOIN my-lakehouse-project.glue_retail_db.glue_retail_db.dim_stores s ON f.store_key = s.store_key GROUP BY 1, 2, 3 ORDER BY total_sales_revenue DESC LIMIT 10;

BigQuery会在原地处理这些连接操作。请注意Snowflake的标识符使用大写（CORE.DIM_CUSTOMERS），而Databricks和AWS Glue保持小写的表路径。

图2 - 结合Snowflake、Databricks和AWS Glue数据的查询结果。

使用自然语言探索跨云数据

由于联合Iceberg表在BigQuery中表现得像本地表，下游分析功能可以直接继承访问权限。您可以将BigQuery中的对话式分析指向这些联合模式，让团队成员使用自然语言提示探索跨云数据。

为了给对话式分析提供完整的操作上下文，我们将联合查询保存为逻辑视图：

CREATE OR REPLACE VIEW my-lakehouse-project.local_retail_dataset.v_omnichannel_sales_pulse AS SELECT f.sale_id, f.sale_date, c.first_name || ' ' || c.last_name AS customer_name, c.country AS customer_country, p.product_name, p.category AS product_category, p.brand AS product_brand, s.store_name, s.city AS store_city, s.region AS store_region, f.quantity, f.total_revenue, f.margin FROM my-lakehouse-project.local_retail_dataset.fact_sales f INNER JOIN my-lakehouse-project.sf_retail_db.CORE.DIM_CUSTOMERS c ON f.customer_key = c.customer_key INNER JOIN my-lakehouse-project.dbx_retail_db.dbx_core.dim_products p ON f.product_key = p.product_key INNER JOIN my-lakehouse-project.glue_retail_db.glue_retail_db.dim_stores s ON f.store_key = s.store_key;

#### 使用自然语言分析销售表现

当您向BigQuery中的对话式分析提问：

"按总销售额排名，我们的顶级客户是谁？他们购买了哪些产品？他们在哪里购物？"

对话式分析会跨所有三个远程目录评估模式，生成SQL语句，执行查询，并呈现结果。

图3：BigQuery中的对话式分析将自然语言提示转换为跨Snowflake、Databricks和AWS Glue的联合查询。

规划缓存和数据驻留

在生产环境中部署联合目录之前，请考虑以下操作行为：

• 背景刷新时机：--refresh-interval 参数控制元数据同步。最小间隔为 300 秒。对于包含数百张表的大型目录，元数据获取可能需要更长时间。如果同步周期超时，BigQuery 会跳过下一个计划运行，以避免任务排队。

• 自动查询缓存：BigQuery 将获取的跨云数据块缓存在联邦目录所在区域（例如 us-central1）。这有助于减少重复查询时的网络传输。由于缓存块存储在该区域的 Google Cloud 存储中，请确认这与组织的数据驻留策略一致。

• 加密控制：跨云缓存块使用 Google 管理的加密密钥。如果组织强制实施 constraints/gcp.restrictNonCmekServices 策略约束，BigQuery 会绕过缓存，每次查询都直接从远程存储读取数据。

• 监控访问指标：您可以在查询执行计划中评估缓存使用情况。在 BigQuery 作业统计信息中检查 objectStorageStats 部分，将 cacheBytesRead 与 objectStorageBytesRead 进行比较。

下一步操作

总结来说，Google Cloud 的无边界 Lakehouse 帮助您激活数据，无论数据存储在何处，无需昂贵的数据迁移或构建额外的数据管道。今天开始，通过查阅无边界 Lakehouse 架构文档了解支持区域和凭证配置。您可以逐步完成无边界 Lakehouse 教程练习外部目录联邦操作。最后，联系您的 Google Cloud 账户团队或客户工程师，评估无边界 Lakehouse 模式是否适用于您的特定数据平台或行业。

附录

设置 Snowflake 和 AWS Glue 跨云数据访问

连接 Snowflake 和 BigQuery

#### 配置 Snowflake Horizon 目录

我们首先在 Snowflake 中创建数据库、模式和 Iceberg 表。在 Snowflake Horizon 中，托管的 Iceberg 表会自动暴露一个开放的 Apache Iceberg REST 目录接口：

-- 在 Snowflake SQL 工作表中运行 CREATE DATABASE IF NOT EXISTS sf_retail_db; CREATE SCHEMA IF NOT EXISTS sf_retail_db.core; -- 创建 Iceberg 维度表 CREATE OR REPLACE ICEBERG TABLE sf_retail_db.core.dim_customers ( customer_key INTEGER, customer_id VARCHAR, first_name VARCHAR, last_name VARCHAR, email VARCHAR, gender VARCHAR, country VARCHAR, signup_date DATE ) CATALOG = 'SNOWFLAKE' EXTERNAL_VOLUME = 'SNOWFLAKE_MANAGED';

在外部引擎能够读取此目录之前，需要配置专用的读取角色，并授予跨数据库、模式和表的遍历权限。

SQL

-- 创建专用读取角色 CREATE ROLE IF NOT EXISTS gcp_lakehouse_reader_role; -- 授予数据库和模式遍历权限 GRANT USAGE ON DATABASE sf_retail_db TO ROLE gcp_lakehouse_reader_role; GRANT USAGE ON SCHEMA sf_retail_db.core TO ROLE gcp_lakehouse_reader_role; -- 授予目标表的读取权限 GRANT SELECT ON TABLE sf_retail_db.core.dim_customers TO ROLE gcp_lakehouse_reader_role;

接下来，使用 gcloud 命令行工具在 Google Cloud 中创建联邦目录。您需要 Snowflake 账户标识符、读取角色和根 Iceberg 数据库名称：

bash

export GCP_PROJECT_ID="my-lakehouse-project" export GCP_REGION="us-central1" gcloud alpha biglake iceberg catalogs create sf_retail_db \
 --project="$GCP_PROJECT_ID" \
 --primary-location="$GCP_REGION" \
 --catalog-type="federated" \
 --federated-catalog-type="snowflake" \
 --snowflake-account-identifier="xy12345-ab67890" \
 --snowflake-warehouse="SF_RETAIL_DB" \
 --snowflake-role="gcp_lakehouse_reader_role" \
 --refresh-interval="300s"

在 Apache Iceberg REST 规范中，--snowflake-warehouse 参数引用的是目录根数据库名称（SF_RETAIL_DB），而不是虚拟计算仓库。

创建完成后，使用以下命令查看目录的分配数字服务账户 ID：

gcloud alpha biglake iceberg catalogs describe sf_retail_db \
 --project="$GCP_PROJECT_ID" \
 --format='value(biglake-service-account-id)'

返回 Snowflake，通过工作负载身份联合（WIF）将 Google Cloud 的数字标识绑定到无密码服务用户：

-- 在 Snowflake SQL 工作表中运行
USE ROLE ACCOUNTADMIN;

-- 将 Google Cloud 的数字标识绑定到无密码服务用户
CREATE OR REPLACE USER snowflake_service_user 
  TYPE = SERVICE 
  WORKLOAD_IDENTITY = ( 
    TYPE = GCP 
    SUBJECT = '102669xxxxxxxxxxxxxxxxx' -- 由 gcloud describe 返回的数字主体 ID
  ) 
  DEFAULT_ROLE = gcp_lakehouse_reader_role 
  COMMENT = '用于通过 WIF 实现 Lakehouse 目录联合的服务用户';

-- 为该服务用户授予读者角色
GRANT ROLE gcp_lakehouse_reader_role TO USER snowflake_service_user;

这通过 OpenID Connect 建立了无密码认证，使 BigQuery 能够从 Snowflake Horizon 直接发现表元数据并颁发临时查询时凭证。

配置 AWS Glue 数据目录

我们从 AWS 开始，准备 IAM 身份，跨 AWS Glue 和 Amazon S3 建立访问权限，并注册 Iceberg 表。

首先，创建一个名为 trust_policy.json 的占位信任策略。这允许您在 Google Cloud 分配唯一目录服务代理之前预置 AWS IAM 角色：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": ["PLACEHOLDER_VALUE"],
          "accounts.google.com:sub": ["PLACEHOLDER_VALUE"]
        }
      }
    }
  ]
}

使用 AWS CLI 创建 IAM 角色。设置 12 小时会话持续时间（43200 秒）可防止长时间分析查询期间凭证过期：

export AWS_ROLE_NAME="lakehouse_glue_federation_role"
aws iam create-role \
  --role-name "$AWS_ROLE_NAME" \
  --assume-role-policy-document file://trust_policy.json \
  --max-session-duration 43200

接下来，在名为 permissions_policy.json 的文件中定义权限策略。该策略授予 BigQuery 读取 AWS Glue 目录元数据以及访问 Amazon S3 中底层 Parquet 数据文件的权限：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlueCatalogRead",
      "Effect": "Allow",
      "Action": [
        "glue:GetCatalog",
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetTable",
        "glue:GetTables"
      ],
      "Resource": "arn:aws:glue:us-east-2:123456789012:*"
    },
    {
      "Sid": "S3BucketAndObjectRead",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::my-glue-iceberg-bucket",
        "arn:aws:s3:::my-glue-iceberg-bucket/*"
      ]
    }
  ]
}

将此权限策略附加到新创建的角色：

aws iam put-role-policy \ --role-name "$AWS_ROLE_NAME" \ --policy-name "lakehouse_glue_federation_policy" \ --policy-document file://permissions_policy.json

重要（AWS Lake Formation）：如果您的 AWS 环境使用 AWS Lake Formation，请确认 IAMAllowedPrincipals 组已获得目标数据库和表的访问权限（或如果存储桶已注册到 AWS Lake Formation，可向 lakehouse_glue_federation_role 显式授予 Lake Formation 权限）。缺少此配置时，Lake Formation 安全设置将阻止 IAM 角色访问目录元数据。

配置好权限后，使用 Amazon Athena 在 AWS Glue 中创建数据库和 Iceberg 表：

-- 在 Amazon Athena 中运行 CREATE DATABASE IF NOT EXISTS glue_retail_db; CREATE TABLE IF NOT EXISTS glue_retail_db.dim_stores ( store_key INT, store_id STRING, store_name STRING, city STRING, state STRING, region STRING, manager STRING, opened_date DATE ) LOCATION 's3://my-glue-iceberg-bucket/retail/dim_stores/' TBLPROPERTIES ( 'table_type'='ICEBERG', 'format'='parquet', 'write_compression'='zstd' );

将 AWS Glue 连接到 BigQuery

接下来，使用 gcloud 命令行工具在 Google Cloud 中注册联合目录。您需要准备 12 位 AWS 账户 ID、AWS 区域以及上述创建的角色 ARN：

export GCP_PROJECT_ID="my-lakehouse-project" export GCP_REGION="us-central1" export AWS_REGION="us-east-2" export AWS_ACCOUNT_ID="123456789012" gcloud alpha biglake iceberg catalogs create glue_retail_db \ --project="$GCP_PROJECT_ID" \ --primary-location="$GCP_REGION" \ --catalog-type="federated" \ --federated-catalog-type="glue" \ --glue-warehouse="$AWS_ACCOUNT_ID" \ --glue-aws-region="$AWS_REGION" \ --glue-aws-role-arn="arn:aws:iam::${AWS_ACCOUNT_ID}:role/lakehouse_glue_federation_role"

为防止 AWS 信任策略传播期间出现提前的后台刷新失败，请在未设置刷新计划的情况下初始化目录。

接下来，提取 Google Cloud 分配给目录的唯一数字主体 ID：

export LAKEHOUSE_SA_ID=$(gcloud alpha biglake iceberg catalogs describe glue_retail_db \ --project="$GCP_PROJECT_ID" \ --format="value(biglake-service-account-id)") echo "分配的 Lakehouse 服务账户 ID: $LAKEHOUSE_SA_ID"

返回 AWS CLI 并更新 IAM 角色的信任策略，将占位符替换为验证过的 Google Cloud 身份：

cat > trust_policy_final.json << EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "accounts.google.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "accounts.google.com:aud": ["$LAKEHOUSE_SA_ID"], "accounts.google.com:sub": ["$LAKEHOUSE_SA_ID"] } } } ] } EOF aws iam update-assume-role-policy \ --role-name "$AWS_ROLE_NAME" \ --policy-document file://trust_policy_final.json

5. 启用元数据同步并验证

gcloud alpha biglake iceberg catalogs update glue_retail_db \ --project="$GCP_PROJECT_ID" \ --refresh-interval="300s"

验证命名空间是否被发现并同步：

验证从 AWS Glue 同步的命名空间

gcloud alpha biglake iceberg namespaces list \ --project="$GCP_PROJECT_ID" \ --catalog="glue_retail_db"

发布于

• 数据分析