hudi文件大小设置

本文档将向您展示Apache Hudi如何克服可怕的小文件问题。Hudi的一个关键设计决策是避免在一开始就创建小文件，并始终编写大小适当的文件。在Hudi中有两种管理小文件的方法，下面将介绍每种方法的优点和优缺点。

文件摄取时期自动调整大小

您可以在摄取期间自动管理文件的大小。 此解决方案在摄取期间增加了一点延迟，但它确保了一旦提交写入，读取查询总是有效的。 如果您在写入时不管理文件大小，而是尝试定期运行文件大小清理，那么在定期执行调整大小清理之前，您的查询将会很慢。

（注意：bulk_insert 写入操作在摄取期间不提供自动调整大小）

对于Copy-On-Write表

这就像配置基本/parquet文件的最大大小以及文件应被视为小文件的软限制一样简单。对于 Hudi 表的初始引导，调整记录大小估计对于确保将足够的记录打包到 parquet 文件中也很重要。 对于后续写入，Hudi 自动使用基于先前提交的平均记录大小。 Hudi 将尝试在写入时向小文件添加足够的记录，以使其达到配置的最大限制。 例如，在 compactionSmallFileSize=100MB 和 limitFileSize=120MB 的情况下，Hudi 将选择所有小于 100MB 的文件并尝试将它们增加到 120MB。

对于Merge-On-Read

MergeOnRead 对于不同的 INDEX 选择的工作方式不同，因此需要设置的配置很少：

• canIndexLogFiles = true 的索引：新数据的插入直接进入日志文件。 在这种情况下，您可以配置最大日志大小和一个表示当数据从 avro 移动到 parquet 文件时大小减小的因子。
• 带有 canIndexLogFiles = false 的索引：新数据的插入仅用于 parquet 文件。 在这种情况下，适用与上述 COPY_ON_WRITE 情况相同的配置。

注意：在任何一种情况下，只有当特定文件片没有 PENDING 压缩或关联的日志文件时，小文件才会自动调整大小。 例如，对于案例 1：如果您有一个日志文件，并且计划进行压缩 C1 将该日志文件转换为 Parquet，则无法再向该日志文件中插入任何内容。 对于案例 2：如果您有一个 parquet 文件并且更新最终创建了关联的 delta 日志文件，则不能再有插入到该 parquet 文件中。 只有在执行了压缩并且没有与基本 parquet 文件关联的日志文件之后，才能将新插入发送到自动调整该 parquet 文件的大小。

使用Clustering自动调整大小

集群是 Hudi 中的一项功能，可以将小文件同步或异步分组为较大的文件。

由于自动调整小文件大小的第一个解决方案在摄取速度上进行了权衡（因为小文件在摄取期间调整大小），如果您的用例对摄取延迟非常敏感，而您又不想在摄取速度上妥协，这可能最终会创建很多小文件，那么此时clustering就可以来解决这个问题。

可以在摄取作业的同时执行Clustering操作，异步作业可以在后台将小文件拼接在一起以生成更大的文件。 请注意，在此期间，摄取可以继续同时运行。

原文链接：https://hudi.apache.org/docs/file_sizing