基于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型別的資料：

• 成功：生成新的快照，最終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快照做小檔案合并的任務：

• 成功，但沒生成新快照：只是表示該任務是完整執行了，沒有出現例外退出的情況，但最終并未生成新的快照，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快照：

• 失敗：提示 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：

• 失敗，提示：
  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中了，可以解決大多數資料沖突的情況，

標籤：大數據

上一篇：R中的生存分析；使用plotly包創建互動式kaplan-meier圖

下一篇：RadonDB MySQL on K8s 2.1.2 發布！