題幹與適用場景
支付系統說昨天有 1,000 筆訂單，但數倉報表只有 998 筆。請設計一條對帳流水線，找出來源系統、落地層、轉換模型和報表之間的差異。
回答不要求綁定 dbt、Airflow 或某個倉庫產品；重點是可重複的證據鏈。要區分記錄遺失、重複、金額不一致、延遲和業務口徑不同。
面試官考察點
對帳粒度
候選人應先定義業務鍵、時間語義和金額精度，再決定按訂單、商戶、日或批次對帳。只比較總數會掩蓋抵銷錯誤。
可解釋校驗
規則應同時檢查筆數、金額、狀態分布、主鍵唯一性和抽樣明細，並保留規則版本與輸入快照。
異常閉環
差異要分級、分派 owner、記錄證據、支援重播和人工結案；告警不能只發一封無法追蹤的郵件。
穩定運行
流水線要支援延遲資料、冪等重跑、分區範圍、schema 變更、資料新鮮度和稽核留痕，避免修復動作再次製造差異。
回答前需要釐清的問題
- 「昨天」按哪個時區和事件時間計算？
- 訂單的業務鍵是什麼，退款和取消如何計入？
- 來源系統是否允許延遲、更新或刪除？
- 數倉是批次、串流，還是兩者並存？
- 金額使用哪種幣別和小數精度？
- 差異需要自動修復、回補，還是先人工核准？
30 秒回答框架
「我會先固定同一時間窗和快照版本，按訂單業務鍵做筆數、金額和狀態對帳，再下鑽到遺失、重複、更新未到和轉換錯誤。每條差異保存規則版本、來源記錄摘要、數倉記錄摘要和 owner。延遲資料用 watermark 與重試視窗處理；修復透過冪等回補任務完成，最後重新對帳並關閉工單。所有執行、輸入範圍、結果和人工操作都寫入稽核表。」
分步驟深入解答
第一步：固定範圍與快照
記錄來源端擷取批次、事件時間範圍、處理時間、時區和快照 ID。對帳結果必須能回到同一批輸入，避免來源系統持續變化導致結果漂移。
第二步：建立標準化鍵
統一訂單 ID、商戶 ID、狀態映射、幣別和金額精度。來源記錄與數倉記錄保留雜湊或摘要，敏感欄位只保留最小必要資訊。
第三步：執行多層校驗
先檢查筆數和總金額，再按商戶、日期、狀態分組比較；隨後做主鍵唯一性、null、重複、金額容差和明細 anti-join。總額相等不代表明細正確。
第四步：辨識延遲與修訂
以事件時間和 watermark 區分尚未到達與真正遺失。對帳視窗允許補數，超過視窗仍有差異才升級；更新、退款和刪除要使用版本或變更時間重算。
第五步：分級與修復
按金額、訂單數、業務影響和持續時間分級。自動修復只執行冪等的回補或重播；涉及財務口徑的差異先人工核准，並記錄前後值和原因。
第六步：重跑與稽核
任務按快照 ID、分區和規則版本冪等執行。保存輸入範圍、查詢版本、指標結果、差異明細、告警、owner、重試次數和關閉時間，支援複盤。
高品質示範回答
「我會為每個來源批次產生 snapshot_id，並固定 UTC 事件時間窗。標準化層把訂單 ID、狀態、幣別和金額精度統一後，先做筆數、金額和狀態分布對帳，再用主鍵 anti-join 找出來源有數倉無、數倉有來源無、重複和金額不一致的記錄。
延遲事件由 watermark 和兩小時補數視窗區分；視窗內標記 pending，視窗後才升級。差異表保存規則版本、雙方記錄摘要、金額差、owner 和證據連結。自動回補任務以 snapshot_id 加業務鍵冪等重播，財務差異需要核准。每次修復後重新跑同一快照，結果連同輸入範圍、程式碼版本、告警和關閉時間寫入稽核表。」
常見錯誤
- 只比較總筆數 → 抵銷錯誤被掩蓋 → 按業務鍵做 anti-join 並保存明細差異。
- 把處理時間當作事件時間 → 跨時區和延遲記錄錯位 → 固定事件時間、處理時間和時區欄位。
- 沒有定義退款、取消、更新和刪除 → 各層口徑無法解釋 → 在狀態映射和版本規則中明確它們。
- 用浮點數比較金額 → 小數誤差製造假差異 → 使用整數最小貨幣單位、幣別和容差。
- 延遲資料一律告警 → 噪音導致誤修復 → 用 watermark 與補數視窗先標記 pending。
- 回補任務非冪等 → 重跑後產生重複記錄 → 以快照和業務鍵做冪等 upsert。
- 差異沒有 owner、證據和關閉狀態 → 無法追責或複盤 → 建立差異工單和稽核欄位。
- 只保存最終數字 → 無法重現當時結果 → 保存輸入快照、規則版本和程式碼版本。
追問及應對
追問一：總額相同但記錄不同怎麼辦？
使用業務鍵 anti-join、重複鍵檢查和分組分布比較，找出一增一減的抵銷錯誤；把明細差異保存在差異表。
追問二：如何避免延遲資料誤報？
用事件時間、watermark 和明確的補數視窗。視窗內狀態為 pending，超過視窗仍不一致才升級，並記錄視窗設定版本。
追問三：修復任務如何安全重跑？
以 snapshot_id、分區和業務鍵作為冪等鍵，寫入採用 upsert 或去重，重跑前後比較計數與金額，失敗可安全重試。
追問四：如何驗證對帳規則本身？
用已知遺失、重複、延遲、退款和幣別樣本做 fixture，測試規則版本、容差、邊界日期和時區，並監控誤報率。
追問五：如何安排告警和責任？
按金額、數量、持續時間和業務等級路由到 owner；告警連結到差異批次、證據和修復動作，關閉必須填寫原因並可稽核。
來源一：dbt sources 與來源測試
dbt Developer Hub 的 sources 文件說明 source 可用於定義來源、建立 lineage、加入資料測試並檢查 freshness，適合作為對帳輸入的治理參考。
來源二：freshness 與 SLA
dbt Developer Hub 的 source freshness 文件展示用 loaded-at 欄位、warn/error 閾值和快照結果管理資料新鮮度，可用於設計延遲資料與升級視窗。
來源三：資料品質檢查
dbt Labs 的資料品質文章涵蓋唯一性、關係、空值和 freshness 等檢查，說明自動化校驗應與版本化模型和告警結合。