Hudi原理学习

最新推荐文章于 2024-10-03 21:45:41 发布

叶不修233

最新推荐文章于 2024-10-03 21:45:41 发布

阅读量1.4k

点赞数 17

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

本文链接：https://blog.csdn.net/weixin_56039103/article/details/137644447

版权

大数据专栏收录该内容

3 篇文章 0 订阅

订阅专栏

本文详细介绍了Hudi，一个基于Hadoop的数据湖平台，涵盖了其时间线设计、文件布局、表类型、查询类型以及索引机制。重点讲解了UPSERT和INSERT操作流程，帮助读者理解Hudi如何实现实时数据处理和高效查询。

摘要由CSDN通过智能技术生成

Hudi原理学习

一、Hudi是什么

Hudi（Hadoop Upsert Delete and Incremental）是什么：围绕数据库内核构建的流式数据湖平台（Streaming Data Lake Platform）
简而言之，它是一个对计算和存储进行解耦的数据湖方案：
	数据存储：底层的数据可以存储到hdfs、s3、azure、alluxio 等存储
	计算引擎：可以使用spark/flink 计算引擎来消费 kafka、pulsar 等消息队列的数据
	查询引擎：支持的查询引擎有trino、hive、impala、spark、presto 等

二、Hudi的四个核心概念

根据官网推荐的学习路线，需要熟悉以下四个核心概念

（1）时间线

官方文档：Hudi 的核心是维护在不同时间对表执行的所有操作，这有助于提供表的即时视图，同时还有效地支持按到达顺序检索数据。

个人理解：对表的所有操作都带时间。

Hudi 即时由以下组件组成：

Instant action：对表执行的操作类型
Instant time：即时时间通常是一个时间戳（例如：20190117010349），它按操作开始时间的顺序单调增加。
state：即时的当前状态

其中Instant action：对表执行的操作类型，执行的关键操作包括：

COMMITS- 提交表示将一批记录原子写入表中。
CLEANS- 后台活动，用于删除表中不再需要的旧版本文件。
DELTA_COMMIT- 增量提交是指将一批记录原子写入 MergeOnRead 类型表，其中部分/全部数据可以只写入增量日志。
COMPACTION- 用于协调 Hudi 中差异数据结构的后台活动，例如：将更新从基于行的日志文件移动到列格式。在内部，压缩表现为时间轴上的特殊提交
ROLLBACK- 指示提交/增量提交不成功并回滚，删除在此类写入期间生成的任何部分文件
SAVEPOINT- 将某些文件组标记为“已保存”，以便清理器不会删除它们。它有助于在发生灾难/数据恢复的情况下将表还原到时间线上的某个点。

任何给定的时刻都可以是处于以下状态之一

REQUESTED- 表示已计划操作，但尚未启动
INFLIGHT- 表示当前正在执行操作
COMPLETED- 表示在时间轴上完成操作

有两个时间上的概念：arrival time-到达时间、event time-事件发生时间，需要理解。

按照官网上的案例：

例如：预计9点要更新一批数据，但这批数据延迟到达，10点20才到。
数据仍然被存储到更旧时间段的文件夹里，也就是9点。
而这批数据的提交时间是10：20。
这样的处理方式保证了数据的完整性，和查询时的便捷性。
在时间线的帮助下，可以直接尝试获取10：00以后成功提交的所有新数据的增量，高效地使用已经更改的文件，而不需要扫描之前的时间段。

（2）文件布局

>表1
>……
>表n
	>分区1
	>……
    >分区n
    	>文件组1（由文件 ID 唯一标识）
    	>……
    	>文件组n（由文件 ID 唯一标识）
    		>文件切片1
    		>……
    		>文件切片n
    			>1个基本文件 （.parquet）
    			>n个日志文件 （.log.*）（包含自生成基本文件以来对基本文件的插入/更新）

压缩：合并日志和基本文件以生成新的文件切片（.parquet）
清理：删除未使用/较旧的文件切片（.parquet），以回收文件系统上的空间。

（3）表类型

Hudi支持两种表类型

表类型	支持的查询类型	对比	含义
`Copy On Write`-写入时复制	快照查询 + 增量查询	数据延迟-高查询延迟-低更新成本（I/O）-高文件大小-小写入放大-高	官方说明：完全使用柱状文件格式（如parquet）来存储数据。更新时只需在写的过程中进行同步合并，并重写文件。个人理解：这种表类型的文件切片里只有一个基本文件（.parquet），每次更新就是重写这个基本文件。
`Merge On Read`-读取时合并	快照查询 + 增量查询 + 读取优化查询	数据延迟-低查询延迟-高更新成本（I/O）-低文件大小-大写入放大-较低，取决于压缩策略	官方说明：使用列（如parquet）和行（如avro）文件格式的组合来存储数据。更新被记录到delta文件中，随后被压缩以同步或异步产生新版本的柱状文件。个人理解：这种表类型的文件切片里包含一个基本文件（.parquet）和n个日志文件，每次更新会将更新写入日志文件中，执行定期压缩操作会根据日志文件生成新版本的基本文件（.parquet）。

