Hudi技术内幕：Table Types全解析

一、引言

Hudi 提供两种表类型，让用户根据自身的 SLA 要求在「写入放大」与「读取放大」之间做出显式权衡，它们的本质区别在于 数据写入时是否立即合并更新到基础文件（Base File）。

二.Copy-on-Write（COW）表

COW 表在每次写入（Insert/Update/Delete）时，会将受影响的文件进行原地重写，即找到包含目标记录的 Parquet 文件，将新数据与旧数据合并后，生成一个新版本的 Parquet 文件。

文件布局：

table_path/
├── .hoodie/                          # 元数据目录（Timeline）
│   ├── 20240101120000.commit         # 已完成的提交
│   ├── 20240101130000.commit
│   └── ...
├── partition=2024-01-01/
│   ├── file_group_1/
│   │   └── base_file_v3.parquet      # 仅保留最新的 base file
│   ├── file_group_2/
│   │   └── base_file_v2.parquet
│   └── ...
└── ...

特性表现：

维度	表现
写入放大	高 --- 每次更新需重写整个 Parquet 文件
读取放大	低 --- 读取时无需合并，直接扫描 Parquet
查询延迟	低 --- 数据已预合并，等同于纯 Parquet 扫描
写入延迟	高 --- 需要读取-合并-重写的完整流程
存储效率	中等 --- 无额外 log 文件开销

三.Merge-on-Read（MOR）表

MOR 表将写入操作分为两个阶段：

1. 写入阶段：增量更新以 日志文件（Log File） 的形式追加写入，不修改已有的 Base File
2. 压缩阶段（Compaction）：后台异步（或同步）将 Log File 与 Base File 合并，生成新的 Base File

文件布局：

table_path/
├── .hoodie/
│   ├── 20240101120000.deltacommit    # deltacommit 表示 MOR 的增量提交
│   ├── 20240101130000.deltacommit
│   ├── 20240101140000.commit         # compaction 完成后的 commit
│   └── ...
├── partition=2024-01-01/
│   ├── file_group_1/
│   │   ├── base_file.parquet         # 基础文件
│   │   ├── .log_file_1               # 增量日志
│   │   ├── .log_file_2               # 增量日志
│   │   └── ...
│   └── ...
└── ...

特性表现：

维度	表现
写入放大	低 --- 仅追加写 Log File
读取放大	可变 --- 取决于查询类型和 compaction 频率
写入延迟	低 --- 追加写，无需重写 base file
查询延迟	Snapshot Query 较高（需实时合并），Read Optimized Query 低
存储效率	有额外 log 文件开销，compaction 后恢复

四.COW vs MOR 对比总览

┌──────────────────────────────────────────────────────────────────┐
│                  COW vs MOR 核心对比                               │
├────────────────┬──────────────────────┬──────────────────────────┤
│     维度       │   Copy-on-Write      │    Merge-on-Read         │
├────────────────┼──────────────────────┼──────────────────────────┤
│ 数据写入方式   │ 同步重写 Base File    │ 追加 Log File            │
│ 数据读取方式   │ 直接读 Base File      │ Base + Log 实时合并      │
│ 写入延迟       │ 较高                 │ 较低                     │
│ 查询性能       │ 最优（无合并开销）    │ Snapshot较慢/RO Query快  │
│ 适用写入模式   │ 批量写入/低频更新     │ 高频更新/流式写入        │
│ Compaction     │ 不需要               │ 需要（异步/同步）        │
│ 文件类型       │ 仅 Parquet           │ Parquet + Log (Avro等)   │
│ Timeline 标记  │ commit               │ deltacommit + commit     │
└──────────────────────────────────────────────────────────────────┘

五、最佳实践

1.COW 表最佳实践

// Hudi 1.x 配置示例 - COW 表
hoodie.table.type = COPY_ON_WRITE

// 文件大小控制 - 避免小文件问题
hoodie.parquet.max.file.size = 128MB
hoodie.parquet.small.file.limit = 100MB

// 索引选择 - 影响 upsert 性能
hoodie.index.type = BUCKET                  // 大表推荐 Bucket Index
// hoodie.index.type = BLOOM               // 中小表可用 Bloom Index

// 合理设置并行度
hoodie.upsert.shuffle.parallelism = 200
hoodie.insert.shuffle.parallelism = 200

// Clustering 优化读取性能
hoodie.clustering.inline = true
hoodie.clustering.inline.max.commits = 4

• 控制写入批次大小，避免过于频繁的小批次写入导致大量文件重写
• 使用 Clustering 定期整理文件布局，优化查询时的数据局部性
• 选择合适的索引类型，Bucket Index 对大表性能更稳定
• 合理设置文件大小，过小导致文件过多，过大导致单次重写代价高

2.MOR 表最佳实践

// Hudi 1.x 配置示例 - MOR 表
hoodie.table.type = MERGE_ON_READ

// Log 文件控制
hoodie.logfile.max.size = 1GB
hoodie.logfile.data.block.max.size = 256MB

// Compaction 策略 - 核心配置
hoodie.compact.inline = false               // 生产环境建议异步 compaction
hoodie.compact.inline.max.delta.commits = 5 // 每 5 次 delta commit 触发

// Compaction 策略选择
hoodie.compaction.strategy = org.apache.hudi.table.action.compact.strategy.BoundedIOCompactionStrategy
hoodie.compaction.target.io = 512000        // 限制单次 compaction IO

// 索引选择
hoodie.index.type = BUCKET

• Compaction 策略是 MOR 表的核心：需要根据数据新鲜度需求和集群资源合理调度
• 生产环境建议使用 异步 Compaction，避免阻塞写入流程
• 监控 Log File 积压情况，过多未 compact 的 log 会严重影响 Snapshot Query 性能
• 对于 Read Optimized Query 的场景，确保 Compaction 频率满足数据新鲜度 SLA

3.Compaction 调优策略