Hudi Metadata Table 与 Hive Sync (HMS)怎么选？

一、引言

在很多Hudi的读写使用场景中，我们都会将Hudi的元数据同步给HMS进行Hive/Hudi元数据统一存储管理，以至于很多人混淆Hudi Metadata Table 与 Hive Sync (HMS)的概念与关系，认为保留一个就行。

其实不然，Hudi Metadata Table 与 Hive Sync (HMS)它们不冲突，实际上是互补关系，作用在数据访问链路的不同阶段，解决的是不同层面的问题。

二、定位对比

|--------|-------------------------------------|------------------------|
| 维度 | Hive Sync (HMS) | Metadata Table |
| 解决什么问题 | 让 SQL 引擎能"发现"表（表注册、Schema 管理、分区注册） | 让 Hudi 内部高效获取文件列表和索引信息 |
| 服务对象 | 外部查询引擎（Hive、Spark SQL、Trino、Presto） | Hudi 自身的读写路径 |
| 存储什么 | 表名、列定义、分区列表、存储路径、SerDe 类 | 文件列表、列统计、布隆过滤器、记录索引 |
| 粒度 | 表级 / 分区级 | 文件级 / 记录级 |
| 是否必须 | 取决于是否需要 SQL 引擎访问 | Hudi 内部优化，与外部引擎无关 |

三、它们如何协作

一个典型的查询流程中，两者各司其职：

复制代码

用户执行: SELECT * FROM hudi_db.orders WHERE dt = '2024-01-01' AND city = 'Beijing'

Step 1: 引擎从 HMS 获取表信息
        ├── 表的 base path: s3://bucket/hudi/orders/
        ├── InputFormat: HoodieParquetInputFormat
        ├── 分区 dt='2024-01-01' 存在 ✓
        └── Schema 信息

Step 2: Hudi InputFormat / Connector 接管
        ├── 从 Metadata Table (files 分区) 获取 dt=2024-01-01 下的文件列表
        │   (替代 s3 list，毫秒级完成)
        ├── 从 Metadata Table (column_stats 分区) 获取 city 列的 min/max
        │   → 跳过 city 范围不包含 'Beijing' 的文件
        └── 生成最终 scan plan，只读取少量文件

Step 3: 引擎执行物理读取

四、常见疑惑澄清

1. Hive Sync 注册的分区信息和 Metadata Table 的 files 分区是否重复？

有重叠但用途不同：

HMS 中的分区：告诉 SQL 引擎"这个分区存在"，用于分区裁剪（partition pruning）
Metadata Table 的 files 分区：告诉 Hudi "这个分区下具体有哪些文件"，用于文件定位

HMS 只知道分区存在，不知道分区里有哪些 base file / log file 以及它们的 Hudi 时间线状态。

2.如果不做 Hive Sync，Metadata Table 能替代 HMS 吗？

不能。 Metadata Table 不提供 Catalog 服务，SQL 引擎无法通过它发现表。但如果你的访问方式是直接通过路径读取（如 spark.read.format("hudi").load("s3://..."))），那么确实不需要 HMS，Metadata Table 独立工作即可。

3.如果两者都开启，会有性能冲突吗？

没有冲突。写入时的额外开销是叠加但独立的：

Hive Sync：commit 后同步分区信息到 HMS（网络调用）
Metadata Table：commit 中同步更新元数据（本地写入 log file）

两者不互斥，也不会争抢资源。

五、选型指南

推荐组合：

|---------------------|-----------|----------------|------------------------------|
| 场景 | Hive Sync | Metadata Table | 额外索引 |
| 标准数仓（SQL 查询为主） | ✅ 必须 | ✅ 推荐 | column_stats |
| 流式入湖 + 下游 SQL 消费 | ✅ 必须 | ✅ 推荐 | files 即可，按需加 column_stats |
| 高频 upsert 大表 | ✅ 按需 | ✅ 必须 | record_index + bloom_filters |
| 纯 Spark 作业间传递（路径读取） | ❌ 可省略 | ✅ 推荐 | 按需 |
| 小表 / 分区少 | ✅ 按需 | ⚠️ 开着无害 | 不需要 |

六、实践建议

两者都开启时的配置示例：

复制代码

# === Metadata Table 配置 ===
hoodie.metadata.enable=true
hoodie.metadata.index.column.stats.enable=true
hoodie.metadata.index.column.stats.column.list=dt,city,amount

# === Hive Sync 配置 ===
hoodie.datasource.hive_sync.enable=true
hoodie.datasource.hive_sync.mode=hms
hoodie.datasource.hive_sync.database=your_db
hoodie.datasource.hive_sync.table=your_table
hoodie.datasource.hive_sync.partition_fields=dt
hoodie.datasource.hive_sync.metastore.uris=thrift://metastore-host:9083

注意事项：

Hive Sync 的分区同步策略：对于高频写入场景，每次 commit 都触发 Hive Sync 可能给 HMS 带来压力。可以考虑异步同步或降低同步频率。
Metadata Table 不影响 Hive Sync 的正确性：即使 Metadata Table 损坏需要重建，HMS 中的表和分区信息不受影响，SQL 查询仍然可用（只是会回退到文件系统 LIST）。
分区注册的一致性：Hive Sync 注册分区和 Metadata Table 更新文件列表是独立的操作。在极端情况下（如 Hive Sync 延迟），可能出现"分区在 HMS 中尚未可见但 Metadata Table 已记录了该分区文件"的短暂窗口。通过路径直接读的方式不受此影响。

Metadata Table 是 Hudi 的"内功"（加速自身读写），Hive Sync 是 Hudi 的"外交"（让外部引擎能用 SQL 访问）。生产环境中通常两者都开启，各自解决各自的问题，互不干扰。