iceberg合并小文件冲突测试

基于iceberg的master分支的9b6b5e0d2（2022-2-9）。

参数说明

1、PARTIAL_PROGRESS_ENABLED（partial-progress.enabled）
默认为 false。该参数能够让合并任务以group为单位做提交，当其中一个group任务失败，可以单独对该group任务重试。

2、USE_STARTING_SEQUENCE_NUMBER（use-starting-sequence-number）
默认为 true。
该参数使用做合并时的sequenceNumber作为新的数据文件的sequenceNumber。

测试

一、append方式生成 a,b,c三个snapshot，基于b做文件合并。

模拟的场景是：已存在a,b快照，现在基于b快照做小文件合并，但任务还未完成时，另一条数据流基于b快照做了append类型的数据：

右:USE_STARTING_SEQUENCE_NUMBER，下：PARTIAL_PROGRESS_ENABLED	true	false
true	成功	成功
false	成功	成功

• 成功：生成新的快照，最终snapshot是 a,b,c,d。

• 新生成的大文件是基于a,b的数据文件的总和，

• 快照d中包含了c的数据，以及基于a,b合并的数据。

• a,b,c,d对应的squenceNumber分别是1,2,3,4：
  USE_STARTING_SEQUENCE_NUMBER 为 true时，d里面生成的新的大文件对应的manifest的squeceid是用的以前的2，删除的manifest用的是新的id4
  

  USE_STARTING_SEQUENCE_NUMBER 为 false 时，d里面合并任务使用的全都是最新的id
  

结论：
1、纯append流的数据，做小文件合并都能成功。
2、可以通过设置 USE_STARTING_SEQUENCE_NUMBER 字段来控制合并任务中的manifest的squencyNumber。

二、append方式生成 a,b,c 三个 snapshot，先基于c做一次合并，合并成功后，基于c再做一次合并。

模拟的场景是，基于c快照做小文件合并，该任务还未完成，又启动了一个基于c快照做小文件合并的任务：

右:USE_STARTING_SEQUENCE_NUMBER，下：PARTIAL_PROGRESS_ENABLED	true	false
true	成功，但没生成新快照	成功，但没生成新快照
false	失败	失败

• 成功，但没生成新快照：只是表示该任务是完整执行了，没有出现异常退出的情况，但最终并未生成新的快照。PARTIAL_PROGRESS_ENABLED 设置 true，会打印出异常信息，但由于是部分提交，这些异常被忽略，最终程序执行成功，但也没有生成新的 snapshot。Failure during rewrite commit process, partial progress enabled. Ignoring。
• 失败：提示 Cannot commit rewrite because of a ValidationException or CommitFailedException. This usually means that this rewrite has conflicted with another concurrent Iceberg operation. To reduce the likelihood of conflicts, set partial-progress.enabled which will break up the rewrite into multiple smaller commits controlled by partial-progress.max-commits. Separate smaller rewrite commits can succeed independently while any commits that conflict with another Iceberg operation will be ignored. This mode will create additional snapshots in the table history, one for each commit.

结论：目前功能上不能基于同一个快照做多次合并，只会成功一次。

三、append方式生成 a,b 两个snapshot，对a的数据做更新生成c，再基于b做文件合并。

模拟的场景是：基于b快照做合并，此时还未完成，另一条数据流对a快照中的数据做了更新，且提交成功生成了c快照：

右:USE_STARTING_SEQUENCE_NUMBER，下：PARTIAL_PROGRESS_ENABLED	true	false
true	成功	成功，但没生成新快照
false	成功	失败

• 失败：提示 Cannot commit, found new delete for replaced data file。
• 成功，生成最新快照d，生成快照a,b中数据合并的大文件
• 成功，但没生成新的快照：参考上面说明

结论：在合并的过程中，有另一条数据流对需要合并的数据做修改，可以通过设置 USE_STARTING_SEQUENCE_NUMBER 来使任务成功。

四、append方式生成 a,b,c 三个snapshot，对c的数据做更新生成d，再基于b做文件合并。

模拟的场景：基于b快照做合并，此时还未完成，另一条数据流先做append，生成了c快照，然后又对c快照里的数据做修改生成了快照d：

右:USE_STARTING_SEQUENCE_NUMBER，下：PARTIAL_PROGRESS_ENABLED	true	false
true	成功	成功，但没生成新快照
false	成功	失败

• 失败，提示：
  Cannot commit, found new delete for replaced data file
  Cannot commit rewrite because of a ValidationException or CommitFailedException. This usually means that this rewrite has conflicted with another concurrent Iceberg operation. To reduce the likelihood of conflicts, set partial-progress.enabled which will break up the rewrite into multiple smaller commits controlled by partial-progress.max-commits. Separate smaller rewrite commits can succeed independently while any commits that conflict with another Iceberg operation will be ignored. This mode will create additional snapshots in the table history, one for each commit.

因为在获取文件的时候，此时只能读取到a和b下的数据文件，a和b下没有delete文件，所以没有读取a和b下数据文件的min和max。 在做merge的时候，最新的snapshot是d，此时有delete文件，所以需要判断该delete文件是否能够匹配上前面读取的数据文件。匹配条件有两个，一个是sequenceNumber，一个是最大最小值是否有交集。delete的文件是后生成的，它的sequenceNumber肯定是大于前面a,b下的数据文件，所以该条件满足。因为在读取a,b下的数据文件的时候，没有读取min,max，导致不能够跟delete文件做值的交叉范围判断，所以data文件中被关联了delete文件，所以这种情况下，虽然只对 a和b做合并，且后续修改的数据文件没有被修改，但依然会合并失败。
如果在读取a,b下数据文件的时候，把对应的min,max也读取上来，那么就可以合并成功，对应流程在 ManifestGroup.planFiles中，读取内容由 columns 决定。

• 成功：生成最新快照e，最终的快照为：a,b,c,d,e
• 成功，但没生成新的快照：参考上面说明

结论：虽然后续修改的数据并不在合并的数据中，但USE_STARTING_SEQUENCE_NUMBER为false依然会失败，具体原因已在上面说明。

结论

1、PARTIAL_PROGRESS_ENABLED
当该参数为true时，虽然它最终能让任务执行完成，但实际上它忽略子提交失败的情况，所以实际有没有做合并与该参数无关。

2、USE_STARTING_SEQUENCE_NUMBER
设置该参数为true，可以修改新生成的dataFile和manifest的sequenceNumber为原来的number，这样在读取数据的时候，就可以把delteFile应用到新生成的dataFile中了，可以解决大多数数据冲突的情况。