Hudi 的 clustering plan 本质是通过重排数据文件（file reorganization）来减少小文件、提升数据局部性（data locality），从而加速查询。它不改变表的逻辑结构，但显著影响底层 Parquet 文件的大小、数量和列统计信息分布，这对 Spark SQL、Presto、Trino 等引擎的谓词下推、跳过扫描（skip scan）和并行度调度都至关重要。
Clustering 如何优化物理布局
默认写入（如 upsert）容易产生大量小文件（
- 按 sort columns（如
ts, user_id）重排序后写入，使同一范围的ts和相似user_id聚合在相邻行组（row group）中； - 合并后单个 Parquet 文件通常达 512MB~1GB，减少文件数量（从数千降至几十）；
- 每个 row group 的 min/max 统计更紧凑，查询带
WHERE ts BETWEEN ...或WHERE user_id IN (...)时，能跳过更多 row group。
Clustering plan 生成与执行的关键控制点
plan 本身不重写数据，只生成待重排的文件分组（clustering groups）和目标排序规则。是否生效取决于后续执行：
-
触发时机：可手动调用
scheduleClustering()+cluster()，或配置hoodie.clustering.autosync.enable=true让写入后自动触发； -
策略选择：常用
SparkSortAndSizeClusteringPlanStrategy（按排序列+文件大小合并），避免盲目按分区合并导致跨时间范围乱序； -
资源预留：clustering 是计算密集型任务，需确保 Spark executor 有足够内存（尤其排序列含字符串时），建议开启
spark.sql.adaptive.enabled=true动态优化 shuffle。
对查询性能的实际影响
实测常见收益集中在三类查询：
- 时间范围扫描：未 clustering 表扫描 10 个分区共 800 个小文件，clustering 后仅读 3 个大文件，I/O 减少 70%+，Spark task 数下降 60%；
-
高基数点查（如
SELECT * FROM t WHERE pk = 'x'）：因主键局部性增强，配合布隆过滤器（Bloom Filter）启用后，95% 查询跳过 90% 以上 row group； - Join 性能：clustering 后按 join key 排序的表，在 broadcast join 失败转 sort-merge join 时，shuffle 数据更有序，reduce 阶段合并效率更高。
注意事项与常见陷阱
clustering 不是万能药，使用不当反而引入开销：
- 频繁 clustering（如每小时）会导致写放大，建议结合
hoodie.clustering.max.num.groups限制作业规模； - 若表已按分区字段（如
dt）强隔离，且查询几乎不跨分区，则 clustering 收益有限，优先优化分区剪枝； - clustering 后需触发
ANALYZE TABLE（Hive/Spark）更新统计信息，否则优化器仍按旧文件元数据估算代价。
不复杂但容易忽略：clustering 的价值不在“做了”，而在“做对了策略、时机和验证”。上线前建议用 DESCRIBE HISTORY 查看 clustering commit 的 input/output file count 和 size 分布，再对比关键查询的 Spark UI 中的 task 时间分布和 skipped row groups 指标。
