Hudi 概念术语

一、Timeline

Hudi 数据湖可以维护很多张表，与 Hive 类似，数据存储在 HDFS 不同的目录结构中。Hudi 维护了表在不同时刻执行的所有操作的 Timeline，这有助于提供表的瞬时视图。

Timeline 是 HUDI 用来管理提交（commit）的抽象，每个 commit 都绑定一个固定时间戳，分散到时间线上。在 Timeline 上，每个 commit 被抽象为一个 HoodieInstant(Hoodie 瞬时时刻)，一个 instant 记录了一次提交(commit)的行为、时间戳、和状态，也就是说每个 HoodieInstant 包含 Action、Time、State 三个部分，下面介绍每个 HoodieInstant 对应的这三个部分。

• Instant Action

Instant Action 指的是对 Hudi 表执行的操作类型，目前包括 COMMITS、CLEANS、DELTA_COMMIT、COMPACTION、ROLLBACK、SAVEPOINT 这 6 种操作类型。

1）Commits：表示一批记录原子性的写入到一张表中。

2）Cleans:清除表中不再需要的旧版本文件。

3）Delta_commit:增量提交指的是将一批记录原子地写入 MergeOnRead 类型表，其中一些/所有数据都可以写入增量日志。

4）Compaction：将行式文件转化为列式文件。

5）Rollback:Commits 或者 Delta_commit 执行不成功时回滚数据，删除期间产生的任意文件。

6）Savepoint:将文件组标记为“saved”,cleans 执行时不会删除对应的数据。

• Instant Time

Instant Time 表示一个时间戳，这个时间戳必须是按照 Instant Action 开始执行的时间顺序单调递增的。

• Instant State

Instant State 表示在指定的时间点（Instant Time）对 Hudi 表执行操作（Instant Action）后，表所处的状态，目前包括 REQUESTED（已调度但未初始化）、INFLIGHT（当前正在执行）、COMPLETED（操作执行完成）这 3 种状态。

HUDI 的读写 API 通过 Timeline 的接口可以方便的在 commits 上进行条件筛选，对 history 和 on-going 的 commit 应用各种策略，快速筛选出需要操作的目标 commit。

下面结合官网中给出的例子理解下 Timeline，例子场景是，在 10:00~10:20 之间，要对一个 Hudi 表执行 Upsert 操作，操作的频率大约是 5 分钟执行一次,每次操作执行完成，会看到对应这个 Hudi 表的 Timeline 上，有一系列的 Commit 元数据生成。当满足一定条件时，会在指定的时刻对这些 COMMIT 进行 CLEANS 和 COMPACTION 操作，这两个操作都是在后台完成，其中在 10:05 之后执行了一次 CLEANS 操作，10:10 之后执行了一次 COMPACTION 操作。

我们看到，从数据生成到最终到达 Hudi 系统，可能存在延迟，如上图数据大约在 07:00、08:00、09:00 时生成，数据到达大约延迟了分别 3、2、1 小时多，最终生成 COMMIT 的时间才是 Upsert 的时间。通过使用 Timeline 来管理，当增量查询 10:00 之后的最新数据时，可以非常高效的找到 10:00 之后发生过更新的文件，而不必根据延迟时间再去扫描更早时间的文件，比如这里，就不需要扫描 7:00、8:00 或 9:00 这些时刻对应的文件（Buckets）。

二、文件格式及索引

Hudi 将表组织成 HDFS 上某个指定目录（basepath）下的目录结构，表被分成多个分区，分区是以目录的形式存在，每个目录下面会存在属于该分区的多个文件，类似 Hive 表，每个 Hudi 表分区通过一个分区路径（partitionpath）来唯一标识。