（4）查询类型

Hudi 支持三种查询类型

快照查询：查询查看给定提交或压缩操作时表的最新快照。在读取表上合并的情况下，它通过合并公开近实时数据（几分钟）动态最新文件片的基本文件和增量文件。对于写入表上的复制，它提供了现有镶木地板表的直接替代品，同时提供更新/删除和其他写入端功能。
增量查询：查询仅看到自给定提交/压缩以来写入表的新数据。这有效地提供了更改流以启用增量数据管道。
读取优化查询：查询查看截至给定提交/压缩操作的表的最新快照。仅公开最新文件切片中的基/列式文件，并保证与非 Hudi 列式表相比，列式查询性能相同。

查询类型	查询的数据	含义
`Snapshot Queries`-快照查询	实时数据	分为两种情况： 1.`Copy On Write`：读 parquet 文件 2.`Merge On Read`：读 parquet + log 文件组合得到的最新数据
`Incremental Queries`-增量查询	增量数据	分为两种情况： 1.`Copy On Write`：查询parquet 文件中指定时间之后更新过的数据 2.`Merge On Read`：查询指定时间后parquet 文件和log 文件组合得到的更新数据
`Read Optimized Queries`-读取优化查询	最近快照	分为两种情况： 1.`Copy On Write`：读 parquet 文件 2.`Merge On Read`：读 parquet 文件

三、其它概念

（1）索引 Index

Hudi通过索引机制提供高效的Upsert操作，该机制会将一个RecordKey+PartitionPath组合的方式作为唯一标识映射到一个文件ID，而且，这个唯一标识和文件组/文件ID之间的映射自记录被写入文件组开始就不会再改变。

目前，Hudi 支持以下索引选项。

Bloom Index (default)：采用由主键（record key）构建的布隆过滤器，还可以选择使用主键范围修剪候选文件。
Simple Index：针对从存储表中提取的键执行传入更新/删除记录的精益联接。
HBase Index：管理外部 Apache HBase 表中的索引映射。
Bring your own implementation：您可以扩展此公共 API 以实现自定义索引。

按照类型分，索引可以分为全局索引和非全局索引

Bloom Index (default)和Simple Index都有全局选项，HBase Index则本质上就是一个全局索引。

全局索引:全局索引在表的所有分区中强制键的唯一性，即保证表中对于给定的记录键只存在一条记录。全局索引提供了更强的保证，但是更新/删除成本会随着表O(表的大小)的大小而增加，这对于较小的表来说仍然是可以接受的。
非全局索引:另一方面，默认索引实现仅在特定分区内强制执行此约束。可以想象，非全局索引依赖于写入器在更新/删除期间为给定的记录键提供相同的分区路径，但是可以提供更好的性能，因为索引查找操作变成O(更新/删除的记录数量)，并且可以很好地扩展写入量。

（2）写操作流程

Hudi数据湖框架中支持三种方式写入数据：UPSERT（插入更新）、INSERT（插入）和BULK INSERT（写排序）。

3.2.1 UPSERT

Copy On Write

第一步：先对 records 按照 record key 去重；

第二步：首先对这批数据创建索引 (HoodieKey => HoodieRecordLocation)；通过索引区分哪些 records 是 update，哪些 records 是 insert（key 第一次写入）；

第三步：对于 update 消息，会直接找到对应 key 所在的最新 FileSlice 的 base 文件，并做 merge 后写新的 base file (新的 FileSlice)；

第四步：对于 insert 消息，会扫描当前 partition 的所有 SmallFile（小于一定大小的 base file），然后 merge 写新的 FileSlice；如果没有 SmallFile，直接写新的 FileGroup + FileSlice；
Merge On Read

第一步：先对 records 按照 record key 去重（可选）

第二步：首先对这批数据创建索引 (HoodieKey => HoodieRecordLocation)；通过索引区分哪些 records 是 update，哪些 records 是 insert（key 第一次写入）

第三步：如果是 insert 消息，如果 log file 不可建索引（默认），会尝试 merge 分区内最小的 base file （不包含 log file 的 FileSlice），生成新的 FileSlice；如果没有 base file 就新写一个 FileGroup + FileSlice + base file；如果 log file 可建索引，尝试 append 小的 log file，如果没有就新写一个 FileGroup + FileSlice + base file

第四步：如果是 update 消息，写对应的 file group + file slice，直接 append 最新的 log file（如果碰巧是当前最小的小文件，会 merge base file，生成新的 file slice）log file 大小达到阈值会 roll over 一个新的

3.2.2 INSERT

Copy On Write

第一步：先对 records 按照 record key 去重（可选）；

第二步：不会创建 Index；

第三步：如果有小的 base file 文件，merge base file，生成新的 FileSlice + base file，否则直接写新的 FileSlice + base file；
Merge On Read

第一步：先对 records 按照 record key 去重（可选）；

第二步：不会创建 Index；

第三步：如果 log file 可索引，并且有小的 FileSlice，尝试追加或写最新的 log file；如果 log file 不可索引，写一个新的 FileSlice + base file；