一、引言
在很多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 内部优化，与外部引擎无关 |
三、它们如何协作
一个典型的查询流程中，两者各司其职：
ini
用户执行: 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 作业间传递（路径读取） | ❌ 可省略 | ✅ 推荐 | 按需 |
| 小表 / 分区少 | ✅ 按需 | ⚠️ 开着无害 | 不需要 |
六、实践建议
两者都开启时的配置示例：
ini
# === 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 访问）。生产环境中通常两者都开启，各自解决各自的问题，互不干扰。