資料工程面試：如何用 Iceberg Deletion Vector 處理列級刪除？
題干與適用場景
事件湖每天追加數十億列，使用者刪除請求持續產生。團隊希望採用 Iceberg v3 的 deletion vector，減少頻繁重寫資料檔。請解釋它與 position delete、equality delete 的差異，如何保證快照一致性、跨引擎相容與最終實體刪除。
面試官考察點
- 是否理解刪除向量是按資料檔記錄列位置的邏輯刪除標記，不是立即擦除底層位元組。
- 能否區分三種刪除表示及其寫入放大、讀取成本與適用邊界。
- 能否設計快照原子提交、並行合併、舊 reader 降級與 compaction。
- 能否把合規刪除證明與查詢正確性、備份保留連結起來。
回答前需要釐清的問題
- 所有 writer、catalog、查詢引擎與 SDK 是否支援 Iceberg v3 與 deletion vector？
- 刪除依據是穩定列位置、業務鍵，還是需要跨檔匹配？
- 允許邏輯刪除保留多久，備份、物件版本與複製鏈路何時過期？
- 查詢引擎如何載入刪除檔，快取鍵是否包含 snapshot ID？
- compaction 是否會與串流寫入、快照過期和合規刪除並行？
30 秒回答框架
我會把 deletion vector 視為快照內的邏輯刪除層：每個資料檔最多關聯一個向量，記錄已刪除的列位置；讀取時按快照過濾，底層檔案仍需在受控 compaction 後重寫。position delete 也按位置記錄但通常使用獨立刪除檔，equality delete 按欄值匹配，靈活卻可能掃描更多資料。先驗證所有 reader 的 v3 支援，再用原子快照提交、舊引擎相容視圖和可稽核的實體清理窗口完成遷移。
分步深入解答
第一步：定義刪除語義
deletion vector 是與資料檔關聯的位圖或等價結構，以列位置標記已刪除記錄。它讓查詢在邏輯上看不到列，卻不等於物件儲存上的位元組已擦除，因此隱私刪除仍需後續重寫、過期與備份治理。
第二步：比較三種刪除表示
position delete 以資料檔位置記錄刪除，適合寫入時已知檔案與列位置；equality delete 以欄位值匹配，適合 CDC 或業務鍵刪除，但讀取側可能需要更廣的過濾；deletion vector 把位置標記集中到每個資料檔的向量，減少大量小刪除檔，卻把讀取過濾與向量維護成本前移。
第三步：建立快照提交邊界
刪除向量引用必須隨 Iceberg 快照原子提交，記錄資料檔路徑、向量位置、大小、校驗和與格式版本。生成任務固定輸入快照，不應原地修改既有向量；並行寫入失敗時重新基於最新快照合併，而不是覆蓋別人的刪除。
第四步：設計讀取路徑
規劃器先讀 manifest 與快照中繼資料，再載入適用的刪除向量。向量缺失、損壞或 reader 不支援時，安全做法是拒絕該快照或回退到相容刪除表示，不能把錯誤當成「沒有刪除」。快取鍵至少包含表、資料檔、snapshot ID 與向量版本。
第五步：規劃 compaction 與清理
當向量密度、隨機讀取開銷或刪除比例超過閾值時，將剩餘列重寫成新資料檔，並在新快照中移除舊檔案與向量。物件儲存生命週期、備份、跨區域複製與快照過期必須共同滿足刪除 SLA；只刪除 catalog 引用不能證明實體清理完成。
第六步：遷移舊 reader
盤點每個引擎的 format-version、delete-file 支援與快取行為。舊 reader 可暫時讀取由 position/equality delete 表示的相容快照，或透過物化視圖隔離；發布前禁止讓不理解向量的 reader 直接讀取含有此特性的快照。
第七步：驗證正確性與合規
構造並行刪除、重複刪除、刪除後更新、快照回滾、向量損壞與 compaction 中斷場景。對每個 snapshot 比較啟用和停用優化時的結果雜湊，抽樣檢查刪除請求對應列不可見，並記錄實體檔案、備份與複製的最後保留時間。
高品質示範回答
我會先確認所有 reader 能解析 Iceberg v3 與 deletion vector。刪除事務固定一個基線 snapshot，為每個資料檔生成列位置向量，並把引用與新快照原子提交；並行衝突就重讀最新快照後合併。查詢按 snapshot ID 載入向量，缺失或不支援時停止發布或回退到相容 delete 檔，絕不把錯誤當作空向量。向量密度達到閾值後 compaction 重寫剩餘列，舊檔案、快照、備份與複製按同一刪除 SLA 過期。驗收涵蓋並行刪除、損壞向量、回滾與中斷恢復，比較結果雜湊並出具實體清理證據。
常見錯誤
- 把 deletion vector 當成物件儲存上的立即擦除。
- 忽略單一資料檔只能安全關聯受約束的向量版本，直接原地覆蓋。
- 讓不支援 v3 的 reader 讀取含向量快照並期待自動忽略。
- 刪除 catalog 指標後就宣稱合規刪除完成。
- compaction 不檢查並行快照，導致新寫入或他人刪除遺失。
追問及應對
追問一：為什麼不總是用 equality delete？
它適合按業務鍵表達刪除，但讀取時可能要跨多個檔案匹配。已知實體位置且刪除頻繁時，位置向量可減少刪除檔數量；最終選擇要以 reader 支援與查詢代價實測為準。
追問二：向量損壞時可以回傳未過濾資料嗎？
不可以。回傳未過濾資料會重新暴露已刪除列。應校驗校驗和與版本，拒絕快照或回退到可信刪除表示，並告警修復。
追問三：刪除向量如何與更新配合？
更新通常產生新資料檔並標記舊列刪除。事務必須在同一快照提交新檔案與刪除引用，reader 按快照只看新列，避免舊列與新列同時可見。
追問四：如何定義 compaction 閾值？
用刪除比例、向量大小、隨機讀取放大、掃描延遲和儲存成本建立閾值，在代表性查詢與寫入負載上壓測；不應只按檔案數量猜測。
追問五：怎樣證明隱私刪除完成？
輸出列級不可見證明、引用快照過期記錄、重寫後檔案清單、物件版本刪除結果、備份與複製保留時間，以及抽樣掃描無命中證據。