😊 如果您觉得这篇文章有用 ✔️ 的话，请给博主一个一键三连 🚀🚀🚀 吧 （点赞 🧡、关注 💛、收藏 💚）！！！您的支持 💖💖💖 将激励 🔥 博主输出更多优质内容！！！
- Hudi 核心知识点详解（一）
- Hudi 核心知识点详解（二）
4.Hudi 核心点解析
4.1 基本概念
Hudi 提供了 Hudi 表的概念，这些表支持 CRUD 操作，可以利用现有的大数据集群比如 HDFS 做数据文件存储，然后使用 SparkSQL 或 Hive 等分析引擎进行数据分析查询。
Hudi 表的三个主要组件：
- ✅ 有序的时间轴元数据，类似于数据库事务日志。
- ✅ 分层布局的数据文件：实际写入表中的数据。
- ✅ 索引（多种实现方式）：映射包含指定记录的数据集。
4.1.1 时间轴 Timeline
Hudi 核心：
- 在所有的表中维护了一个包含在不同的即时（Instant）时间对数据集操作（比如新增、修改或删除）的时间轴（Timeline）。
- 在每一次对 Hudi 表的数据集操作时都会在该表的 Timeline 上生成一个 Instant，从而可以实现在仅查询某个时间点之后成功提交的数据，或是仅查询某个时间点之前的数据，有效避免了扫描更大时间范围的数据。
- 可以高效地只查询更改前的文件（如在某个 Instant 提交了更改操作后，仅 query 某个时间点之前的数据，则仍可以 query 修改前的数据）。
Timeline 是 Hudi 用来管理提交（commit）的抽象，每个 commit 都绑定一个固定时间戳，分散到时间线上。
在 Timeline 上，每个 commit 被抽象为一个 Hoodie Instant，一个 Instant 记录了一次提交（commit）的 行为、时间戳、和 状态。
图中采用时间（小时）作为分区字段，从
10
:
00
10:00
10:00 开始陆续产生各种 commits，
10
:
20
10:20
10:20 来了一条
9
:
00
9:00
9:00 的数据，该数据仍然可以落到
9
:
00
9:00
9:00 对应的分区，通过 Timeline 直接消费
10
:
00
10:00
10:00 之后的增量更新（只消费有新 commits 的 group），那么这条延迟的数据仍然可以被消费到。
时间轴（Timeline）的实现类（位于 hudi-common-xx.jar 中），时间轴相关的实现类位于 org.apache.hudi.common.table.timeline 包下。
4.1.2 文件管理
Hudi 将 DFS 上的数据集组织到基本路径（HoodieWriteConfig.BASEPATHPROP）下的目录结构中。
数据集分为多个分区（DataSourceOptions.PARTITIONPATHFIELDOPT_KEY），这些分区与 Hive 表非常相似，是包含该分区的数据文件的文件夹。
在每个分区内，文件被组织为文件组，由文件 id 充当唯一标识。每个文件组包含多个文件切片，其中每个切片包含在某个即时时间的提交 / 压缩生成的基本列文件（.parquet）以及一组日志文件（.log），该文件包含自生成基本文件以来对基本文件的插入 / 更新。
Hudi 的 base file (parquet 文件) 在 footer 的 meta 去记录了 record key 组成的 BloomFilter，用于在 file based index 的实现中实现高效率的 key contains 检测。
Hudi 的 log （avro 文件）是自己编码的，通过积攒数据 buffer 以 LogBlock 为单位写出，每个 LogBlock 包含 magic number、size、content、footer 等信息，用于数据读、校验和过滤。
4.1.3 索引 Index
Hudi 通过索引机制提供高效的 Upsert 操作，该机制会将一个 RecordKey + PartitionPath 组合的方式作为唯一标识映射到一个文件 ID，而且这个唯一标识和文件组 / 文件 ID 之间的映射自记录被写入文件组开始就不会再改变。
- 全局索引：在全表的所有分区范围下强制要求键保持唯一，即确保对给定的键有且只有一个对应的记录。
- 非全局索引：仅在表的某一个分区内强制要求键保持唯一，它依靠写入器为同一个记录的更删提供一致的分区路径。
4.2 表的存储类型
4.2.1 数据计算模型
Hudi 是 Uber 主导开发的开源数据湖框架，所以大部分的出发点都来源于 Uber 自身场景，比如司机数据和乘客数据通过订单 Id 来做 Join 等。
在 Hudi 过去的使用场景里，和大部分公司的架构类似，采用批式和流式共存的 Lambda 架构，后来 Uber 提出增量 Incremental 模型，相对批式来讲，更加实时；相对流式而言，更加经济。
4.2.1.1 批式模型（Batch）
批式模型就是使用 MapReduce、Hive、Spark 等典型的批计算引擎，以小时任务或者天任务的形式来做数据计算。
- 延迟：小时级延迟或者天级别延迟。这里的延迟不单单指的是定时任务的时间，在数据架构里，这里的延迟时间通常是定时任务间隔时间 + 一系列依赖任务的计算时间 + 数据平台最终可以展示结果的时间。数据量大、逻辑复杂的情况下，小时任务计算的数据通常真正延迟的时间是 2 − 3 2-3 2−3 小时。
- 数据完整度：数据较完整。以处理时间为例，小时级别的任务，通常计算的原始数据已经包含了小时内的所有数据，所以得到的数据相对较完整。但如果业务需求是事件时间，这里涉及到终端的一些延迟上报机制，在这里，批式计算任务就很难派上用场。
- 成本：成本很低。只有在做任务计算时，才会占用资源，如果不做任务计算，可以将这部分批式计算资源出让给在线业务使用。从另一个角度来说成本是挺高的，如原始数据做了一些增删改查，数据晚到的情况，那么批式任务是要全量重新计算。
4.2.1.2 流式模型（Stream）
流式模型，典型的就是使用 Flink 来进行实时的数据计算。
- 延迟：很短，甚至是实时。
-
数据完整度：较差。因为流式引擎不会等到所有数据到齐之后再开始计算，所以有一个
watermark的概念，当数据的时间小于watermark时，就会被丢弃，这样是无法对数据完整度有一个绝对的保障。在互联网场景中，流式模型主要用于活动时的数据大盘展示，对数据的完整度要求并不算很高。在大部分场景中，用户需要开发两个程序，一是流式数据生产流式结果，二是批式计算任务，用于次日修复实时结果。 -
成本：很高。因为流式任务是常驻的，并且对于多流 Join 的场景，通常要借助内存或者数据库来做
state的存储，不管是序列化开销，还是和外部组件交互产生的额外 IO，在大数据量下都是不容忽视的。
4.2.1.3 增量模型（Incremental）
针对批式和流式的优缺点，Uber 提出了 增量模型（Incremental Mode），相对批式来讲，更加实时；相对流式而言，更加经济。
增量模型，简单来讲，是以 mini batch 的形式来跑准实时任务。Hudi 在增量模型中支持了两个最重要的特性：
-
Upsert：这个主要是解决批式模型中，数据不能插入、更新的问题，有了这个特性，可以往 Hive 中写入增量数据，而不是每次进行完全的覆盖。（Hudi 自身维护了key➡file的映射，所以当upsert时很容易找到key对应的文件） -
Incremental Query：增量查询，减少计算的原始数据量。以 Uber 中司机和乘客的数据流 Join 为例，每次抓取两条数据流中的增量数据进行批式的 Join 即可，相比流式数据而言，成本要降低几个数量级。
4.2.2 查询类型（Query Type）
Hudi 支持三种不同的查询表的方式：Snapshot Queries、Incremental Queries 和 Read Optimized Queries。
4.2.2.1 快照查询（Snapshot Queries）
- 查询某个增量提交操作中数据集的最新快照，先进行动态合并最新的基本文件（
Parquet）和增量文件（Avro）来提供近实时数据集（通常会存在几分钟的延迟）。 - 读取所有
partition下每个 FileGroup 最新的 FileSlice 中的文件，Copy On Write 表读parquet文件，Merge On Read 表读parquet+log文件。
4.2.2.2 增量查询（Incremental Queries）
- 仅查询新写入数据集的文件，需要指定一个 Commit / Compaction 的即时时间（位于 Timeline 上的某个 Instant）作为条件，来查询此条件之后的新数据。
- 可查看自给定
commit/delta commit即时操作以来新写入的数据，有效的提供变更流来启用增量数据管道。
4.2.2.3 读优化查询（Read Optimized Queries）
- 直接查询基本文件（数据集的最新快照），其实就是列式文件（Parquet）。并保证与非 Hudi 列式数据集相比，具有相同的列式查询性能。
- 可查看给定的
commit/compact即时操作的表的最新快照。 - 读优化查询和快照查询相同仅访问基本文件，提供给定文件片自上次执行压缩操作以来的数据。通常查询数据的最新程度的保证取决于压缩策略。
4.2.3 Hudi 支持表类型
Hudi 提供两类型表：写时复制（Copy on Write，COW）表和 读时合并（Merge On Read，MOR）表。
- 对于 Copy-On-Write Table，用户的
update会重写数据所在的文件，所以是一个写放大很高，但是读放大为 0 0 0，适合 写少读多 的场景。 - 对于 Merge-On-Read Table，整体的结构有点像 LSM-Tree，用户的写入先写入到
delta data中，这部分数据使用行存，这部分delta data可以手动merge到存量文件中，整理为parquet的列存结构。
4.2.3.1 写时复制表（COW）
Copy on Write 简称 COW，顾名思义，它是在数据写入的时候，复制一份原来的拷贝，在其基础上添加新数据。
正在读数据的请求，读取的是最近的完整副本，这类似 MySQL 的 MVCC 的思想。
- ✅ 优点：读取时，只读取对应分区的一个数据文件即可，较为高效。
- ⭕ 缺点：数据写入的时候，需要复制一个先前的副本再在其基础上生成新的数据文件，这个过程比较耗时。
COW 表主要使用列式文件格式（Parquet）存储数据，在写入数据过程中，执行同步合并，更新数据版本并重写数据文件，类似 RDBMS 中的 B-Tree 更新。
- 更新
update：在更新记录时，Hudi 会先找到包含更新数据的文件，然后再使用更新值（最新的数据）重写该文件，包含其他记录的文件保持不变。当突然有大量写操作时会导致重写大量文件，从而导致极大的 I/O 开销。 - 读取
read：在读取数据时，通过读取最新的数据文件来获取最新的更新，此存储类型适用于少量写入和大量读取的场景。
4.2.3.2 读时合并表（MOR）
Merge On Read 简称 MOR，新插入的数据存储在 delta log 中，定期再将 delta log 合并进行 parquet 数据文件。
读取数据时，会将 delta log 跟老的数据文件做 merge，得到完整的数据返回。下图演示了 MOR 的两种数据读写方式。
- ✅ 优点：由于写入数据先写
delta log，且delta log较小，所以写入成本较低。 - ⭕ 缺点：需要定期合并整理
compact，否则碎片文件较多。读取性能较差，因为需要将delta log和老数据文件合并。
MOR 表是 COW 表的升级版，它使用列式（parquet）与行式（avro）文件混合的方式存储数据。在更新记录时，类似 NoSQL 中的 LSM-Tree 更新。
- 更新：在更新记录时，仅更新到增量文件（
Avro）中，然后进行异步（或同步）的compaction，最后创建列式文件（parquet）的新版本。此存储类型适合频繁写的工作负载，因为新记录是以追加的模式写入增量文件中。 - 读取：在读取数据集时，需要先将增量文件与旧文件进行合并，然后生成列式文件成功后，再进行查询。
4.2.3.3 COW VS MOR
对于写时复制（COW）和读时合并（MOR）writer 来说，Hudi 的 WriteClient 是相同的。
- 🚀 COW 表，用户在
snapshot读取的时候会扫描所有最新的FileSlice下的base file。 - 🚀 MOR 表，在
READ OPTIMIZED模式下，只会读最近的经过compaction的commit。
| 权衡 | 写时复制 COW | 读时合并 MOR |
|---|---|---|
| 数据延迟 | 更高 | 更低 |
| 更新代价（I/O） | 更高（重写整个 parquet 文件） |
更低（追加到增量日志） |
| Parquet 文件大小 | 更小（高更新代价（I/O）） | 更大（低更新代价） |
| 写放大 | 更高 | 更低（取决于压缩策略） |
| 适用场景 | 写少读多 | 写多读少 |
4.2.4 数据写操作类型
在 Hudi 数据湖框架中支持三种方式写入数据：UPSERT（插入更新）、INSERT（插入）和 BULK INSERT（写排序）。
-
UPSERT：默认行为，数据先通过index打标（INSERT/UPDATE），有一些启发式算法决定消息的组织以优化文件的大小。 -
INSERT：跳过index，写入效率更高 -
BULK INSERT：写排序，对大数据量的 Hudi 表初始化友好，对文件大小的限制best effort（写 HFile）。
4.2.4.1 写流程（UPSERT）
1️⃣ Copy On Write 类型表，UPSERT 写入流程
- 第一步：先对
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。
2️⃣ Merge On Read 类型表，UPSERT 写入流程
- 第一步：先对
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一个新的。
4.2.4.2 写流程（INSERT）
1️⃣ Copy On Write 类型表，INSERT 写入流程文章来源：https://www.toymoban.com/news/detail-775718.html
- 第一步：先对
records按照record key去重（可选）； - 第二步：不会创建
Index； - 第三步：如果有小的 base file 文件，
merge base file，生成新的FileSlice + base file，否则直接写新的FileSlice + base file；
2️⃣ Merge On Read 类型表，INSERT 写入流程文章来源地址https://www.toymoban.com/news/detail-775718.html
- 第一步：先对
records按照record key去重（可选）； - 第二步：不会创建
Index； - 第三步：如果
log file可索引，并且有小的 FileSlice，尝试追加或写最新的log file；如果log file不可索引，写一个新的FileSlice + base file。
到了这里，关于【大数据】Hudi 核心知识点详解（二）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
