SQL Hudi 的 compaction 策略与 clustering 定时任务配置

hudi的compaction和clustering需按写入模式与节奏精细配置：cow表宜开inline compaction，mor高频写入应禁用inline改异步；clustering须错峰调度、限制并发与文件大小阈值；二者参数必须对齐，否则引发小文件堆积、元数据膨胀及查询异常。

compaction 该不该开自动，取决于写入模式

Hudi 的 compaction 不是“开了就稳”，而是和你的写入频率、数据更新比例强相关。如果用 COW 表，每次更新都生成新文件，不 compaction 就会迅速积累小文件，查得慢、元数据压力大；但要是 MOR 表 + 高频小批量 upsert（比如每 5 分钟一批 100 条），自动 compaction 可能卡在排队里，反而拖慢写入。

• hoodie.compact.inline=true：写入时顺手 compact，适合低并发、中等吞吐场景，但会延长单次写入耗时
• hoodie.compact.inline.max.delta.commits=5：每 5 次 commit 触发一次 inline compaction，比固定时间更贴合数据节奏
• 真正高频写入（如 kafka 实时接入）建议关掉 inline，改用异步 compaction，否则写入线程常被 block 在 CompactionUtils.getCompactionPlan

常见错误现象：java.util.concurrent.TimeoutException 出现在 HoodieflinktableSink 提交阶段——大概率是 inline compaction 卡住了，不是 Flink 本身超时。

clustering 定时任务怎么配才不抢资源

Clustering 是重分布文件、提升查询性能的关键，但它本质是“读一堆小文件 → shuffle → 写新文件”，IO 和 CPU 开销都大。直接丢进生产调度器定时跑，很容易和 compaction 或写入任务撞上。

• 调度周期别照搬 compaction 频率：clustering 建议按天或按小时级触发，用 hoodie.clustering.async.enabled=true + 外部调度器（如 Airflow）调 hudi-cli 的 scheduleClustering 和 runClustering
• 必须设资源水位：在 Flink 作业里加 hoodie.clustering.max.num.groups=5，避免单次 clustering 启动上百个 task
• 注意 hoodie.clustering.plan.strategy.target.file.max.bytes：默认 120MB，如果原始文件普遍小于 20MB，这个值太大会导致 grouping 失效，clustering 做了也白做

使用场景差异：离线数仓 T+1 补数据，适合凌晨跑 clustering；实时链路中若用了 MOR 表且查得勤，可把 clustering 和 compaction 错峰（比如 compaction 在整点，clustering 在半点）。

compaction 和 clustering 共存时的参数冲突点

两者都操作文件布局，参数一不小心就会互相干扰。最典型的是：

• hoodie.compact.small.file.limit 和 hoodie.clustering.plan.strategy.small.file.limit 数值不一致：会导致 compaction 认为该合并的文件，clustering 却跳过，或者反过来，结果就是小文件反复生成又不清理
• hoodie.cleaner.policy.failed.writes 设成 KEEP_FAILED 时，compaction 失败的临时文件不会被清，下次 clustering 又可能读到脏状态，报 HoodieIOException: Cannot read from file xxx.commit
• MOR 表下，hoodie.compaction.payload.class 和 hoodie.clustering.payload.class 必须一致，否则 clustering 后的文件用不了 compaction 的 payload 逻辑，查出来字段为空

性能影响明显：同时开启且参数没对齐，metadata 表体积可能翻倍，.hoodie/metadata/filegroups/ 下文件数暴涨，S3 列目录变慢，Flink 作业启动卡在 FileSystemViewStorageConfig 初始化。

Flink sql 里怎么安全启停 compaction/clustering

Flink SQL 本身不直接暴露 compaction 控制，得靠配置项 + 外部动作配合：

• 启动 compaction：在 INSERT INTO 语句的 table properties 里加 'compaction.async.enabled'='true'，但注意这只是“允许后台跑”，真正触发还得靠 commit 频率或手动 schedule
• 暂停 compaction：把 hoodie.compact.inline=false + hoodie.compact.async.enabled=false，再等当前正在跑的 compaction 完成（查 .hoodie/compaction.requested 文件是否存在）
• clustering 无法用 SQL 动态开关，必须通过 hudi-cli 或 REST API：

  scheduleClustering --tableName trd_orders --parallelism 2

  runClustering --tableName trd_orders --sparkMaster yarn

容易踩的坑：Flink 作业重启时，如果 hoodie.compact.async.enabled=true 但没配 hoodie.compact.schedule.interval.seconds，它不会自动 schedule，得靠外部触发；另外，clustering 运行中重启 Flink 作业，可能导致部分文件写了一半，后续查不到数据——这不是 bug，是设计如此，得靠 hoodie.fail.on.timeline.archiving=false 保底。

Hudi 的 compaction 和 clustering 不是开关一按就完事，它们的节奏得跟着你的数据写入毛细血管走，参数稍偏一点，小文件、元数据膨胀、查询抖动就全来了。最麻烦的是两者叠加时的隐式依赖，比如 compaction 输出成了 clustering 的输入，但 payload class 或 file limit 对不上，问题会藏好几层才暴露。