Apache Hive Metastore（HMS）长期承担数据湖的元数据中枢：Spark、Presto 和 Hive 通过它定位存放在对象存储中的 Parquet、ORC 文件。但当数据规模增长到 PB 级、表和分区数量持续膨胀，并且 BigQuery、Managed Service for Apache Spark、Trino 乃至分析智能体都需要访问同一批数据时，传统 HMS 很容易从基础设施变成瓶颈。
Google Cloud Lakehouse runtime catalog 提供了一条渐进式升级路径：保留 Cloud Storage 中的现有数据，通过迁移表定义和分区映射，把元数据注册到无服务器目录中。底层文件无需复制或重写，计算引擎则可通过 Iceberg REST Catalog、Hive Catalog 等开放接口访问统一的数据资产。
HMS 的问题不只是数据库性能
传统 HMS 通常由 Metastore 服务和 MySQL、PostgreSQL 等关系数据库组成。这个结构在集群数量有限、查询引擎单一时足够实用，到了云上多引擎环境，则会同时暴露三类问题。
元数据请求会形成共享热点
高分区表需要频繁执行分区枚举、过滤和批量读取。一个复杂 Spark 作业就可能把 Metastore 后端 CPU 推到满载，使其他集群的查询一起等待，严重时还会触发连接池耗尽或 OOM。
扩容也不是简单增加 HMS 进程：数据库索引、事务、连接数、缓存和主从切换仍然需要平台团队持续调优。元数据服务因此拥有与业务数据不相称的运维成本和故障半径。
权限散落在多个控制面
Hadoop 时代的安全模型偏向网络边界、服务身份和文件权限。企业如果同时运行 Spark 与 BigQuery，往往需要在 HMS、计算平台和 Cloud Storage 上重复维护策略。
Lakehouse runtime catalog 与 Knowledge Catalog、Cloud IAM 集成，可把表级治理放到统一控制面。其 credential vending 能力还允许引擎在获得表访问授权后取得必要凭据，而不是要求每个调用方直接拥有底层存储桶权限。这一点对智能体尤其重要：智能体需要受约束的可信上下文，而不是一把可以遍历整个数据湖的存储密钥。
常驻服务带来隐性 TCO
高可用数据库、HMS 守护进程、补丁、备份、JDBC 连接池和容量规划都需要人力。实例式服务还会在低负载期间持续计费。无服务器目录把容量与可用性责任交给托管平台，并通过 Spanner 支撑元数据扩展；对于 Cloud Storage 双区域和多区域存储桶，还可覆盖相应的故障转移场景。
零数据复制究竟迁移什么
这里的“零复制”特指不移动、复制或重写 Parquet、ORC 等底层数据文件。迁移能力连接现有 HMS，提取外部表定义及分区映射，再将其注册到 Lakehouse runtime catalog。新目录中的表仍然指向原来的 Cloud Storage 地址。
因此，迁移对象主要包括：
- 数据库、表和列定义；
- 外部表的存储位置与文件格式；
- 分区键以及已有分区到存储路径的映射；
- 计算引擎发现和访问表所需的目录元数据。
这种方式缩短了切换窗口，也避免为 PB 级数据准备双倍存储。不过，零复制不等于零风险。迁移前仍需检查非标准 SerDe、自定义 InputFormat、路径不一致、分区未登记、大小写差异以及依赖 HMS 专有行为的作业。源数据在切换期间是否继续写入，也必须纳入一致性方案。
可以这样实践：迁移前后做多引擎验收
下面是一个可改造的 PySpark 验收脚本。假设旧 HMS 已配置为 legacy catalog，新目录已按 Google Cloud 当前文档配置为 lakehouse catalog；实际的 REST URI、认证方式和 Spark 扩展参数需要替换为项目中的正式配置。
脚本不会修改数据，只比较两套目录下指定表的行数与基础聚合结果。运行前设置表名和用于校验的数值列：
# validate_catalog_cutover.py
import os
import sys
from pyspark.sql import SparkSession
from pyspark.sql import functions as F
TABLES = [
item.strip()
for item in os.environ.get("TABLES", "analytics.orders").split(",")
if item.strip()
]
VALUE_COLUMN = os.environ.get("VALUE_COLUMN", "amount")
spark = SparkSession.builder.appName("catalog-cutover-validation").getOrCreate()
def snapshot(catalog: str, table: str) -> dict:
df = spark.table(f"{catalog}.{table}")
row = (
df.agg(
F.count(F.lit(1)).alias("rows"),
F.sum(F.col(VALUE_COLUMN)).alias("value_sum"),
)
.first()
)
return {
"rows": row["rows"],
"value_sum": None if row["value_sum"] is None else str(row["value_sum"]),
}
failed = False
for table in TABLES:
legacy = snapshot("legacy", table)
lakehouse = snapshot("lakehouse", table)
matched = legacy == lakehouse
failed = failed or not matched
print({
"table": table,
"legacy": legacy,
"lakehouse": lakehouse,
"matched": matched,
})
spark.stop()
sys.exit(1 if failed else 0)
在已经配置好两套 catalog 的 Managed Spark 或其他兼容 Spark 环境中，可以这样运行：
export TABLES="analytics.orders,analytics.order_items"
export VALUE_COLUMN="amount"
spark-submit validate_catalog_cutover.py
仅比较总行数还不够。生产验收应再加入以下检查：
-- 分区裁剪：确认查询只扫描目标日期范围
SELECT order_date, COUNT(*)
FROM analytics.orders
WHERE order_date BETWEEN DATE '2025-01-01' AND DATE '2025-01-07'
GROUP BY order_date
ORDER BY order_date;
-- 空值与业务主键：发现列映射或读取语义变化
SELECT
COUNT(*) AS total_rows,
COUNT(order_id) AS rows_with_id,
COUNT(DISTINCT order_id) AS distinct_ids
FROM analytics.orders;
分别在旧路径和新路径，以及计划接入的 Spark、BigQuery、Trino 等引擎中执行同类查询。除了结果一致性，还要记录查询延迟、扫描数据量、分区裁剪情况和权限拒绝行为。
从双读到切换的落地顺序
稳妥的迁移不应直接停掉 HMS。可以按以下顺序推进：
- 盘点 HMS 中的外部表、分区数量、Cloud Storage 路径、SerDe 和读写作业，优先识别非标准表。
- 冻结或明确迁移窗口内的元数据变更策略，避免源目录和目标目录持续漂移。
- 将表定义和分区映射注册到 Lakehouse runtime catalog，并确认没有改写底层对象。
- 选取只读、低风险工作负载进行双目录校验，再扩展到 BigQuery、Managed Spark 和其他 Iceberg 兼容引擎。
- 在 Cloud IAM 中验证最小权限，特别检查调用方能否查询授权表、能否越权读取其他表，以及是否仍可直接遍历存储桶。
- 分批切换读取流量；对写入工作负载单独验证提交协议、并发控制和失败恢复，不要把“可读取旧 Hive 表”等同于“所有引擎都能安全并发写入”。
- 保留可审计的回退窗口，确认关键作业稳定后，再下线 HMS、数据库和相关运维任务。
Lakehouse runtime catalog 的核心价值不是简单换掉一个 Metastore 服务，而是把元数据发现、跨引擎访问和治理放进统一且开放的控制面。对于已经在 Cloud Storage 中积累大量 Hive 外部表的团队，零数据复制降低了迁移门槛；真正决定上线质量的，则是兼容性清单、权限边界、写入语义和可回退的分阶段切换。