表格式并发协调机制

表格式的核心分歧不在数据文件本身，而在并发写入的协调机制。由于云存储中的数据文件本质上是不可变的，所有变更都必须通过创建新文件来表达，这导致了一个关键问题：当多个写入者同时提交时，谁的新文件集成为“当前版本”？

【背景】传统数据库依赖锁机制或集中式元数据存储来保证一致性，但在大规模分布式对象存储上，这种方案往往成为性能瓶颈。

目前主流表格式如 Apache Iceberg、Delta Lake 和 Lance 均采用了**乐观并发控制（OCC）结合多版本并发控制（MVCC）**的策略。其基本流程是：写入者先假设无冲突，生成新的数据文件和元数据快照；在提交阶段，尝试通过原子操作（如 put-if-not-exists 或目录重命名）更新指向最新状态的指针。如果检测到其他写入者已抢先提交，则根据具体策略选择重试、合并或失败。

不同表格式的差异在于冲突检测的粒度和解决逻辑。例如，Iceberg 强调通过原子交换元数据文件来实现可序列化隔离，并支持基于分区或文件的细粒度冲突检查；Lance 则利用对象存储的原语实现零基础设施的协调，并通过事务日志支持更复杂的自动冲突解决。这一机制的选择直接决定了系统在高频写入场景下的吞吐量、延迟以及运维复杂度。