Apache Iceberg 中 partial-progress.max-failed-commits 配置的缺陷分析与解决方案

在 Apache Iceberg 1.7.1 版本中，我们发现了一个关于 partial-progress.max-failed-commits 配置的重要缺陷。这个配置原本用于控制部分进度重写操作中允许的最大失败提交次数，但在特定场景下会出现误判情况。

问题背景

Apache Iceberg 提供了数据文件重写功能，允许用户通过 RewriteDataFiles 操作优化表的数据布局。为了处理大规模重写操作，Iceberg 引入了部分进度机制，将重写操作分解为多个较小的提交。其中两个关键配置参数是：

1. partial-progress.max-commits：指定将重写操作分割成的最大提交次数
2. partial-progress.max-failed-commits：允许的最大失败提交次数

问题本质

当前实现中存在一个逻辑缺陷：系统通过计算 maxCommits - succeededCommits 来获取失败提交数，而不是直接统计实际的失败提交次数。这种计算方式在以下场景会产生问题：

当实际需要重写的文件组数量少于配置的 maxCommits 值时，系统会自动减少实际提交次数。然而，失败提交数的计算仍然基于原始的 maxCommits 配置值，导致误报失败次数超过阈值。

问题表现

在实际应用中，我们观察到以下典型现象：

1. 配置 maxCommits=10，但实际只需要1个文件组重写
2. 系统正确执行了1次提交
3. 但失败计数却显示为9（10-1）
4. 当配置的 max-failed-commits=3 时，系统错误地认为超过了阈值

技术分析

问题的根源在于 RewriteDataFilesSparkAction 类的实现逻辑：

1. 系统直接从配置中获取 maxCommits 值
2. 计算文件组分配时使用 IntMath.divide(ctx.totalGroupCount(), maxCommits, RoundingMode.CEILING)
3. 当 ctx.totalGroupCount() < maxCommits 时，实际提交次数会少于配置值
4. 但错误处理仍然基于原始配置值计算失败次数

解决方案

正确的实现方式应该是：

1. 直接统计实际的失败提交次数，而不是通过计算得出
2. 在错误处理逻辑中维护一个失败计数器
3. 将实际失败次数与配置阈值进行比较

这种改进方案更符合实际业务场景，能够准确反映重写操作的执行状态。

影响范围

该问题主要影响以下场景：

1. 使用 Spark 引擎执行重写操作
2. 启用了部分进度功能（partial-progress.enabled=true）
3. 实际需要重写的文件组数量少于配置的 maxCommits 值
4. 重写过程中确实发生了部分提交失败

最佳实践建议

在使用 Iceberg 的重写功能时，建议：

1. 根据表的数据量合理设置 maxCommits 值
2. 监控重写操作的执行情况，特别是失败计数
3. 升级到包含修复补丁的版本
4. 对于关键业务表，建议先在测试环境验证重写配置

该问题已在社区得到重视，并提交了修复方案。用户在使用部分进度重写功能时应当注意这一潜在问题，特别是在文件组数量较少的情况下。