湖仓一体之Apache Hudi

原创已于 2026-05-17 11:03:33 修改 · 525 阅读

10 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#Hudi #湖仓一体

于 2026-05-17 11:02:56 首次发布

大数据同时被 2 个专栏收录

99 篇文章

订阅专栏

数据湖

9 篇文章

订阅专栏

Apache Hudi 详细介绍

一、Hudi 是什么

Apache Hudi
Hudi（Hadoop Upserts Deletes and Incrementals）是一个面向数据湖（Data Lake）的开放表格式（Open Table Format）与数据管理框架，主要解决：

数据湖实时写入
Upsert（更新插入）
Delete（删除）
增量查询
流批一体
小文件治理
数据版本管理
CDC（Change Data Capture）

本质上：

Hudi = “支持数据库能力的数据湖表格式”

它让：

HDFS
S3
OSS
GCS

上的 Parquet 文件，具备：

类数据库事务
ACID
实时更新
时间旅行
增量消费

能力。

官方地址：

Apache Hudi Official Site

GitHub：

Apache Hudi GitHub

二、为什么会出现 Hudi

传统 Hive 数仓存在几个问题：

问题	原因
只能 Append	Parquet 文件不可更新
更新代价巨大	UPDATE 本质是重写整个分区
实时性差	T+1
小文件严重	Streaming 写入
无增量消费	只能全表扫描
CDC 困难	无变更日志
流批割裂	Kafka/Hive 两套系统

例如：

订单表：

order_id	status
1	paid

后面变成：

order_id	status
1	shipped

Hive 需要：

重刷分区
重写文件

代价巨大。

于是出现：

Apache Hudi
Apache Iceberg
Delta Lake

三大湖仓表格式。

三、Hudi 核心目标

Hudi 的核心目标：

目标	说明
流式写入	支持 Kafka/Flink/Spark
实时查询	秒级可见
Upsert/Delete	类数据库更新
增量拉取	CDC
ACID	事务一致性
小文件治理	自动 Compaction
时间旅行	查询历史版本
流批一体	Streaming + Batch

四、Hudi 架构

整体架构

                +------------------+
                | Kafka / CDC / MQ |
                +------------------+
                         |
                  Flink / Spark
                         |
                 Hudi Write Client
                         |
      +--------------------------------------+
      |             Hudi Table               |
      |--------------------------------------|
      | .hoodie/ 元数据                      |
      | parquet base files                   |
      | log files(avro log)                  |
      +--------------------------------------+
                         |
         +-------------------------------+
         | Hive / Spark / Trino / Presto |
         +-------------------------------+

五、Hudi 核心概念

1. Table Type（表类型）

Hudi 最核心的概念。

支持两种：

类型	特点
Copy On Write（COW）	更新时重写 Parquet
Merge On Read（MOR）	更新写 Log，异步合并

六、COW（Copy On Write）

工作原理

更新数据时：

旧 parquet
    ↓
读取
    ↓
合并新数据
    ↓
生成新 parquet

即：

Rewrite File

特点

优点	缺点
查询快	写入慢
适合 OLAP	更新代价高
无 Log 合并	IO 大

适用场景

适合：

BI
报表
查询多
更新少

例如：

用户画像
商品维表
宽表

七、MOR（Merge On Read）

工作原理

更新：

新数据
   ↓
append log file

查询时：

base parquet + log
        ↓
merge

后台：

compaction

合并生成新 parquet。

MOR 架构

base file.parquet
delta log1.avro
delta log2.avro
delta log3.avro

特点

优点	缺点
写入快	查询慢
实时性强	需要 compaction
Streaming 友好	架构复杂

适合场景

CDC
实时数仓
高频更新
IoT
用户行为

八、Hudi Timeline（时间线）

Hudi 最大特色之一。

所有操作：

commit
clean
compaction
rollback

都记录到：

.hoodie/

中。

Timeline 示例

20250510120000.commit
20250510121000.commit
20250510121500.compaction

Timeline 的价值

支持：

能力	说明
Time Travel	查询历史版本
增量消费	获取变更
回滚	rollback
审计	操作历史

九、Hudi 文件布局

table/
 ├── .hoodie/
 ├── partition1/
 │    ├── file1.parquet
 │    ├── file1.log
 │
 ├── partition2/

十、Record Key

类似数据库主键。

例如：

order_id

用于：

去重
更新定位
Upsert

十一、PreCombine Key

用于解决：

同一主键多条记录冲突

例如：

ts 时间戳

保留最新记录。

十二、Index（索引）

Hudi 必须知道：

某条数据在哪个文件

因此需要索引。

Hudi 索引类型

索引	特点
Bloom Index	默认
Simple Index	简单
HBase Index	外部索引
Bucket Index	类 Hash
Metadata Index	元数据索引

Bloom Index

核心思想：

文件 -> bloom filter -> 判断 key 是否存在

避免全表扫描。

十三、Compaction（压缩）

MOR 核心机制。

为什么需要

Log 文件不断增长：

.parquet + .log + .log + .log

查询越来越慢。

Compaction 作用

