apache hudi 是一種資料湖平台技術，可提供建構和管理資料湖所需的多種功能。hudi 提供的一項重要功能是自動管理檔案大小，使用者不需要手動維護。由于查詢引擎不得不多次打開/讀取/關閉檔案，以計劃和執行查詢，是以擁有大量小檔案将使其難以實作良好的查詢性能。但是對于流資料湖用例而言，固有的攝入量将最終具有較小的寫入量，如果不進行特殊處理，則可能導緻大量小檔案。
during write vs after write
解決小檔案引起的系統可伸縮性問題，常見的方法是寫入非常小的檔案然後将它們合并在一起，但可能會因為把小檔案暴露在查詢中而違反查詢sla。實際上，可以通過運作clustering 輕松地在 hudi 表上執行此操作。
此篇文章讨論初始寫入期間在 hudi 中進行檔案大小優化的情況，是以不必為了調整檔案大小而再次重新寫入所有資料。如果要同時具有(a)自我管理的檔案大小和(b)避免将小檔案暴露給查詢，自動調整檔案大小的功能将幫助你解決上述問題。
執行 insert/upsert 操作時，hudi 能夠保持配置的目标檔案大小。注意 bulk_insert 操作不提供此功能，類似于 spark.write.parquet。
為了說明問題，隻介紹 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。
比方說，這是一個特定分區的資料檔案分布
讓我們假設最大檔案大小和小檔案大小限制的配置值為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