資料工程面試：如何設計可稽核的分散式資料刪除管道？

題幹與適用場景

題目考察資料工程師能否把一次刪除請求變成跨系統、可重試、可稽核的生命週期流程。刪除不只是主庫 DELETE，還涉及派生表、快取、搜尋索引、事件流、備份和第三方處理者。回答應處理資料發現、身份關聯、法律保留、冪等、失敗恢復和完成證明。

面試官考察點

強回答會先定義刪除範圍與例外，再建立資料目錄和 owner 映射；請求進工作流後，按依賴發出刪除或匿名化命令，等待每個系統回執。它會區分 requested、running、verified 和 blocked，並用不可變稽核日誌證明每一步。不能立即擦除物理備份時，應說明加密擦除、到期覆蓋和存取隔離。

回答前需要釐清的問題

• 辨識使用者的鍵是什麼？是否有郵箱、裝置、訂單和匿名識別的關聯表？
• 哪些資料必須刪除，哪些因發票、欺詐調查或法律保留暫時不能刪？
• 是否包含搜尋索引、快取、分析聚合、事件日誌、物件儲存、備份和第三方 SaaS？
• 目標是物理刪除、不可逆匿名化，還是期限內停止使用？
• 如何定義完成、超時、人工複核和對使用者回覆？

30 秒回答框架

「我先用資料目錄登記系統、欄位、owner、保留策略和刪除能力，接收請求後產生不可變 deletion case 和冪等任務。編排器按依賴發出刪除、匿名化或加密擦除命令，每個消費者返回版本、範圍和校驗摘要；失敗任務可重試並進人工佇列。法律保留資料只凍結存取並記錄例外，到期後再刪除。最後用目錄覆蓋率、回執、抽樣查詢和稽核日誌證明完成。」

分步深入解答

第一步：建立資料地圖與身份圖

目錄記錄系統、表/桶/索引、欄位分類、owner、下游依賴、備份週期和處理者。身份圖把穩定使用者 id 映射到訂單、裝置、郵箱和匿名 token；沒有可靠映射就不能聲稱刪除完整。

第二步：定義刪除策略

把記錄分成直接刪除、匿名化、聚合保留和法律凍結。財務憑證或欺詐證據可能必須保留，但應最小化欄位、限制存取並記錄法源。策略版本化，避免政策變化後無法解釋舊請求。

第三步：建立冪等刪除案件

請求產生 case_id、主體 id、策略版本、截止時間和來源。每個系統收到帶 case_id 的命令，重複執行返回同一結果；狀態至少包括 requested、running、verified、blocked、failed 和 expired。

第四步：按依賴傳播

先刪除來源記錄或發出 tombstone，再觸發 CDC、搜尋索引、快取和派生倉庫消費者。無法即時刪除的批次系統寫入抑制表，避免後續重新產生已刪主體。第三方透過有回執 API 或合約流程確認。

第五步：處理備份與加密擦除

備份通常按週期過期，無法逐筆修改時應隔離恢復權限、標記刪除名單，並在恢復流程重新套用刪除。高敏感物件可用每主體資料金鑰，刪除金鑰令密文不可恢復；這不是所有法規的萬能方案。

第六步：驗證而非只看成功碼

消費者回傳刪除計數、版本、分割區和校驗摘要。編排器抽樣查詢主庫、索引、倉庫和物件儲存，檢查快取失效與 CDC 水位；驗證失敗進補償任務。

第七步：隔離保留例外

法律凍結記錄單獨儲存，欄位最小化並禁止產品查詢。案件報告列出凍結範圍、法源、owner 和複審日期；解除凍結後自動產生新的刪除任務。

第八步：稽核、告警與使用者回覆

稽核日誌只記錄主體不可逆摘要、操作者、時間、策略版本和結果，不複製敏感原文。監控未完成案件年齡、失敗率、目錄覆蓋率、第三方回執和恢復演練。使用者看到已完成、處理中或受法律保留影響的狀態。

刪除工作流偽代碼

case = create_case(subject, policy_version)
for target in catalog.targets(subject, policy_version):
    enqueue_idempotent(case.id, target, action_for(target))
verify_samples(case)
close(case, "verified" if all_verified(case) else "blocked")

設計取捨與邊界

刪除證明應覆蓋查過哪些地方、哪些地方收到回執、哪些地方暫時例外，不承諾無法驗證的絕對物理消失。Google Cloud 文件也將流程拆成多階段。

落地計畫與證據

先選一個使用者資料集，完成目錄、身份映射和主庫、索引、倉庫三類消費者接入。用故障注入測試重複訊息、消費者離線、恢復備份和策略變更。歐盟委員會說明刪除權存在法定例外；Google Cloud 說明刪除管道的階段性；TechInterview 題目要求覆蓋微服務、物件儲存、分析系統、備份和稽核軌跡。

試點退出條件

目錄覆蓋率可計算；每個目標有 owner 與能力；重複請求冪等；失敗可重試或升級；抽樣驗證能發現殘留；保留例外有依據和到期日；使用者回覆與內部狀態一致。

如何證明收益不是巧合

比較接入前後未登記資料集數、案件完成時間、驗證發現殘留率、重試率和人工介入量，並演練消費者離線、備份恢復和第三方超時。

常見誤區與追問

只刪除主庫資料列

索引、快取、倉庫和物件儲存可能繼續返回資料。目錄和下游回執必須是完成條件。

用一個全域 DELETE 事件解決所有系統

不同消費者需要不同動作和版本；沒有冪等、回執和水位，事件會遺失或重複。應使用帶 case id 的工作流。

聲稱備份能立即物理刪除

許多備份按週期過期。應說明存取隔離、刪除名單、恢復重播和最終覆蓋時間。

法律保留如何不阻塞全部刪除？

把保留範圍縮到必要欄位與記錄，凍結存取並記錄法源、owner 和複審日期，其餘資料繼續刪除。

如何防止刪除後又被回填？

來源端寫入 tombstone 或抑制表，CDC 和批次在產生派生資料前檢查刪除狀態，重播時再次套用策略。

使用者要求立即完成怎麼辦？

誠實區分已驗證目標與有期限的備份/第三方步驟，返回處理中狀態和截止時間，不編造已完成的物理刪除。