Paimon 支持针对多个并发写入任务的乐观并发控制。
每个作业都会按照自身的节奏写入数据，并在提交时基于当前的快照应用增量文件（删除或添加文件）来生成新的快照。
这里可能会出现两种类型的提交失败情况：
- 快照冲突：快照 ID 已被抢占，该表已由另一项作业生成了新的快照。好的，让我们再次提交。
- 文件冲突：此作业想要删除的文件已被其他作业删除。此时，该作业只能失败。（对于流式作业，它会失败并重新启动，还会有意地进行一次故障转移）
快照冲突
Paimon的快照 ID 是唯一的，因此只要作业将快照文件写入文件系统，就视为作业成功完成。
image.png
Paimon 利用文件系统的重命名机制来提交快照，这对于 HDFS 来说是很安全的，因为它能确保重命名操作具有事务性和原子性。
但对于诸如 OSS 和 S3 这样的对象存储而言，它们的“RENAME”操作并不具备原子性语义。我们需要配置 Hive 或者 JDBC 元数据存储，并为Catelog启用“lock.enabled”选项。否则，可能会有丢失快照的风险。
文件冲突
当 Paimon 执行文件删除操作（这仅是逻辑删除操作）时，它会检查与最新快照是否存在冲突。如果存在冲突（意味着该文件已被逻辑删除），那么它就无法继续在当前提交节点上进行操作，因此只能有意触发故障转移以重新启动，并且该作业会从文件系统中获取最新状态，以期解决此冲突。
image.png
Paimon会确保这里不会出现数据丢失或重复的情况，但如果两个流式传输任务同时进行写入操作，并且出现了冲突，您就会发现它们会不断地重新启动，这可不是什么好事。
冲突的本质在于删除文件（从逻辑上讲），而删除文件源于压缩操作，所以只要我们关闭写入任务的压缩操作（将“只写”设置为“真”），然后启动一个单独的任务来进行压缩工作，一切就都很好了。
See dedicated compaction job for more info.
