Apache Hive Metastore (HMS) 十多年来一直是大数据分析的事实元数据权威。无论是部署在 Hadoop 集群，还是由 MySQL/PostgreSQL 支撑的自管理 Compute Engine 上，HMS 都是 Spark、Presto、Hive 查询 .parquet 和 .orc 文件的中心 schema 注册表。但当企业数据规模增长到 PB 级，并横跨 Google Cloud Managed Spark、BigQuery、Trino 等多个查询引擎时，传统 HMS 就变成了关键的操作瓶颈。

文章总结了三个核心痛点：一是架构与扩展瓶颈。HMS 依赖关系型数据库跟踪表 schema、分区和存储位置。当分区表达到数十万规模时，分区裁剪和批量列举操作会严重拖累数据库。一个复杂 Spark 作业请求分区元数据，就能让 metastore 的 CPU 飙升至 100%，造成集群级查询延迟甚至 OOM。二是身份与安全治理孤岛。旧 Hive Metastore 基于 Hadoop 边界安全模型设计，要在 Spark 作业和 BigQuery 这类 SQL 引擎上同时实施表级 ACL，就得维护两套割裂且重复的安全策略。三是运维负担和 TCO。管理高可用 MySQL/Postgres、给 HMS daemon 打补丁、调 JDBC 连接池，还要为闲置的实例付费，这些都在消耗数据平台团队的精力。

解决方案是 Google Cloud 去年推出的 Lakehouse runtime catalog。它基于开源 Apache Iceberg REST catalog 规范构建，完全 serverless、高可用，是一个统一元数据注册表，同时支持传统 Hive/Parquet 表与现代开放表格式（如 Iceberg）。通过原生实现 Iceberg REST Catalog 规范，它把元数据发现与计算引擎解耦，让多个 Iceberg 兼容引擎能以零数据拷贝方式访问同一份数据，无需为不同引擎维护多份数据副本。

这个方案带来几个架构层面的好处：多引擎互操作——表注册后，可立即通过标准 REST 接口被 Managed Spark、BigQuery 和开源引擎发现并查询；开放 API——同时支持 Iceberg Rest Catalog 和 Hive Catalog，不同团队可以用各自偏好的工具访问同一份数据；零数据拷贝——表定义直接指向 Cloud Storage 里的现有数据，不需要移动、重写或复制。它还集成了 Knowledge Catalog 和 Cloud IAM，能定义面向 agent 的可信上下文，并支持凭据 vending（credential vending），用户无需直接访问底层存储桶文件即可访问表。底层由 Google 的 Spanner 支撑，支持双区域/多区域存储桶故障转移，且 serverless 无运维，从而降低 TCO。

文章还提供了一个零拷贝迁移能力：直接连接传统自管理 Hive Metastore，提取外部表定义和分区映射，注册到 Lakehouse catalog，之后这些数据就能立即用于 Managed Spark、BigQuery，以及 Gemini 驱动的 Conversational Analytics agents。整个迁移可以几分钟内完成。

简单说，这个方案的核心是让旧 Hive 表在不重写数据的前提下，直接享受到现代云上元数据服务的弹性、统一治理和低运维成本，同时为 agent 时代的应用准备好可信的数据上下文。