📚 课程目录第4章 Clustering策略

4. Clustering策略：策略类型与选择配置

4.1 核心原理：Clustering策略的本质

Clustering策略并非一个简单的“是否开启”开关，而是一组触发条件与执行规则的组合。Hudi将“何时聚类”与“如何聚类”解耦，前者由策略类型决定，后者由排序、分组等参数控制。理解策略，本质上是理解Hudi如何判断一张表（或分区）的文件布局健康度，并在合适的时机发起重写操作。

从实现角度看，Clustering策略作用于两个层面：调度层（决定哪些文件组参与聚类）与执行层（决定如何合并小文件、如何排序）。调度层依赖元数据统计（如文件大小、记录数），执行层则依赖写入计划（ClusteringPlan）。策略类型决定了调度层扫描元数据的维度和阈值，而策略配置则控制执行层的具体行为。

关键认知：Clustering策略不是“一次性优化”，而是持续性的文件布局治理机制。策略选择错误会导致两种典型问题：过度聚类（频繁重写大文件，浪费IO）或聚类不足（小文件持续累积，查询性能下降）。

4.2 策略类型详解

4.2.1 基于大小的策略（SizeBasedClusteringStrategy）

这是最常用的策略，核心逻辑是：扫描分区内所有文件，将小于目标大小（targetFileMaxBytes）的文件视为“小文件”，当小文件数量达到阈值时触发聚类。该策略不关心分区内文件总数，只关注文件大小分布。

典型配置示例：

-- 在Spark SQL中执行Clustering
CALL run_clustering(
  table = 'db.table1',
  order = 'ts DESC',
  options = '
    hoodie.clustering.plan.strategy.class=org.apache.hudi.client.clustering.run.strategy.SparkSortAndSizeStrategy
    hoodie.clustering.plan.strategy.target.file.max.bytes=268435456
    hoodie.clustering.plan.strategy.small.file.limit=134217728
    hoodie.clustering.plan.strategy.max.num.groups=30
  '
)

参数含义：

target.file.max.bytes：目标文件最大字节数（默认256MB），聚类后文件尽量接近该值。
small.file.limit：小于该值的文件被视为小文件（默认128MB），会被优先合并。
max.num.groups：单次聚类最多处理的文件组数量，防止一次操作过重。

4.2.2 基于分区的策略（PartitionBasedClusteringStrategy）

该策略以分区为粒度进行判断，适合分区内文件数量极多、但单个文件大小尚可的场景。触发条件通常是：分区内文件总数超过阈值，或分区总大小超过设定值。此策略常用于流式写入场景，因为流式任务会不断产生新分区文件，导致分区内文件碎片化。

配置示例：

hoodie.clustering.plan.strategy.class=org.apache.hudi.client.clustering.plan.strategy.SparkSizeBasedClusteringPlanStrategy
hoodie.clustering.plan.strategy.partition.regex.pattern=.*
hoodie.clustering.plan.strategy.max.num.groups=50
hoodie.clustering.plan.strategy.target.file.max.bytes=268435456

与基于大小策略的区别在于：基于分区的策略会扫描整个分区的文件列表，而基于大小的策略只关注文件大小分布。实际生产中，两者常组合使用：先按分区判断是否需要聚类，再按文件大小决定合并哪些文件。

4.2.3 自定义策略

Hudi允许通过实现ClusteringPlanStrategy接口来自定义触发逻辑。例如，可以结合数据新鲜度（如只聚类3天前的数据）、结合分区路径正则匹配特定业务分区等。自定义策略适合有特殊治理需求的生产环境。

4.3 策略选择与配置方法

场景特征	推荐策略	关键参数建议	理由
批式写入，单次写入量大	基于大小	target=256MB, small=128MB	文件大小均匀，只需合并偶发小文件
流式写入，高频小批量	基于分区 + 基于大小	max.num.groups=50, target=256MB	分区内文件碎片化严重，需按分区批量治理
分区数量多，但单分区文件少	基于大小	small.file.limit=64MB	避免跨分区聚类带来的元数据开销
查询模式以最近分区为主	自定义（正则匹配热分区）	partition.regex.pattern=2024/.*	只治理热分区，冷分区不浪费IO

4.4 案例：流式写入场景的策略配置

某业务使用Flink流式写入Hudi，每5分钟一个checkpoint，每个checkpoint产生约20个小文件（每个约10MB）。一天下来，单分区文件数可达数千个。

问题诊断：查询时需打开数千个文件，NameNode压力大，查询延迟从2秒恶化到15秒。

策略配置：

-- 每30分钟触发一次Clustering
hoodie.clustering.inline=true
hoodie.clustering.inline.max.commits=6
hoodie.clustering.plan.strategy.class=org.apache.hudi.client.clustering.plan.strategy.SparkSizeBasedClusteringPlanStrategy
hoodie.clustering.plan.strategy.target.file.max.bytes=268435456
hoodie.clustering.plan.strategy.small.file.limit=134217728
hoodie.clustering.plan.strategy.max.num.groups=100
hoodie.clustering.plan.strategy.sort.columns=ts
hoodie.clustering.plan.strategy.sort.order=desc

执行效果：每6个commit（约30分钟）触发一次聚类，将约120个小文件合并为5~6个256MB的大文件。查询文件数从数千降至数十，查询延迟恢复到2秒以内。

4.5 误区与复盘

常见误区1：target.file.max.bytes设置过大
将目标文件设为1GB虽然减少了文件数，但会导致后续更新放大——任何单条记录的更新都需要重写整个1GB文件。建议保持256MB~512MB之间，平衡查询效率与写入放大。

常见误区2：忽略sortColumns的配置
仅做文件合并而不排序，虽然文件数减少了，但查询过滤效率未提升。如果业务查询经常按时间范围过滤，务必配置sort.columns=ts，使聚类后的文件内数据有序，配合Hudi的索引机制可大幅提升点查性能。

复盘建议：每次Clustering执行后，观察以下指标：
① 聚类前后文件数变化率（应大于50%）；
② 聚类耗时占总写入耗时比例（应小于10%）；
③ 聚类后查询P95延迟变化（应明显下降）。
若聚类频繁触发但文件数未显著下降，需检查small.file.limit是否过小，或是否存在大量“不可合并”的文件组（如处于进行中的写入）。

策略选择总结：没有“万能策略”，只有“适合当前写入模式”的策略。建议先在测试环境用真实数据量验证策略参数，观察2~3个调度周期后再推广到生产。同时，Clustering策略应随数据规模增长动态调整——初期小文件多，可激进聚类；后期文件已规整，应降低触发频率，避免无谓的IO开销。