題幹與適用場景
一張 Apache Iceberg 表承載使用者資料，既要支援 GDPR 刪除，也要接收高頻更正。團隊準備從 v2 升級到 v3，並考慮使用 deletion vector。請說明三種列級刪除格式的差異、何時選擇它們，以及如何保證舊讀者、並行寫入、回滾和 compaction 都安全。
這道題考察資料湖表格式的讀寫協定，而不是記憶一個開關。Iceberg 規範把 deletion vector（DV）定義為針對單一資料檔案、按列位置編碼的位圖；它與 equality delete 和 position delete 的作用範圍、元資料及維護責任不同。
面試官考察點
- 能否區分按欄值刪除、按檔案位置刪除和位圖刪除。
- 是否知道 DV 是 Iceberg v3 能力，v2 不支援新增 DV。
- 是否能解釋快照讀取時的檔案路徑、分割區和 sequence number 條件。
- 是否能考慮一個資料檔案最多一個 DV，以及與舊 position delete 的合併規則。
- 是否能把格式選擇連接到讀放大、寫放大、刪除比例、相容性和維護時段。
- 是否會設計可觀測性、回滾演練和舊讀者降級方案。
回答前需要釐清的問題
先確認：
- 目前表是 Iceberg v2 還是 v3，讀寫引擎和版本分別是什麼？
- 刪除請求按主鍵值到達，還是已知道資料檔案與列位置？
- 刪除比例、更新頻率、查詢延遲和 compaction 預算是多少？
- 是否仍有只讀 v2 引擎，是否要求時間旅行和快照回滾？
- 是否需要把刪除事件下游化為 CDC，還是只保證目前查詢不可見？
如果條件不明，可假設主要讀者支援 v3、仍有少量 v2 讀者，並且刪除必須在提交成功的快照中可見。
30 秒回答框架
我會先按語義選擇：按欄值匹配用 equality delete，已知檔案和列位置且需要相容 v2 時用 position delete；v3 場景下，對單一資料檔案的高頻位置刪除可合併為一個 deletion vector。讀取時必須同時檢查引用資料檔案、分割區和 sequence number，不能只看位圖。
寫入端要保證一個資料檔案在一個快照中最多一個 DV，並把既有 position delete 合併進去；提交使用 Iceberg 的快照並行校驗。v2 讀者不能理解 DV，因此升級前要完成能力矩陣、雙讀驗證和回滾方案。最後用刪除可見性、舊快照、並行衝突、compaction 和效能指標驗收。
分步驟深入解答
1. 先定義三種格式的語義
equality delete 用一個或多個欄值匹配任意資料檔案中的列，例如 id = 5。position delete 用資料檔案路徑與從零開始的列位置標記刪除。deletion vector 則為一個被引用的資料檔案保存位置位圖，置位表示對應列已刪除。
三者不是簡單的壓縮等級。equality delete 適合主鍵事件但掃描時匹配成本較高；position delete 精確且可相容 v2，但檔案數量容易增長；DV 把同一資料檔案的許多位置刪除合併成一個可定位的二進位物件。
2. 處理版本與讀者能力
Iceberg 規範把列級刪除放在 v2 之後，deletion vector 是 v3 新增能力。v3 表不能新增 position delete，但從 v2 升級而來的舊 position delete 仍然有效，並應在建立 DV 時被合併。
因此不能只升級 catalog。要盤點每個讀引擎是否能讀取 v3 元資料、Puffin 中的 deletion-vector-v1 blob 和刪除 manifest。未支援的讀者應繼續消費相容快照，或在切換前完成遷移；不能把 DV 寫入後再期待舊引擎靜默忽略。
3. 遵守快照讀取範圍
讀取器把 DV 應用於資料檔案，需要同時滿足：資料檔案路徑等於 referenceddatafile、資料檔案 sequence number 不大於 DV 的 sequence number、分割區規範和值相等。只按路徑匹配會把刪除錯誤套用到重寫後的檔案，忽略 sequence number 會破壞時間順序。
刪除 manifest 還要記錄 DV 所在檔案、blob 的 offset 和 length。讀取器必須從正確的快照元資料定位 blob，而不能把物件儲存目錄中的同名檔案當作事實來源。
4. 設計寫入合併與並行提交
同一快照中一個資料檔案最多允許一個 DV。寫入者在追加刪除時要讀取目前刪除狀態，把新位置與舊 DV、舊 position delete 合併，再寫出新的 DV。若移除資料檔案，也要從 delete manifest 移除適用的 DV。
提交仍然透過 Iceberg 快照和 optimistic concurrency 完成。衝突重試時必須重新讀取最新 metadata 和 delete manifests，不能重用第一次嘗試生成的位圖。重試次數、衝突原因和最終提交 snapshot id 都應記錄。
5. 選擇寫放大與讀放大的平衡
刪除很少且分散時，equality delete 能避免定位原始檔案，但掃描器需要套用述詞。刪除集中在少量檔案且頻繁發生時，DV 通常能減少 position delete 檔案管理與讀取合併成本。大面積刪除或檔案已經需要重寫時，直接重寫資料檔案並清理刪除檔案可能更划算。
不要用「DV 一定更快」作為結論。需要用查詢掃描位元組、刪除檔案數量、位圖大小、manifest 讀取時間、compaction CPU 和端到端延遲比較不同刪除密度。
6. 規劃維護、回滾和合規證明
維護任務應在安全時段合併舊 delete files、重寫高刪除比例的資料檔案並清理無引用 blob。清理必須尊重時間旅行保留策略，否則歷史快照會失去可讀性。GDPR 場景還要證明目前有效快照和下游副本都不再返回目標列。
回滾演練要涵蓋：寫入提交後回滾、DV 所在 Puffin 檔案仍在、舊 position delete 是否仍能套用，以及新快照是否繼續滿足刪除要求。刪除稽核應保存請求 id、提交 snapshot id 和驗證結果，但不能把個人資料寫入日誌。
7. 建立相容性與可觀測性門禁
發布前建立讀寫引擎矩陣：v2 讀者、v3 讀者、批次處理、串流讀取和維護工具分別驗證 equality、position、DV。指標至少包括 DV 套用失敗、未匹配資料檔案、delete manifest 膨脹、衝突重試、舊快照讀取失敗和 compaction 積壓。
在灰度期間讓同一快照由新舊讀引擎做結果對比，檢查列數、主鍵集合和抽樣內容。發現舊讀者無法解釋 v3 刪除時，應停止 DV 寫入或切換到相容格式，而不是繼續擴大影響面。
高品質示範回答
我會先看刪除事件的語義和引擎矩陣。按主鍵值刪除用 equality delete；已知道資料檔案和列位置、且仍需 v2 相容時可用 position delete；如果表已升級到 v3，並且刪除集中在單一資料檔案，我會把位置集合合併為 deletion vector。DV 是單檔案位圖，一個快照中同一資料檔案最多一個，建立新 DV 時要合併已有 position delete。
讀取時不能只依據檔案路徑。必須校驗 referenceddatafile、分割區規範和值，以及資料檔案 sequence number 不大於 DV 的 sequence number；DV 的 blob offset 和 length 也必須來自 delete manifest。寫入採用快照樂觀並行，衝突重試要重新讀取最新 metadata，不能重用舊位圖。
遷移前我會驗證所有讀者是否支援 v3、Puffin 和 DV，並保留停止寫 DV 的開關。驗收包括目前快照刪除可見、舊快照時間旅行、並行刪除、回滾、compaction、舊引擎結果對比和合規證明。效能上比較掃描位元組、manifest 時間、DV 大小、compaction CPU 與端到端延遲；當刪除比例很高時，重寫資料檔案可能比繼續累積 DV 更合適。
常見錯誤
- 把 DV 當成 equality delete 的壓縮版，忽略匹配語義。
- 誤稱 Iceberg v2 可以寫入 deletion vector。
- 只按檔案路徑套用 DV，不校驗分割區與 sequence number。
- 為同一資料檔案保留多個 DV，或沒有合併舊 position delete。
- 升級 catalog 後沒有驗證所有讀引擎和維護工具。
- 用一次 compaction 解決所有刪除密度，沒有比較讀放大與寫放大。
- 清理 delete manifest 時破壞時間旅行保留的歷史快照。
- 把日誌中的個人資料當作刪除稽核證據。
追問及應對
追問一：為什麼不能讓 v2 讀者直接忽略 DV？
因為忽略刪除元資料會把已刪除列重新返回，形成靜默的資料正確性事故。應先完成引擎能力矩陣和結果對比，再決定遷移、相容寫入或停止 DV。
追問二：如果同一資料檔案的刪除持續增加，何時重寫檔案？
按刪除密度、位圖大小、掃描 CPU、查詢延遲和 compaction 預算設定門檻。超過門檻後重寫資料檔案並在新快照中移除適用 DV，隨後驗證舊快照保留策略。
追問三：並行提交衝突重試時最容易漏什麼？
漏讀最新 delete manifests 和 data sequence number。每次重試都要基於最新表 metadata 重新合併刪除集合，並記錄衝突與最終 snapshot id。
追問四：如何證明刪除符合合規要求？
保存請求範圍、提交 snapshot id、目前快照查詢結果、下游副本核驗和清理任務狀態；同時明確時間旅行保留期限，避免把含個人資料的日誌作為證明。
追問五：什麼時候 equality delete 反而更合適？
當事件只攜帶業務鍵、資料檔案不斷重寫，或需要跨多個檔案表達同一刪除述詞時，equality delete 更直接。仍應測量讀取匹配成本並設定後續重寫策略。