聚类解决什么问题
Hudi Clustering 按新的布局把一批小文件重写成大小合适的文件，减少查询时的文件打开与元数据开销，也可以顺便按新的列顺序重组数据。它和 compaction 是两件事：compaction 负责把 MOR 表的 log 文件合并回 base 文件，clustering 负责重排文件布局。
基本信息
| 适用对象 | Apache Hudi 0.9 及以后版本的表 |
|---|---|
| 执行方式 | inline 随写入执行，或 async 独立调度 |
| 核心策略 | 小文件阈值、目标文件大小、可选排序列 |
| 与 compaction | 职责不同，各自调度、各自监控 |
| 监控项 | 待执行的聚类计划数量与执行耗时 |
典型使用场景
- 写入频率高导致小文件堆积，查询打开成千上万个文件
- 历史分区需要整理成更大的文件，降低长尾扫描时间
- 希望按新的排序列重组数据，提升按列过滤的裁剪效率
- 表经历过结构变更，需要重整布局以恢复读写性能
- MOR 表查询性能下降，需要区分是 log 积压还是文件过碎
开启异步聚类
开启异步聚类
# 交给写入链路内联执行，或关闭后改用独立调度触发
hoodie.clustering.inline=true
# 每积累 4 次提交执行一次内联聚类，避免每次写都触发
hoodie.clustering.inline.max.commits=4
# 目标文件大小 1GB，小于 300MB 视为小文件纳入计划
hoodie.clustering.plan.strategy.target.file.max.bytes=1073741824
hoodie.clustering.plan.strategy.small.file.limit=314572800
# 聚类会与写入争抢资源，生产环境建议限制并发并单独编排
hoodie.clustering.async.max.commits=4聚类与 compaction 分工
| 对比项 | Clustering | Compaction |
|---|---|---|
| 处理对象 | base 文件布局与小文件 | MOR 表的 log 文件 |
| 触发原因 | 文件过碎或需重排序 | 增量日志积累过多 |
| 是否改内容 | 不改数据，只改组织方式 | 把日志合并进 base 文件 |
| 失效风险 | 计划积压，写入延迟上升 | 不执行会导致读放大严重 |
聚类计划需要积压到一定数量才执行，积压本身不一定是故障；但待处理计划数持续上升、写入耗时同步变长时，说明调度能力跟不上写入速度，需要调整阈值或增加执行窗口。
聚类与 compaction 同时高频开启而不限制资源，写入任务会排队等待，表现为端到端延迟上升。上线前先用压测确认两者叠加后的写入吞吐能接受。