在每个分区下面，通过文件分组（file groups）的方式来组织，每个分组对应一个唯一的文件 ID。每个文件分组中包含多个文件分片（file slices）(一个新的 base commit time 对应一个新的文件分片，实际就是一个新的数据版本），每个文件分片包含一个 Base 文件（*.parquet），这个文件是在执行 COMMIT/COMPACTION 操作的时候生成的，同时还生成了几个日志文件（*.log.*），日志文件中包含了从该 Base 文件生成以后执行的插入/更新操作。

Hudi 采用 MVCC 设计，当执行 COMPACTION 操作时，会合并日志文件和 Base 文件，生成新的文件分片。CLEANS 操作会清理掉不用的/旧的文件分片，释放存储空间。

Hudi 会通过记录 Key 与分区 Path 组成 Hoodie Key，即 Record Key+Partition Path，通过将 Hoodie Key 映射到前面提到的文件 ID，具体其实是映射到 file_group/file_id，这就是 Hudi 的索引。一旦记录的第一个版本被写入文件中，对应的 Hoodie Key 就不会再改变了。

HUDI 的 Base file(parquet 文件)在根目录中的”
.hoodie_partition_metadata”去记录了 record key 组成的 BloomFilter，用于在 file based index 的实现中实现高效率的 key contains 检测，决定数据是新增还是更新。

三、表类型

Hudi 提供了两种表格式，Copy On Write Table (COW)和 Merge On Read Table(MOR)，他们会在数据的写入和查询性能上有所不同。

1、Copy On Write - COW

Copy On Write 简称 COW,在数据写入的时候，复制一份原来的拷贝，在其基础上添加新数据,生成一个新的持有 base file （*.parquet，对应写入的 instant time）的 File Slice，数据存储格式为 parquet 列式存储格式。用户在读取数据时，会扫描所有最新的 File Slice 下的 base file。

如上图，每一个颜色都包含了截至到其所在时间的所有数据。老的数据副本在超过一定的个数限制后，将被删除（
hoodie.cleaner.commits.retained 参数配置，保留几个历史版本，不包含最后一个版本，默认 10 个）。这种类型的表，没有 compact instant，因为写入时相当于已经 compact 了。

• 优点

读取时只需要读取对应分区的一个数据文件即可，比较高效。

• 缺点

数据写入的时候，需要复制一个先前的副本再在其基础上生成新的数据文件，这个过程比较耗时，且由于耗时，读请求读取到的数据相对就会滞后。

2、Merge On Read - MOR

Merge On Read 简称 MOR，使用列式存储（parquet）和行式存储（arvo）混合的方式来存储数据。更新时写入到增量（Delta）文件中，之后通过同步或异步的 COMPACTION 操作，生成新版本的列式格式文件。

Merge-On-Read 表存在列式格式的 Base 文件，也存在行式格式的增量（Delta）文件，新到达的更新都会写到增量日志文件中（log 文件），根据实际情况进行 COMPACTION 操作来将增量文件合并到 Base 文件上。

通过参数”hoodie.compact.inline”来开启是否一个事务完成后执行压缩操作，默认不开启。通过参数“
hoodie.compact.inline.max.delta.commits”来设置提交多少次合并 log 文件到新的 parquet 文件，默认是 5 次。这里注意，以上两个参数都是针对每个 File Slice 而言。我们同样可以控制“
hoodie.cleaner.commits.retained”来保存有多少 parquet 文件，即控制 FileSlice 文件个数。

上图中，每个文件分组都对应一个增量日志文件（Delta Log File）。COMPACTION 操作在后台定时执行。会把对应的增量日志文件合并到文件分组的 Base 文件中，生成新版本的 Base 文件。

对于查询 10:10 之后的数据的 Read Optimized Query，只能查询到 10:05 及其之前的数据，看不到之后的数据，查询结果只包含版本为 10:05、文件 ID 为 1、2、3 的文件；但是 Snapshot Query 是可以查询到 10:05 之后的数据的。

Read Optimized Query 与 Snapshot Query 是两种不同的查询类型，后文会解释到。

• 优点

由于写入数据先写 delta log，且 delta log 较小，所以写入成本较低。

• 缺点

需要定期合并整理 compact，否则碎片文件较多。读取性能较差，因为需要将 delta log 和 老数据文件合并。

3、COW&MOR 对比

四、查询类型

Hudi 数据查询对应三种查询类型，三种查询类型区别如下：

• Snapshot Query

读取所有 Partition 下每个 FileGroup 最新的 FileSlice 中的文件，Copy On Write 表读 Base(Parquet 格式)文件，Merge On Read 表读 Base(Parquet 格式)文件+Log（Avro）格式文件，也就是说这种查询模式是将到当前时刻所有数据都读取出来，如果有更新数据，读取的也是更新后数据，例如：MOR 模式下，读取对应的 Base+Log 文件就是读取当前所有数据更新后的结果数据。

• Incremantal Query

无论 Hudi 表模式是 COW 或者是 MOR 模式，这种模式可以查询指定时间戳后的增量数据，需要由用户指定一个时间戳。

• Read Optimized Query

这种模式只能查询列式格式 Base 文件中的最新数据。对于 COW 表模式，读取数据与 Snapshot 模式一样。对于 MOR 模式的数据，读取数据只会读取到 Base 文件列式数据，不会读取 Log 文件 Avro 格式数据。