企业向 lakehouse 架构现代化时，正在标准化 Apache Iceberg 等开放格式，以在兼容引擎间建立共享数据资产。catalog 是 lakehouse 的关键组件，在 Iceberg 环境中通常是 Iceberg REST Catalog，负责维护表指针、处理原子提交、充当表位置的单一事实来源。随着查询规模随 agent 增长，大型企业需要一个高扩展、高可用的托管 catalog，以支持大量重复小查询，并提供原子性、一致性、可用性和并发性。

Google Cloud 推出了由 Spanner 驱动的 Lakehouse runtime catalog（GA），它基于 Apache Iceberg REST Catalog 规范构建，是一个完全 serverless、高可用的统一元数据注册表。文章总结了托管 catalog 需要解决的五个核心挑战：原子提交与并发控制（需可靠的 compare-and-swap 操作）；高可用与运维（catalog 宕机则查询立即失败）；后端数据库扩展（传统 scale-up 关系型数据库有垂直上限，scale-out 系统常牺牲一致性或难以管理）；表维护协调（compaction、快照过期、manifest 重写、孤儿文件清理）；治理与安全（认证、命名空间与表级访问控制、vended credentials）。

Lakehouse runtime catalog 的架构优势包括：开放 API 支持多引擎互操作，注册后的表可被 BigQuery、Google Cloud Managed Service for Apache Spark 及开源引擎通过标准 REST 接口直接发现和查询；零数据拷贝，表定义直接指向对象存储中的现有数据；跨云双向联邦，可访问 Databricks Unity、Snowflake Horizon 和 AWS Glue 中的数据，支持 vended credentials 和 OIDC token 交换；通过 credential vending 实现安全访问，无需给查询引擎直接的存储凭据；与 Knowledge Catalog 和 Cloud IAM 集成，提供 AI 驱动的上下文和表级安全。Etsy 已将 catalog 迁移到该服务，以数据原位加入的方式将管道查询加速 60%。

Spanner 是底层支撑：它兼具关系型 SQL 语义和多表 ACID 事务，同时具备 NoSQL 系统的水平扩展弹性，无需手动分片，计算和存储可独立透明扩展，还能自动检测热点拆分并迁移。Spanner 区域配置提供高达 99.99% 的可用性，事务可序列化，保证了强一致性。进一步地，Lakehouse runtime catalog 与 Knowledge Catalog 集成，利用 Spanner 支持的全文搜索与原生向量搜索组合，在同一查询中结合关键词检索和语义嵌入，且两种索引基于同一数据集，随表 DML 以 ACID 一致性更新，省去同步管道和外部搜索系统的运维负担。

该方案还可将分析负载与操作负载结合：把 Iceberg 分析数据与 Spanner 中的 OLTP 数据联合用于分析，或在 Spanner 这类操作数据库中低延迟访问 Lakehouse 资产。文中示例用曼哈顿出租车行程（Iceberg）和出租车区域（Spanner）数据找出最拥堵路线，并可通过 Conversational Analytics Agent 访问同一数据获得二阶洞察。

总体上，现代云环境向 Google Cloud 的 borderless Lakehouse 迁移，可减少数据孤岛、统一多引擎治理、为 agent 提供可信上下文并降低运维总成本。Lakehouse runtime catalog 作为 agent 规模下高扩展高可用的元数据基础，让用户更快将生产工作负载落地。