把：

base + log

合并成：

new parquet

Compaction 策略

策略	说明
按时间	定时
按 log 数量	阈值
按文件大小	自动

十四、Clustering（聚簇）

用于：

小文件治理
文件重排
数据排序

类似：

OPTIMIZE

作用

例如：

10000 小文件
→
100 大文件

提升查询性能。

十五、Cleaner（清理）

删除旧版本文件。

否则：

版本越来越多

存储爆炸。

Cleaner 策略

策略	说明
KEEP_LATEST_COMMITS	保留最近 commit
KEEP_LATEST_FILE_VERSIONS	保留文件版本

十六、Incremental Query（增量查询）

Hudi 非常强大的能力。

例如：

begin_time='20250510'

只获取：

新增/更新数据

价值

可实现：

CDC
增量同步
流式 ETL
数据订阅

十七、Time Travel（时间旅行）

查询历史版本。

例如：

as.of.instant='20250510120000'

十八、ACID 事务

Hudi 支持：

能力	支持
原子性	YES
一致性	YES
隔离性	MVCC
持久性	YES

十九、MVCC

Hudi 使用：

Multi Version Concurrency Control

实现：

读写隔离
Snapshot Query

二十、查询类型

1. Snapshot Query

查：

最新数据

2. Read Optimized Query

只读 parquet：

忽略 log

适合：

BI
OLAP

3. Incremental Query

只读变更。

二十一、Hudi 写入模式

INSERT

新增。

UPSERT

更新插入。

最常用。

BULK_INSERT

大批量导入。

DELETE

删除。

二十二、Flink + Hudi

这是当前主流。

架构

Kafka CDC
    ↓
Flink
    ↓
Hudi
    ↓
Trino/Spark

优势

优势	说明
实时写入	秒级
Exactly Once	精确一次
CDC 支持	MySQL binlog
流批一体	YES

二十三、Spark + Hudi

早期主流方案。

特点

优势	缺点
生态成熟	Streaming 弱
批处理强	延迟高

二十四、Hudi 元数据表（Metadata Table）

用于解决：

S3 LIST 太慢

问题。

存储内容

内容	说明
文件列表	file listing
column stats	列统计
bloom filter	bloom 索引

二十五、Hudi 与 Iceberg 对比

对比	Hudi	Iceberg
更新能力	强	中
CDC	强	一般
实时写入	强	中
流式支持	强	一般
查询性能	中	强
大分析	一般	强
小文件治理	强	强
时间旅行	支持	支持
生态	强	非常强

二十六、Hudi 与 Delta Lake 对比

对比	Hudi	Delta
开源开放	Apache	Linux Foundation
Streaming	强	强
Flink 支持	强	一般
Spark 绑定	弱	强
云生态	中	Databricks 强

二十七、Hudi 典型应用场景

1. CDC 实时数仓

MySQL -> Flink CDC -> Hudi

2. 用户画像

频繁更新。

3. IoT

设备状态持续变化。

4. 风控

实时特征更新。

5. AI Feature Store

在线离线特征同步。

结合：

Kafka
Flink
Hudi
Redis

实现实时特征平台。

二十八、Hudi 在 Lakehouse 中的位置

Lakehouse：

                +----------------+
                | BI / AI / SQL |
                +----------------+
                         |
            +------------------------+
            | Iceberg / Hudi / Delta |
            +------------------------+
                         |
             Object Storage / HDFS

Hudi 提供：

表格式
事务
更新
增量

能力。

二十九、Hudi 核心优势总结

优势	说明
Upsert 强	最大优势
CDC 强	实时增量
Flink 友好	Streaming 强
实时性强	秒级
小文件治理	完善
数据版本	timeline
流批一体	YES

三十、Hudi 的不足

问题	说明
查询性能弱于 Iceberg	MOR merge 成本高
架构复杂	timeline/log/compaction
运维复杂	compaction 调优
文件管理复杂	小文件问题严重时较难
大分析场景一般	不如 Iceberg

三十一、什么时候选 Hudi

适合选 Hudi

如果你的场景：

高频更新
CDC
实时数仓
流式写入
增量消费

优先选 Hudi。

不适合

如果：

超大规模 OLAP
复杂分析
超高并发查询

更推荐：

Apache Iceberg
Delta Lake

三十二、未来趋势

当前趋势：

Hudi 越来越偏：

实时湖仓
CDC 平台
Streaming Lakehouse

尤其：

Flink CDC
实时数据同步
AI Feature Store
实时画像

领域。

三十三、企业使用案例

很多公司使用：

公司	场景
Uber	原始作者
ByteDance	实时数仓
腾讯	湖仓
阿里	CDC
快手	实时画像

三十四、总结

一句话总结：

Hudi 是“最像数据库”的数据湖表格式。

它最强的能力：

Upsert
CDC
Incremental Query
实时流式写入

尤其适合：

Flink + Kafka + 实时数仓

架构。

而：

Apache Iceberg 更偏：
- 大规模分析
- 高性能查询
- 云数仓
Delta Lake 更偏：
- Spark/Databricks 生态