你的AWS数据现在可为Google AI提供动力——无需迁移：Google Cloud跨云Lakehouse解析
AI技术与应用 2026-04-26 11:51:16 10 *这是 Google Cloud NEXT Writing Challenge 的投稿*
---
## 每个数据工程师都太熟悉的问题
想象一下：你的公司有多年精心整理的数据存储在 Amazon S3 上。它为你的仪表盘、你的数据管道、你的 ML 模型提供支持。然后领导层有人问：“我们能用 Google 的 AI 来处理这些数据吗？”
你已经知道这意味着什么。迁移。几周甚至几个月的 ETL 工作。令人瞠目结舌的出口费用。跨云数据复制。治理噩梦。破坏现有系统的风险。
多年来，云数据世界遵循一条不成文的规则：**选择你的云，然后就待在那里**。在提供商之间迁移并非不可能——只是痛苦到大多数团队都不愿折腾。
在 Google Cloud NEXT '26 上，这条规则改变了。Google 发布了基于 Apache Iceberg 构建的 **Cross-Cloud Lakehouse**，这可能是整场大会最被低估的公告——尤其是如果你关心 AI 实际发展方向的话。
---
## 什么是 Cross-Cloud Lakehouse？
在深入了解公告之前，先快速说明一下背景：截至 2026 年 4 月 20 日，Google 将 BigLake 更名为 **Google Cloud Lakehouse**，BigLake Metastore 现为 **Lakehouse Runtime Catalog**。如果你之前使用过 BigLake，API 和 CLI 命令保持不变——只是换了新名称以更好地反映其实际功能。
Cross-Cloud Lakehouse 将 Google Cloud Lakehouse 扩展到让你可以直接从 Google Cloud 使用 BigQuery、Dataproc 和 Apache Spark 查询 AWS（以及 Azure，将于今年晚些时候支持）中的数据——**无需迁移数据或构建复杂的 ETL 管道**。
它分两层运作：
**元数据层：** 你的远程 Apache Iceberg 目录（如 Databricks Unity Catalog 或 AWS Glue）连接到 Google 的 Lakehouse。它在不复制任何文件的情况下发现你的数据，并通过 Workload Identity Federation 进行安全认证——无需长期访问密钥。
**传输层：** Google 将 Cross-Cloud Interconnect (CCI) 直接集成到数据平面。通过将 CCI 的专用私有网络与 Apache Iceberg REST Catalog 相结合，跨云查询以低延迟运行，无需支付通过公共互联网路由流量时通常会产生的高额出口费用。
结果是：你的 agent 和分析师可以像查询 Google Cloud 中的数据一样查询 AWS S3 中的数据。
---
## 真正重要的 4 项公告
Google 发布了下一代 Cross-Cloud Lakehouse，包含四项实质性突破。让我在 keynote 层面之外逐一解析。
### 1. 完全托管的 Iceberg 存储与真正的互操作性
这比听起来更重要。以前，如果你使用 Apache Spark 通过 Iceberg REST Catalog 表进行 ETL，你就无法通过 BigQuery 写入或使用其存储管理功能。你必须二选一。
现在 BigQuery 和托管 Apache Spark 服务之间实现了真正的读写互操作性，包括 Iceberg 兼容引擎如 Spark、Trino、Flink——以及第三方引擎如 Databricks 和 Snowflake（Preview 阶段）。一份数据，多个引擎，无妥协。
### 2. Cross-Cloud Caching：没人谈论的功能
这是让跨云在经济上可行的功能。Google 引入了智能缓存，在**首次读取**时存储跨云数据，大幅削减出口费用，并显著加速对 AWS 和 Azure 数据的后续查询。
简单来说：第一次通过 BigQuery 查询 S3 数据时，它会被缓存在 Google 端。之后每次查询都快速且廉价。首次读取之后，跨云访问的代价几乎为零。
### 3. Lightning Engine for Apache Spark：最高 4.5 倍性能提升
Google 的 Lightning Engine 是一个实时无服务器 Spark 引擎，相比开源 Spark 替代方案提供最高 4.5 倍的性能提升，在大数据集场景下相比领先的商业竞品提供最高 2 倍的性价比优势。
Flipkart、Lowe's 和 Meesho 已经用它加速了他们的 Apache Spark 工作负载。这不是 beta 测试——而是生产级规模。
### 4. 不到 6 个月预估 117% 的 ROI
Google 自己的分析显示，这种 agent 优先的 lakehouse 方法预估 ROI 达到 **117%**，回本期不到 6 个月。Spotify 已经用它实现了创新。
对供应商发布的 ROI 数字保持适度的怀疑是应该的——但底层逻辑是成立的。如果你消除了数据移动成本，降低了 ETL 复杂性，并让多个引擎共享单一数据副本，数学计算确实对你有利。
---
## 大多数人忽略的角度：这是关于 AI agent 的，不只是数据
这是我认为的真正故事，也是为什么这个公告值得更多关注的原因。
NEXT '26 上每个人都在谈论 Gemini Enterprise Agent Platform、Agent Studio、agent 工作流。但所有这些都有一个根本问题：**AI agent 的智能程度取决于它能访问的数据**。
如果你的 agent 遇到跨云壁垒——高延迟、昂贵的出口费用、专有目录锁定——它的自主性就被破坏了。它无法跨整个数据资产进行推理。它只能看到你成功集中的那一小部分数据，而在大多数企业中，这只是冰山一角。
Cross-Cloud Lakehouse 不是数据功能。它是使多云企业中的真正有能力的 AI agent 成为可能的基础设施层——换句话说，几乎每个真实企业都是如此。
---
## 实际使用体验
无需账户即可理解。设置好联合后，跨云查询的实际样子如下：
```sql
SELECT user_id, action, COUNT(*) as total_actions
FROM `your-project.federated_aws_catalog.your_namespace.your_table`
WHERE event_date >= '2026-04-01'
GROUP BY 1, 2;
```
这是标准的 BigQuery SQL。但查询中的表实际存储在 Amazon S3 上。没有数据移动。没有迁移。没有需要管理的特殊连接器。Google Cloud Lakehouse 透明地处理元数据转换和安全数据访问。
你也可以直接从 Apache Spark 集群读取 Cross-Cloud Lakehouse 数据，无需管理单独的 AWS 凭证或 S3 连接器——Lakehouse 通过 Iceberg REST Catalog 接口自动向 Spark 提供临时的、限定范围的 S3 凭证。
---
## 我的观点
作为一名大四 IT 工程专业学生，我在两个平台的免费层级上花了不少时间进行实验——坦率地说，体验大多是正面的。两个平台都非常强大，适合学习，而且免费层级的慷慨意味着你可以不花一分钱就构建真实的东西。不过我通过惨痛教训学到，"免费层级"需要持续关注。我曾经在一次学习项目后忘记关闭几个 AWS 服务，一觉醒来收到超过 120 美元的账单。AWS 在我解释情况后退款给我了，但那刻的惊慌记忆犹新。不知道什么在运行、在花多少钱，这种焦虑是真实的——尤其当你是一个没有预算的学生时。
这就是为什么这次 Cross-Cloud Lakehouse 公告的成本角度最吸引我的原因。跨云缓存功能尤其如此——S3 数据在首次读取后缓存在 Google 端，大幅降低后续查询的出口费用——这种东西改变的不只是企业巨头的计算方式，对小型团队和学习者也意义重大。出口费用是云服务中最令人沮丧的隐性成本之一，Google 直接解决这个问题而不是仅仅承诺"无缝互操作性"，这是有意义的。
我的诚实怀疑？我想看看 Google 自己案例研究之外的团队的真正基准测试。117% 的 ROI 数字在纸面上很诱人，但供应商发布的数字总是值得审视。我还想了解故障模式——当跨云连接出现延迟峰值时会发生什么？或者当缓存过期时？对于学习和实验来说，这看起来确实令人兴奋。对于大规模生产，我想先至少等六个月让社区充分测试。
---
## 即将到来的（以及为什么重要）
生态系统已经比大多数意识到的更大。Cross-Cloud Lakehouse 已经支持与 Databricks、Oracle Autonomous Database、Snowflake、SAP、Salesforce Data360、ServiceNow、Workday 等的双向联合。Azure 支持将于今年晚些时候推出。
目录联合也即将在 Preview 阶段推出，支持 AWS Glue、Databricks、SAP 和 Snowflake——Confluent Tableflow 支持即将到来。
这不是 Google 在构建一个功能。这是 Google 在将自己定位为多云世界的**分析大脑**——你的数据留在原处，但你的 AI 运行在 Google 的基础设施上。
这个赌注能否成功取决于采纳率和规模性能，我们会在未来几个月了解更多。但架构方向是明确的，NEXT '26 上的公告是发令枪。
*"真正的考验是企业是否信任 Google 让它成为其 AWS 数据之上的查询层——你怎么看？"*
---
## 资源
- What's New in the Agentic Data Cloud — Google Cloud Blog
- The Future of Data Lakehouse for the Agentic Era — Google Cloud Blog
- Google Cloud NEXT '26 Wrap-Up — All 260 Announcements
- Cross-Cloud Lakehouse Documentation
