Data Lake (3): Hudi Concept Terminology

​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格式数据.

​