湖仓写任务报 CommitFailed，最常见的处理是调高重试次数。这对一部分并发 append 有效，对 overwrite、delete 或 compaction 却可能掩盖真正的语义冲突。更麻烦的是提交超时：客户端认为失败，Catalog 可能已经成功切换了元数据。

诊断并发写入，不能只看异常类名。我会把一次写拆成数据文件生成、基于某个 snapshot 规划变更、冲突校验、Catalog 原子提交和提交结果确认五段，先判断失败发生在哪一段，再决定复用文件、重新规划还是人工核对。

“Iceberg 支持原子提交”这句话很容易被理解成：两个任务同时写同一张表也不会冲突，失败了自动重试就好。实际边界要窄得多。

Iceberg 的原子点是 table metadata pointer 从旧 metadata file 切换到新文件。数据文件、manifest、manifest list 和新 metadata file 在此之前已经写到存储上；只有 catalog 中的指针成功切换，新 snapshot 才对读者可见。两个 writer 基于同一个旧版本提交时，只能有一个先完成切换，另一个必须刷新表状态、重新验证再尝试。

所以原子性解决的是“读者不会看到半张表”，不是“所有并发操作都会成功”。并发 append、overwrite 和 compaction 的冲突条件不同，失败后的处理也不能统一写成一个无限重试。