在 Hudi 的设计中，为了保持数据文件大小合理、提升查询性能，引入了 clustering 后台表服务。Clustering 的核心目的，是将多个小文件（small files）合并或重写为更大、更均衡的文件，从而减少读取和查询过程中因小文件过多带来的性能开销。
然而，在实际生产环境中，会出现一个较为微妙但对稳定性和资源利用影响显著的问题 —— “尾部小文件（tail small file）”。具体来说，一次 clustering 执行后可能会残留一个体积非常小的文件，而在下一轮 clustering 周期中，这个小文件会再次被选中重写。如此反复，不仅浪费计算资源，还会导致 commit 和 metadata 的额外开销，甚至可能因为文件频繁更替，造成下游查询表现不稳定。
准备一个分区，其数据量大约 720 MB，并配置如下参数：
'clustering.plan.strategy.target.file.max.bytes' = '650000000'在执行聚簇之前，该分区（例如 p_date=20251029）大约包含 10 个 Parquet 文件，每个文件大小从 8 MB 到 120 MB 不等。
第一次运行 clustering 后，会生成一个大文件（大约 680 MB）和一个小文件（大约 50 MB）。这符合设定的目标文件大小，按理说不应该再有额外合并。然而，当 clustering 周期性地持续运行时，这个 50 MB 的小文件却持续被反复重写 —— 每次 clustering 执行都会生成这个小文件的新版本。
由于启用了 “clean-retain-commits” 配置，多个该小文件的历史版本被保留下来，导致不必要的文件膨胀和冗余提交。
在生产环境中，各分区的数据量往往差异较大。即使对文件的最小/最大大小做了精细调优，也难以保证所有分区都能均匀地合并成大文件，因此产生“小尾巴文件”几乎是不可避免的。
为此，我们引入了一种全新的聚类策略。该策略会综合考虑是否需要在聚类过程中进行排序等因素，并仅在 clustering 的 plan 构建阶段 添加 early-exit（提前退出） 条件，而不会改变 commit 或 execution 的整体流程。用户可通过参数 clustering.plan.strategy.class 启用该策略，完全兼容旧逻辑。该策略已测试并在生产环境稳定运行，可靠性经过验证。
目前，这一策略已被社区正式采纳合并入主分支。对于 Hudi + Flink 场景下启用了 clustering 的用户——尤其是分区数据分布不均 的场景，该策略能够显著降低不必要的 clustering 开销，从而提升作业的稳定性与整体效率。
如果你在生产环境中使用 Hudi + Flink 进行 clustering，强烈建议开启此新策略。对于绝大多数场景来说，这是一个几乎“零成本”、但收益十分明显的优化方案。
评论