先定義完整性，而不是先寫筆數檢查
來源系統與資料倉儲的對帳，不能只比較總筆數。來源資料可能在擷取期間持續新增或更新，倉儲也可能因去重、維度展開、時區轉換或商業規則而產生合理的筆數差異。工程團隊應先定義對帳邊界：比較哪個來源物件、哪段業務時間、哪個資料版本，以及倉儲中的哪一層。若這些條件不明確，即使兩邊筆數相同，也可能只是遺漏與重複剛好互相抵消。
實務上可將完整性拆成三層。傳輸完整性確認來源紀錄是否抵達落地區；轉換完整性確認欄位映射、型別與計算規則是否正確；業務完整性則檢查訂單金額、庫存異動或客戶狀態等結果是否符合領域規則。三層應分別留下證據，否則發現報表異常時，很難判斷問題出在來源、擷取、轉換，還是報表語意。
用穩定的批次邊界建立對帳帳本
每次擷取都應產生一筆對帳帳本，至少記錄來源、資料集、批次識別碼、擷取起訖時間、來源浮水位、完成時間、狀態與重跑關係。浮水位可以是遞增主鍵、更新時間或 CDC 位點，但選擇時要理解限制：更新時間可能回填或碰撞；遞增鍵無法捕捉舊資料修改；CDC 能保留變更順序，卻需要處理日誌保留、結構變更與斷點續傳。
來源仍在變動時，不要直接拿「現在的來源」比較「昨天載入的倉儲」。較可靠的方式是使用來源快照、可重現的查詢時間點，或保存批次所涵蓋的鍵值與浮水位區間。對帳粒度應細到能定位問題，但不必逐列比較所有欄位。常見做法是依日期、租戶、門市或資料分區記錄下列指標：
- 筆數與唯一鍵數：同時偵測遺漏、重複與主鍵品質問題。
- 新增、更新與刪除數：避免只驗證新增資料，卻漏掉狀態修正或來源刪除。
- 關鍵欄位空值與型別錯誤：找出解析失敗、欄位位移或結構變更。
- 可加總業務量：比較金額、數量或點數，但需固定幣別、符號與四捨五入規則。
- 分區雜湊或列級雜湊：適合驗證大量欄位；雜湊前必須統一空值、字串編碼、欄位順序與時間格式。
把合理差異與真正缺陷分開
對帳規則必須反映資料模型。來源的一筆客戶資料，進入歷史維度表後可能變成多個版本；取消訂單可能在倉儲中保留而非刪除；跨午夜的時區換算也會讓每日筆數移動。這些差異不能靠放寬門檻處理，而應明確定義可解釋的轉換關係。例如先比較落地區與來源的一對一完整性，再以獨立規則驗證維度版本區間、事實表外鍵與彙總結果。
延遲到達資料需要特別設計。若來源允許補登或離線裝置稍後同步，只以最新更新時間增量擷取容易漏資料。可採用重疊擷取視窗，再以穩定業務鍵與版本欄位進行冪等合併；代價是增加讀取與運算量。另一種方式是依 CDC 位點處理，但仍需安排週期性回溯對帳，找出日誌缺口或來源端未正確產生變更事件的紀錄。刪除也應有一致策略，例如軟刪除旗標、墓碑事件或定期全量鍵值比對。
讓差異可以定位、修復與追蹤
好的警示不只顯示「數量不一致」，還要附上批次、分區、指標、預期值、實際值與少量差異鍵值。對帳結果應寫入獨立、可查詢的控制表，不要只留在工作排程器日誌。警示嚴重度可依影響區分：主鍵遺漏或金額不平通常應阻擋發布；非關鍵描述欄位的格式差異可以隔離後繼續處理；延遲但仍在服務時限內的資料則先觀察。
修復流程必須具備冪等性。工程團隊應能針對指定批次或分區重新擷取、重新轉換及重新對帳，而不製造重複資料。原始落地資料宜保留到足以涵蓋調查與重跑週期，並記錄程式版本、結構版本及規則版本。最後，為每項對帳指定負責人與處理時限：資料平台負責傳輸與批次狀態，領域團隊確認業務規則，來源系統團隊處理上游缺陷。若差異無人負責，再完整的監控也只會累積成沒有人閱讀的告警。