Apache Hudi 如何构建新一代数据湖

---

1 为什么说Hudi是新一代数据湖框架

1.1 传统hdfs的缺陷

hdfs利用fsimage\edit，增量数据仅能进行append操作,不支持文件的随意修改，无法做到低延时的数据访问、毫秒级的数据存储

1.2 Hudi优势

Hudi 的设计⽬标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调了其主要⽀持Upserts、Deletes 和 Incremental 数据处理，

Hudi不存储数据，不分析数据，它负责管理数据。Hudi提供新的表格式、支持的update、insert、delete、流式摄取服务、提供了流式环境的基础。

---

2 彻底弄懂Hudi表类型

根据不同需求，Hudi提供两种表类型
COW(Copy On Write)
MOR(Merge On Read)

2.1术语介绍

在深入研究 COW 和 MOR 之前，先了解一下 Hudi 中使用的一些术语，以便更好地理解以下部分。

2.1.1 数据文件/基础文件

Hudi将数据以高效的列式存储格式（Parquet/ORC）存放，称为数据文件/基础文件，该列式存储格式在整个行业中广泛使用，数据文件和基本文件通常可以互换使用，但两者的含义相同。

2.1.2 增量日志文件

在 MOR 表格式中，更新被写入到增量日志文件中，该文件以 avro 格式存储。 这些增量日志文件始终与基本文件相关联。
假设有一个名为 data_file_1 的数据文件，对 data_file_1 中记录的任何更新都将写入到新的增量日志文件。在服务读取查询时，Hudi 将实时合并基础文件及其相应的增量日志文件中的记录。

2.1.3 文件组(FileGroup)

通常根据存储的数据量，可能会有很多数据文件。
ROM下每个数据文件及其对应的增量日志文件形成一个文件组。
在 COW 的情况下，它要简单得多，因为只有基本文件。

2.1.4 文件版本

每当数据文件发生更新时，将创建数据文件的较新版本，其中包含来自较旧数据文件和较新传入记录的合并记录。

2.1.5 文件切片(FileSlice)

对于每个文件组，可能有不同的文件版本。 因此文件切片由特定版本的数据文件及其增量日志文件组成。
对于 COW，最新的文件切片是指所有文件组的最新数据/基础文件。
对于 MOR，最新文件切片是指所有文件组的最新数据/基础文件及其关联的增量日志文件。

有了这些基础，让我们看看 COW 和 MOR 表类型。

2.2 COW

仅使用列式文件格式（例如 Parquet）存储数据。更新只需在写入期间执行同步合并来重写文件和更新版本。

由于在写入期间进行合并，COW 会产生一些写入延迟。 但是COW 的优势在于它的简单性，不需要其他表服务（如压缩），
优点：读取时，只读取对应分区的一个数据文件即可，较为高效
缺点：数据写入的时候，需要复制一个先前的副本再在其基础上生成新的数据文件，这个过程比较耗时。且由于耗时，读请求读取到的数据相对就会滞后

COW格式对 Hudi 的每一个新批次写入都将创建相应数据文件的新版本，新版本文件包括旧版本文件的记录以及来自传入批次的记录。
接下来用一个示例进行说明。

假设有 3 个文件组，其中包含如下数据文件。

进行一批新的写入，在索引后，我们发现这些更新记录属于 File group 1 和 File group 2 文件组。
然后有属于新文件组的数据插入，为其创建一个新的文件组 File group 4。

因此 Data file1 和 Data file2 都将更新文件版本，在 File group 1 之中， V2 是 V1 的内容与 传入其增量数据的记录合并。

2.2 ROM

使用列式（例如 Parquet）+ 基于行（例如 avro）文件格式的组合存储数据。

优点：由于写入数据先写 Delta log，且 Delta log较小，所以写入成本较低
缺点：需要定期合并整理compact，否则碎片文件较多。读取性能较差，因为需要将 Delta log 和 基本文件合并

成本从写入端转移到读取端。 因此在写入期间不会合并或创建较新的数据文件版本。

在每个fileid组中，现在有一个 Delta 日志文件，它保存记录的插入更新数据。记录了时间线所有新数据过程。

它有一个周期性的压缩过程，将实时压缩合并 基本文件 及其各自的 增量日志文件，更改并生成一个新版本的基本文件。（默认5次提交后进行压缩）

示例：我利用hudi在插入一次mor格式的表保存hive和hdfs，修改数据对表进行更新updata，在hadoop的50075端口中浏览文件目录，可以看到如下图

2.3 COW和MOR对比

	COW	MOR
写入延迟	较高	较低
查询延迟	较低	较高
更新成本	较高	较低
Parquet文件大小	较小	较大
写放大	Higher	Lower

• 写放大：
  假设有一个大小为 100Mb 的数据文件，并且每次更新 10% 的记录进行 4 批写入，4 次写入后，Hudi 将拥有 5 个大小为 100Mb 的 COW 数据文件。 你可以配置你的清理器（将在后面的博客中讨论）清理旧版本文件，但如果没有进行清理，最终会有 5 个版本的数据文件，总大小约500Mb。
  MOR 的情况不同，由于更新进入日志文件，写入放大保持在最低限度。 对于上面的例子，假设压缩还没有开始，在 4 次写入后，我们将有 1x100Mb 的文件和 4 个增量日志文件（10Mb） 的大小约140Mb。
• 读优化查询
  尽管 MOR 似乎有一些缺点，但它提供了不同的查询功能，例如读优化查询，这可能不会产生额外的合并成本。 如果有一个具有适当配置的异步压缩作业，那么就可以获得 MOR 的所有好处，而无需在延迟上进行大量权衡。

3 数据查询方式

Table Type	支持的查询类型
COW	快照查询 Snapshot Queries + 增量查询 Incremental Queries
ROM	快照查询 Snapshot Queries + 增量查询 Incremental Queries + 读优化查询 Read Optimized Queries

3.1 增量查询

用户给定一个数据戳，查询只会返回时间戳之后的全部数据

• 想象下面的场景：
  如果用户的数据源 “table2” 表同步12个月，期间有大量的增量数据，甚至总量达到上亿条数据。此时用户需要查询6月至今的新增数据，利用增量查询，给出6月份数据的提交时间_hoodie_commit_time，则数据只会查询到6月份之后的数据。这种查询方式对接业务需求，节约时间，实现高效的数据查询。

set hoodie.test.consume.mode=INCREMENTAL;
set hoodie.test.consume.max.commits=5;
set hoodie.test.consume.start.timestamp=20220330204717180;
select * from test.motor where `_hoodie_commit_time`>'20220330204717180';

3.2 快照查询

查询数据集的最新快照、提取接近实时的数据集

3.3 读优化查询

查询最近的一次压缩的数据文件，但无法查询最新的增量数据。
尽MOR 似乎有一些缺点，但它提供了读优化查询，这不会产生额外的合并成本。 如果有一个具有适当配置的异步压缩作业，那么就可以获得 MOR 的所有好处，而无需在延迟上进行大量权衡。