Hudi 原理 | Apache Hudi 如何维护最佳文件大小-轻识

Apache Hudi 是一种数据湖平台技术，可提供构建和管理数据湖所需的多种功能。Hudi 提供的一项重要功能是自动管理文件大小，用户不需要手动维护。由于查询引擎不得不多次打开/读取/关闭文件，以计划和执行查询，因此拥有大量小文件将使其难以实现良好的查询性能。但是对于流数据湖用例而言，固有的摄入量将最终具有较小的写入量，如果不进行特殊处理，则可能导致大量小文件。

During Write vs After Write

解决小文件引起的系统可伸缩性问题，常见的方法是写入非常小的文件然后将它们合并在一起，但可能会因为把小文件暴露在查询中而违反查询SLA。实际上，可以通过运行Clustering 轻松地在 Hudi 表上执行此操作。

此篇文章讨论初始写入期间在 Hudi 中进行文件大小优化的情况，因此不必为了调整文件大小而再次重新写入所有数据。如果要同时具有(a)自我管理的文件大小和(b)避免将小文件暴露给查询，自动调整文件大小的功能将帮助你解决上述问题。

执行 Insert/Upsert 操作时，Hudi 能够保持配置的目标文件大小。注意 bulk_insert 操作不提供此功能，类似于 spark.write.parquet。

Configs

为了说明问题，只介绍 COPY_ON_WRITE 表。

在我们深入研究算法之前，先看看几个配置。

max file size(hoodie.parquet.max.file.size)：给定数据文件的最大大小，Hudi将努力把文件大小保持在这个配置值上。
soft file limit(hoodie.parquet.small.file.limit)：最大文件大小，低于这个大小的数据文件被认为是小文件。
insert split size(hoodie.copyonwrite.insert.split.size)：单个分区的插入分组数量。这个值应该与单个文件中的记录数相匹配（可以根据最大文件大小和每个记录大小来确定）。

例如，如果你的第一个配置值是120MB，第二个配置值设置为100MB，那么任何大小<100MB的文件将被视为小文件。

如果你想关闭这个功能，把 Soft file limit 的配置值设为0。

Example

比方说，这是一个特定分区的数据文件分布

让我们假设最大文件大小和小文件大小限制的配置值为120MB和100MB。File_1 的当前大小为40MB，File_2 的大小为80MB，File_3 的大小为90MB，File_4 的大小为130MB，File_5 的大小为105MB。让我们看看当有新的写入发生时，会发生什么。

Step 1：将更新分配给文件。在这一步，我们查找索引以找到标记的位置，记录被分配到各自的文件。请注意，我们假设更新只会增加文件的大小，这只会带来一个更大的文件。当更新降低了文件的大小(例如清空很多字段)，那么随后的写入将被视为一个小文件。

Step 2：确定每个分区路径的小文件。这里将利用最大文件大小配置值来确定小文件。例子鉴于配置值被设置为100MB，小文件是 File_1(40MB)和 File_2(80MB)以及 File_3(90MB)。

Step 3：一旦确定了小文件，就给它们分配插入内容，使它们达到最大容量120MB。File_1 将摄取80MB的数据，File_2 将摄取40MB的数据，File_3 将摄取30MB的数据。

Step 4：一旦所有的小文件都达到最大容量，如果还有未分配的数据，就会创建新的文件组/数据文件，并将插入文件分配给它们。每个新的数据文件的记录数是由 insert split size 配置决定的。假设 insert split size 配置为12万条记录，如果有30万条剩余记录，将创建3个新文件，其中2个文件(File_6 和 File_7)将被填入12万条记录，最后一个文件(File_8)将被填入6万条记录(假设每条记录为1000字节)。在未来的摄取中，第3个新文件将被认为是一个小文件，将被装入更多的数据

Hudi 利用诸如自定义分区之类的机制来优化记录分配到不同文件的能力，从而执行上述算法。在这一轮提取完成之后，除 File_8 以外的所有文件均已调整为最佳大小。每次提取期间都会遵循此过程，以确保 Hudi 表中没有小文件。

英文地址：http://hudi.apache.org/blog/hudi-file-sizing/#configs