Hudi的核心概念 —— 表类型（Table Types）

最新推荐文章于 2025-05-05 00:44:42 发布

Alienware^

最新推荐文章于 2025-05-05 00:44:42 发布

阅读量1.3k

点赞数

CC 4.0 BY-SA版权

分类专栏： Hudi 文章标签：数据库 Hudi

本文链接：https://blog.csdn.net/weixin_45417821/article/details/128615523

Hudi 专栏收录该内容

10 篇文章

订阅专栏

文章介绍了Hudi存储模型中的CopyOnWrite(COW)和MergeOnRead(MOR)两种策略。COW在写入时合并数据，导致写入延迟但简单易用；MOR在读取时合并，写入快但读取延迟较高，并可通过压缩优化。Hudi支持快照查询、增量查询和读优化查询，不同表类型支持的查询类型有所不同。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Copy On Write

在 COW 表中，只有数据文件/基本文件（.parquet）,没有增量日志文件（.log.*）。对每一个新批次写入都将创建相应数据文件的新版本（新的 FileSlice），新版本文件包括旧版本文件的记录以及来自传入批次的记录（全量最新）。

由于在写入期间进行合并，COW 会产生一些写入延迟。但是 COW 的优势在于它的简单性，不需要其他表服务（如压缩），也相对容易调试。

Merge On Read

MOR 表中，包含列存的基本文件（.parquet）和行存的增量日志文件（基于行的 avro 格式，.log.*）。
顾名思义，MOR 表的合并成本在读取端。因此在写入期间我们不会合并或创建较新的数据文件版本。标记/索引完成后，对于具有要更新记录的现有数据文件，Hudi 创建增量日志文件并适当命名它们，以便它们都属于一个文件组。

在这里插入图片描述

读取端将实时合并基本文件及其各自的增量日志文件。每次的读取延迟都比较高（因为查询时进行合并），所以 Hudi 使用压缩机制来将数据文件和日志文件合并在一起并创建更新版本的数据文件。

在这里插入图片描述

用户可以选择内联或异步模式运行压缩。Hudi 也提供了不同的压缩策略供用户选择，最常用的一种是基于提交的数量。例如可以将压缩的最大增量日志配置为4。这意味着在进行 4 次增量写入后，将对数据文件进行压缩并创建更新版本的数据文件。压缩完成后，读取端只需要读取最新的数据文件，而不必关心旧版本文件。

MOR 表的写入行为，依据 index 的不同会有细微的差别：

对于 BloomFilter 这种无法对 log file 生成 index 的索引方案，对于 INSERT 消息仍然会写 base file （parquet format），只有 UPDATE 消息会 append log 文件（因为 base file 已经记录了该 UPDATE 消息的 FileGroup ID）。
对于可以对 log file 生成 index 的索引方案，例如 Flink writer 中基于 state 的索引，每次写入都是 log format，并且会不断追加和 roll over。

COW 与 MOR 的对比

	CopyOnWrite	MergeOnRead
数据延迟	高	低
查询延迟	低	高
Update(I/O) 更新成本	高（重写整个 Parquet 文件）	低（追加到增量日志）
Parquet 文件大小	低（更新成本 I/O 高）	较大（低更新成本）
写放大	大	低（取决于压缩策略）

查询类型（Query Types）

Hudi 支持如下三种查询类型：

Snapshot Queries

快照查询，可以查询指定 commit/delta commit 即时操作后表的最新快照。在读时合并（MOR）表的情况下，它通过即时合并最新文件片的基本文件和增量文件来提供近实时表（几分钟）。
对于写时复制（COW），它可以替代现有的 parquet 表（或相同基本文件类型的表），同时提供 upsert/delete 和其他写入方面的功能，可以理解为查询最新版本的 Parquet 数据文件。