1. 題干與適用情境
資料湖每天接收物件儲存檔案，經過 Parquet 寫入與表快照提交後供報表和模型讀取。團隊擔心網路傳輸截斷、磁碟或物件被替換、檔案後設資料與內容不一致，以及重試造成重複資料。你需要設計能定位問題邊界的完整性校驗，而不是只在任務結束時比較一個總筆數。
2. 面試官考察點
- 能把傳輸完整性、檔案內部損壞、表級一致性與業務正確性分開。
- 知道 checksum 是偵測意外變化的證據，不能證明業務語義正確，也不能單獨防止惡意竄改。
- 會區分寫入時校驗、讀取時校驗與背景巡檢，並說明成本與覆蓋率。
- 能給出可重播的隔離、告警、修復與稽核流程。
3. 回答前需要釐清的問題
- 目標是防傳輸錯誤、偵測靜默損壞，還是滿足合規留痕？不同目標會決定演算法與保存週期。
- 資料檔案是否不可變？若允許原地覆寫，必須把物件版本或內容摘要納入表快照。
- 可接受的發現延遲與誤報率是多少？即時校驗與每日全量巡檢的預算不同。
- 是否存在多格式、多物件儲存與跨區域複製？跨邊界複製需要在每一跳重新驗證。
4. 30 秒回答框架
「我會建立四層校驗：上傳時驗證物件 checksum，讀取時驗證 Parquet 頁級 CRC，提交表快照時驗證檔案清單與後設資料，業務側再用筆數、分區範圍與關鍵指標做對帳。每層保存演算法、摘要、物件版本、任務 ID 與時間戳。讀取失敗的檔案先隔離並從上游或副本重建；背景按風險抽樣並搭配全量巡檢，告警按資料集與影響範圍分級。最後把校驗結果寫入可查詢的稽核表，避免只在日誌中報錯。」
5. 分步驟深入解答
第一層是傳輸。生產者在上傳前計算摘要，儲存服務在接收時驗證；校驗失敗就拒絕物件並重試。Amazon S3 支援在單段與分段上傳中提供 checksum，並可在下載時再次要求校驗值；不能把 multipart 的 ETag 當成整個物件的 MD5。
第二層是檔案。Parquet 可以對每個資料頁計算 CRC32，讀取器可在頁解壓前發現損壞。頁級校驗能縮小損壞範圍，但不保證欄位值符合業務約束；應把檔案路徑、大小、格式版本與摘要寫入 manifest。
第三層是表快照。提交交易時產生不可變檔案清單，包含物件版本或內容摘要、分區、筆數與寫入任務 ID。新快照必須引用完整檔案集合；發現缺檔、重複檔或摘要變化時拒絕提交，避免壞檔案進入下游。
第四層是業務對帳。對關鍵分區計算筆數、空值率、金額總和、主鍵去重數等指標，並與上游帳本或前一版本比較。指標相同不代表內容相同，因此業務對帳應作為 checksum 之外的獨立訊號。
第五層是巡檢與修復。熱資料讀取時校驗，冷資料按風險抽樣；高價值或合規資料定期全量計算。Amazon S3 的 Batch Operations 可以非同步為大量靜態物件產生完整或分段 checksum 報告，適合背景巡檢。異常物件進入隔離區，保留原摘要、發現時間與快照引用，再從可信副本重建並重新提交。
6. 高品質示範回答
「我不會把 checksum 當作唯一的資料品質方案。上傳層驗證傳輸摘要，Parquet 讀取層啟用頁級 CRC，表提交層保存不可變 manifest、物件版本與任務 ID，業務層再對關鍵分區做筆數、主鍵與金額對帳。每次校驗記錄演算法、摘要與時間，讀取或巡檢失敗就隔離檔案，禁止繼續提交到新快照。即時讀取校驗熱資料，背景用風險抽樣覆蓋一般資料，合規資料定期全量巡檢。修復時從可信副本重建並重新計算摘要，稽核表保留原失敗證據。這樣能區分傳輸、儲存、表提交與業務邏輯問題，也能清楚說明每層成本與盲點。」
7. 常見錯誤
- 錯誤表現 → 只比較總筆數 → 檔案內容替換或重複列可能仍通過 → 增加物件摘要、主鍵去重與關鍵指標對帳。
- 錯誤表現 → 把 ETag 當成 multipart 檔案的 MD5 → 演算法語義不成立 → 保存明確宣告的 checksum 類型與物件版本。
- 錯誤表現 → 所有讀取都做全量強校驗 → 查詢延遲與成本不可控 → 熱資料同步校驗，冷資料按風險抽樣或批量巡檢。
- 錯誤表現 → 發現壞檔案後直接重跑整條管線 → 可能重複寫入好檔案 → 先隔離、按任務 ID 定位，只重建受影響檔案。
- 錯誤表現 → 用 checksum 證明業務正確 → 摘要只能證明位元組變化 → 另外維護業務對帳與資料品質規則。
8. 追問及應對
如果攻擊者替換檔案並同時更新摘要，怎麼辦？
普通 checksum 只解決意外損壞。需要受保護的簽章、存取控制、物件版本鎖與稽核鏈；把可信摘要存放在與寫入權限隔離的後設資料系統，並記錄誰批准了新版本。
全量巡檢預算只有每天一小時，如何取捨？
按資料價值、最近變更、歷史故障率與複製路徑評分，優先巡檢高風險分區；其餘使用讀取時校驗、抽樣與分層滾動覆蓋。報告覆蓋率與未檢查窗口，不能宣稱全庫已驗證。
怎樣避免修復任務再次造成重複資料？
修復任務使用原檔案 ID、目標快照與冪等寫入鍵；提交前檢查 manifest 是否已有相同內容摘要，成功後再原子更新快照指標。重試只重建失敗檔案，不重新追加已確認的檔案。