数据分散在多云是很多组织的常态。工程团队为不同 workload 选专门平台，数据自然扩散到多个云和业务系统。做分析和 AI 时需要全组织上下文，传统思路只有两条路：搭复杂抽取管线把数据复制到中心仓库，或者接受碎片化的报表。

传统架构靠定时抽取管线把远端数据复制到中央临时数仓，代价是同步滞后、持续的存储费用、波动的网络出口费。上游 schema 一变，管线就断，团队还要花大量时间在多个不同步的仪表盘之间对齐指标。

BigQuery 和 Google Cloud 的 borderless Lakehouse 换了个思路：基于开放的 Apache Iceberg REST catalog 规范，不把数据搬到计算引擎，而是把 Google Cloud 的计算和生成式 AI 带到数据所在的地方，直接就地查询 Databricks、Snowflake、AWS Glue 里的数据。

核心机制是 Lakehouse runtime catalog 把元数据同步和存储访问分开。元数据层面，它按你设定的刷新计划，定期同步远端 catalog 的 schema、快照指针和表定义。查询运行时，兼容引擎直接用远端平台签发的临时凭证，从远端对象存储（如 Amazon S3）读 Parquet 数据文件。所有查询处理都跑在 Google Cloud 计算里（BigQuery 或 Managed Service for Apache Spark），不会调用远端 Databricks 集群、Snowflake 虚拟仓或 AWS 计算实例。

认证是三步模式：在 Google Cloud 创建联邦 catalog → 检查配置里自动生成的服务账号 → 到远端平台授权。以 Databricks Unity Catalog 为例，需要先建一个 Databricks Service Principal 并记录 UUID，用 gcloud 命令创建联邦目录，然后给这个服务主体授予 EXTERNAL USE SCHEMA 权限，再配置 federation policy，填 Google 的 Issuer URL、catalog 的数值型 Subject ID 和 Audiences。

联邦 Iceberg 表在 BigQuery 里用四段路径 project.catalog.namespace.table 寻址。文章里的示例直接跑一条 SQL，把 BigQuery 原生的销售事务表和 Snowflake 的客户表、Databricks 的产品线表、AWS Glue 的店铺位置表 join 起来。要注意大小写差异：Snowflake 标识符是大写（CORE.DIM_CUSTOMERS），Databricks 和 AWS Glue 的路径是小写。

因为联邦表对下游分析功能来说和原生表行为一致，BigQuery 的对话式分析（conversational analytics）可以直接指向这些联邦 schema。把联邦 join 保存成逻辑视图后，团队成员就能用自然语言提问，比如”谁是销售额最高的客户、他们买了什么产品、在哪些门店消费”。系统会评估三个远端 catalog 的 schema，生成 SQL，执行查询并返回结果。

生产部署前有几个运维点要留意。元数据刷新用 –refresh-interval 控制，最小间隔 300 秒；目录较大（几百张表）时，元数据检索可能超过一个刷新周期，BigQuery 会跳过下一次计划同步，避免任务排队。BigQuery 会把跨云取回的数据块缓存在联邦 catalog 所在的 Google Cloud 区域（如 us-central1），减少重复查询的网络传输，所以需要确认这符合组织的数据驻留政策。缓存用的是 Google 托管密钥；如果组织强制执行 gcp.restrictNonCmekServices 约束，BigQuery 会绕过缓存，每次查询直接读远端存储。想监控缓存效果，可以看查询执行计划里 objectStorageStats 的 cacheBytesRead 和 objectStorageBytesRead 对比。

附录还给了 Snowflake 和 AWS Glue 的接入要点。Snowflake 侧用 Horizon Catalog 自动暴露 Iceberg REST 接口，并借助 Workload Identity Federation 绑定 Google Cloud 的数值身份，建立无密码的 OIDC 认证。AWS Glue 侧需要准备 IAM 角色，设 12 小时会话时长防止长查询凭据过期，还要处理信任策略的传播；如果用了 AWS Lake Formation，必须确认 IAMAllowedPrincipals 有权限，否则安全设置会挡住访问。