Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog

TL;DR · AI 摘要
Google Cloud 使用 Spanner 构建了可扩展的 Lakehouse 运行时目录,解决了 Apache Iceberg 在大规模场景下的原子提交、高可用性和数据库扩展等核心挑战。
核心要点
- Spanner 支持每秒数百万次的原子提交,保障 Iceberg 表的 ACID 事务。
- Google Cloud 目录服务实现 99.999% 可用性,避免因服务中断导致查询失败。
- Spanner 的无限制水平扩展能力突破传统数据库的垂直资源瓶颈。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Lakehouse 运行时目录架构
- 核心挑战
- 原子提交
- 高可用性
- 数据库扩展
- 表维护
- Spanner 解决方案
- 分布式 ACID 事务
- 无限水平扩展
- 自动分片管理
金句 / Highlights
值得收藏与分享的关键句。
Spanner 的乐观并发控制实现 Iceberg 表的原子 compare-and-swap 操作,确保元数据一致性。
传统数据库在 1000 节点规模时需手动分片,而 Spanner 可自动扩展至数百万节点。
Lakehouse 目录服务通过 Spanner 实现 99.999% 可用性,减少 90% 的运维成本。
由 Spanner 提供支持的 Lakehouse 运行时目录 | Google Cloud 博客
数据分析
扩展规模的 Apache Iceberg 托管:Spanner 如何驱动 Lakehouse 运行时目录
2026 年 10 月 7 日
##### Vinod Ramachandran
产品经理
##### Mina Mikhail
软件工程经理
##### 今天试用 Gemini Enterprise
工作场所人工智能的入口
立即试用
随着客户向 Lakehouse 架构现代化转型,他们正在采用 Apache Iceberg 等开放格式作为标准,以在兼容引擎之间创建统一的数据资产。这使您能够构建原生 AI 的 Lakehouse,将数据转化为语义知识,实现主动行动,并在智能代理规模上运行。
Lakehouse 的关键组件之一是目录,在 Apache Iceberg 环境中,这通常意味着 Iceberg REST 目录。Apache Iceberg 目录负责维护表指针、处理原子提交,并作为表位置的单一事实来源。但随着大型企业组织向 Lakehouse 现代化转型,他们开始意识到需要在 Lakehouse 架构中包含一个高度可扩展且可用的托管目录。随着代理查询规模的扩大,这一点变得更加重要。为了支持代理产生的大量重复小型查询,您需要构建在提供原子性、一致性、可用性和大规模并发性的托管目录之上。
在本文中,我们将探讨托管目录在现代云环境和代理规模下面临的挑战,并展示 Google Cloud 的无服务器 Lakehouse 运行时目录如何帮助解决这些问题。由 Spanner 提供支持,Google Cloud 的始终在线数据库具备几乎无限的扩展能力,并符合开放的 Apache Iceberg REST 目录规范,Lakehouse 运行时目录是您在智能代理时代所需的高可扩展性和可用性基础。
Lakehouse 中托管目录需要解决的挑战
与在 Lakehouse 中大规模运行生产分析的数据工程师和基础设施负责人交流时,以下核心痛点持续出现,需要托管目录来解决:
原子提交和并发控制:Iceberg 通过乐观并发控制(OCC)保证 ACID 事务。托管目录必须实现坚如磐石的原子比较并交换(CAS)操作,以替换当前的元数据指针。
高可用性和运维维护:由于目录宕机会导致查询立即失败,托管目录成为关键的 Tier-1 服务。
目录后端数据库的扩展:目录架构师在选择表元数据和状态后端数据库时通常面临艰难的权衡。传统的垂直扩展关系数据库提供 SQL 和 ACID 事务,但在高并发读写负载下会遇到垂直 CPU、内存、存储和连接限制,除非手动分片,这会带来巨大的运维开销;而水平扩展数据库系统要么最终一致,要么难以管理,要么不具备企业级就绪性,或以上所有问题。
表维护协调:目录本身不会优化数据;您必须构建和运营辅助流水线来执行压缩、快照过期、清单重写和孤立文件清理。
治理和安全:目录充当安全守门人。目录必须实现和维护:
- 认证协议(例如,OAuth2 令牌交换、IAM 联邦)
- 支持细粒度的访问控制,可精确到命名空间和表级别
- 分发存储凭证(例如生成短期令牌,使查询引擎无需使用范围广泛的直接存储凭证)
Lakehouse 运行时目录
为解决这些挑战,我们构建了 Lakehouse 运行时目录(GA 版),支持 Iceberg Rest Catalog。Lakehouse 运行时目录是一个完全无服务器架构、高可用且统一的元数据注册中心,专为现代开放表格式(如 Apache Iceberg)设计。通过原生实现 Apache Iceberg REST Catalog 规范,Lakehouse 运行时目录将元数据发现与计算引擎解耦,确保多个 Iceberg 兼容引擎可访问共享数据仓库,并帮助您更快将工作负载投入生产环境。我们已协助许多客户简化其托管目录的迁移。例如,Etsy 将其目录迁移至 Lakehouse 运行时目录,通过原地整合数据使流水线查询速度提升 60%。
这种架构带来了多项优势:
- 开放 API:支持 Iceberg Rest Catalog 使不同团队可使用其首选分析工具访问统一数据集
- 多引擎互操作性:注册后,表可通过标准 REST 接口立即在 Google Cloud Managed Service for Apache Spark、BigQuery 和开源引擎之间发现和查询
- Iceberg 表读写互操作性:使用 BigQuery、Managed Spark 等 Iceberg 兼容引擎向 Lakehouse 运行时目录注册的 Iceberg 表进行写入。客户还可使用 Managed Spark 向外部目录中的 Iceberg 表写入数据
- 企业级功能的全托管 Iceberg 存储:利用 Google 差异化基础设施在 Iceberg 表上运行分析,兼具开源灵活性与性能、规模、治理和多模态处理能力
- 零数据复制:表定义直接指向底层对象存储中的现有数据,无需移动、重写或复制底层数据
- 跨云双向目录联邦:通过凭证分发和 OIDC 令牌交换,支持访问 Databricks Unity、Snowflake Horizon 和 AWS Glue。这使您可直接将 Google AI 带到 AWS 和 Azure 数据环境
- 基于凭证分发的安全访问:目录支持多种授权机制,可在凭证分发和终端用户凭证之间进行选择。这意味着可通过现代机制(如凭证分发)访问表,而无需直接访问底层对象存储(Cloud Storage、AWS S3、Azure Blob Storage)中的文件
- AI 驱动的上下文与治理:Lakehouse 运行时目录直接集成 Knowledge Catalog 和 Cloud IAM,使您能够为代理定义可信上下文,并在所有计算引擎上一致应用表级安全策略。可直接获得目录中 Iceberg 表的开箱即用搜索、血缘分析和洞察功能
- 原子提交和并发控制、高可用性及可扩展性:依托 Google 的全球基础设施和 Spanner,您可获得满足数据规模增长所需的元数据高可用性、并发处理能力和扩展性。支持 Cloud Storage 双区域和多区域存储桶,可实现故障转移场景。同时,由于采用无服务器架构和免运维环境,总拥有成本显著降低,并可支持任意工作负载规模的扩展。
什么技术支撑了 Lakehouse 运行时目录?
Lakehouse 运行时目录是一个高度可用、并发且可扩展的目录,其强一致性保障源于基于 Spanner 的构建。与传统垂直扩展关系型数据库存在单节点性能瓶颈不同,Spanner 将完整的关系型 SQL 语义和多表 ACID 事务与 NoSQL 系统在读写操作上的水平扩展弹性相结合。
Spanner 通过区域配置实现 Lakehouse 运行时目录的高可用性,可用性高达 99.99%。Spanner 为 Lakehouse 运行时目录提供开箱即用的可扩展性:作为水平扩展数据库,Spanner 无需手动分片,可独立透明地扩展计算和存储资源。Spanner 动态监控数据量和查询负载,跨节点分割并重新分配数据范围。计算节点根据 CPU 使用率和存储阈值动态扩展。Spanner 可自动检测分割层级的过载情况,并将高负载分割迁移到非过载节点。此外,Spanner 让 Lakehouse 运行时目录用户消除了传统关系型一致性与分布式可扩展性之间的权衡,实现了行业领先的强一致性保障。Lakehouse 事务具有可序列化特性——数据库内事务的执行顺序与客户端观察到的事务提交顺序完全一致。这一基础使 Lakehouse 用户能够实现代理级规模的操作。
随后,为了进一步支持代理使用场景,Lakehouse 运行时目录直接集成 Knowledge Catalog,可轻松发现 Lakehouse 冰川表(Iceberg tables),并为代理提供可信上下文。Knowledge Catalog 利用 Spanner 提供的全文搜索与原生向量搜索的高效组合,这种方案通过单次查询即可将词法关键词搜索与语义嵌入相结合,显著提升搜索召回率。由于两种索引类型均基于相同的底层数据集构建,它们可与基础表的 DML 操作保持严格的事务性 ACID 一致性同步更新。这消除了管理同步流水线、外部向量搜索和全文搜索系统的运维开销。简而言之,Lakehouse 运行时目录可显著缩短代理使用场景的上市时间。
统一分析型与操作型工作负载
基于 Apache Iceberg 的 Google Cloud 无边界 Lakehouse 可将分析数据与操作型工作负载相结合。应用场景涵盖从将 Lakehouse 数据资产与 OLTP 数据(来自 Spanner)结合用于分析,到低延迟服务应用(Lakehouse 资产可通过 Spanner 等操作型数据库访问),再到在第一方和第三方代理中实现对话式分析。
以下是示例,展示了 Lakehouse 运行时目录与 Spanner 的实际应用。在此示例中,我们将曼哈顿出租车行程的分析数据(由 Apache Iceberg 支持)与 Spanner 中出租车区域的操作数据相结合,以找出交通最拥堵的路线。该示例还表明,您也可以使用对话式分析代理访问相同数据并获取二阶洞察。
找出曼哈顿最拥堵的交通路线
向无边界的 Lakehouse 迈进
向 Google Cloud 的 Lakehouse 进阶可以减少分析引擎和代理之间的数据孤岛,统一多引擎治理,为代理提供可信的上下文,并大幅降低运营总拥有成本。利用基于 Spanner 的 Lakehouse 运行时目录,可帮助您为现代云环境做好准备,实现代理规模的运行。要了解更多并开始免费试用,请访问
Lakehouse 网页 并在此处了解有关 Spanner 的更多信息。
发布在
- 数据分析
- 数据库