離線同步資料品質排查 - DataWorks

本文將為您列舉一些常見資料品質方面的情境，方便您排查是否存在符合的情境，根據對應解決方案解決資料同步品質問題。

背景資訊

講述Data Integration資料同步的原理機制，理解資料同步的過程，進而對資料同步的執行效果有判斷能力，判斷資料同步效果具體包括：資料同步的資料量、目標端資料實際數量等。

同步原理

DataWorksData Integration的同步任務在執行時稱之為一個Job，為了最大化提高資料同步的效率，任務在執行時會將split切分成多個子作業，每個子作業稱之為一個Task。這些Task以單機或者多機的方式並發執行，每個Task讀取一個資料區間內的資料，多個Task最終完成整體的資料同步業務。

說明在資料同步過程中，涉及到讀外掛程式Reader，寫外掛程式Writer。

Reader外掛程式串連具體的資料來源頭讀取資料，並將資料放到內部緩衝隊列，Writer外掛程式從資料緩衝隊列消費資料並將資料寫出到目標儲存中。
由Reader外掛程式和Writer外掛程式完成具體的資料同步過程，同步外掛程式會遵循資料來源本身的資料讀寫協議，以及資料讀寫規則（如資料約束等）。因此在檢查源頭、目標資料來源的實際同步效果時，會受到實際資料讀寫協議、讀寫規則方面的影響。

寫端資料一致性排查

Data Integration的Writer外掛程式用來將源頭讀取到的資料寫出至資料目標端，每一個目標儲存類型都會有對應的Writer外掛程式，Writer外掛程式會根據使用者配置的資料寫出模式（包括衝突替換策略），使用JDBC或者對應資料來源SDK最終將資料提交給目標儲存。

說明資料實際在目標端寫出效果和資料內容，寫出模式、目標資料表條件約束資訊有關。

如果資料同步任務執行完成後，對於資料同步品質（資料條數、資料內容）有相關疑問，在寫出端您可以嘗試從下列常見情況對照排查：

原因	問題描述	解決方案
寫出模式選擇導致	Writer外掛程式會使用選擇的寫出模式將源頭資料在目標端執行重放，如果源頭資料和目標表結構出現資料約束，會對應導致資料插入失敗（髒資料）、資料插入忽略、資料插入替換等行為。	使用正確的寫出模式，評估資料內容約束是否存在，以及是否合理。以下介紹最常見的關係型資料庫的寫出模式（不同資料來源類型寫出模式不同）：
		insert into	將資料使用insert into的SQL語句寫出至目標端，如果寫出資料和目標儲存已有資料發生資料約束（主鍵衝突、唯一鍵約束、外鍵約束等），則來來源資料會作為髒資料，不會實際寫出至目標端。您可以留意同步處理記錄中的髒資料條數和內容資訊。
		replace into	將資料使用replace into的SQL語句寫出到目標端。如果寫出資料和目標儲存已有資料發生資料約束（主鍵衝突、唯一鍵約束、外鍵約束等），資料庫則使用來來源資料替換目標表已有資料，在目標表存在多個資料約束的情況下，資料替換可能會替換掉多條目標記錄如果寫出資料和目標儲存已有資料沒有發生資料約束，資料庫則將來來源資料插入（和insert into行為限制一致）到目標儲存中。
		insert into on duplicate key update	將資料使用insert into on duplicate key update的SQL語句寫出到目標端。如果寫出資料和目標儲存已有資料發生資料約束（主鍵衝突、唯一鍵約束、外鍵約束等），資料庫則使用來來源資料update更新目標表已有資料行，在目標表存在多個資料約束的情況下，資料替換可能會失敗併產生髒資料如果寫出資料和目標儲存已有資料沒有發生資料約束，資料庫則將來來源資料插入（和insert into行為限制一致）至目標儲存中。
		insert ignore into	將資料使用insert ignore into的SQL語句寫出到目標端。如果寫出資料和目標儲存已有資料發生資料約束（主鍵衝突、唯一鍵約束、外鍵約束等），資料庫會忽略來來源資料不會寫入到表中，資料寫出動作為成功並且不會產生髒資料。如果寫出資料和目標儲存已有資料沒有發生資料約束，資料庫則將來來源資料插入（和insert into行為限制一致）到目標儲存中。
		insert on conflict do nothing	PostgreSQL協議族的資料庫寫出模式，類似於MySQL協議的insert ignore into。如果寫出資料和目標儲存已有資料發生資料約束（主鍵衝突、唯一鍵約束、外鍵約束等），資料庫會忽略來來源資料不會寫入到表中，資料寫出動作為成功並且不會產生髒資料。如果寫出資料和目標儲存已有資料沒有發生資料約束，資料庫則將來來源資料插入（和insert into行為限制一致）到目標儲存中。
		insert on conflict do update	PostgreSQL協議族的資料庫寫出模式，類似於MySQL協議的 insert into on duplicate key update。如果寫出資料和目標儲存已有資料發生資料約束（主鍵衝突、唯一鍵約束、外鍵約束等），資料庫則使用來來源資料update更新目標表已有資料行，在目標表存在多個資料約束的情況下，資料替換可能會失敗併產生髒資料。如果寫出資料和目標儲存已有資料沒有發生資料約束，資料庫則將來來源資料插入（和insert into行為限制一致）到目標儲存中。
		copy on conflict do nothing	PostgreSQL協議族的資料庫寫出模式，使用copy文法將資料寫出到目標端，並且在遇到衝突時丟棄來來源資料，資料衝突不會導致髒資料；如果寫出資料和目標儲存已有資料沒有發生資料約束，資料庫則將來來源資料插入到目標儲存中。
		copy on conflict do update	PostgreSQL協議族的資料庫寫出模式，使用copy文法將資料寫出到目標端，並且在遇到衝突時替換目標資料來源已有資料，資料衝突不會導致髒資料；如果寫出資料和目標儲存已有資料沒有發生資料約束，資料庫則將來來源資料插入到目標儲存中。
		merge into	目前暫不支援。
髒資料	資料在寫出至目標儲存時失敗，導致出現髒資料，進而目標資料來源記錄條數和源頭資料不匹配。	確認髒資料出現的原因，並解決髒資料問題，或者確認可否容忍忽略髒資料。說明若您任務不允許產生髒資料，您可以在任務配置 > 通道配置處，修改該閾值。配置任務髒資料閾值，詳情請參見通過嚮導模式配置離線同步任務，關於髒資料認定，詳情請參見基本概念。
資料同步執行過程中就進行了資料查詢	部分Writer外掛程式在資料同步完成前，會有同步完成才可見（比如Hive、MaxCompute（可配）等）、部分可見等行為。	您需要在同步任務完成後再執行資料查詢。
沒有合理的節點依賴	資料同步任務和資料分析任務沒有配置合理的節點依賴，但是有資料依賴，比如下遊使用max_pt找到MaxCompute的最大分區並讀取分區的資料，但是最大分區對應的資料同步任務還未完成。	上下遊節點要建立節點依賴，避免使用max_pt這類的弱資料依賴，避免下遊消費資料時資料不完整。
目標表、分區有多個同步任務同時在執行，併產生了幹擾	不合理的同步任務並發執行。	如果是同節點多周期執行個體導致的衝突，建議配置任務調度自依賴，詳情請參見依賴上一周期：本節點（自依賴）。以MaxCompute、Hologres為例，2個任務寫同一個分區資料（同步前清理分區資料 truncate），第一個任務寫出的資料可能會被第2個同步任務清理掉。關聯式資料庫配置了前置處理preSql、後置處理postSql等，第一個任務寫出的資料可能會被第2個同步任務的前後置SQL幹擾。
任務配置不能等冪執行	一個任務重複運行多次最終的同步效果是一致等價的。如果任務配置不能等冪執行，而對任務又執行了多次重跑（包括成功後重跑，失敗後重跑），可能會導致目標端資料又重複或者覆蓋。	不建議多次運行一個任務。說明若您配置了任務不可重跑，但是為保障任務產出的時效性，建議您為該任務設定監控警示，確保在任務異常時可以第一時間收到警示並及時處理異常，設定警示詳情請參見：智能監控概述。
錯誤的查詢檢查條件	以MaxCompute為例，大多數情況下資料表都是分區表，分區值是DataWorks調度參數如$bizdate，常見的錯誤：調度參數沒有合理的替換，即資料寫出到$bizdate這個字面值分區中，而非實際的業務日期（如20230118中）。或者下遊在查詢使用資料時，分區運算式沒有正確賦值，查詢使用了錯誤的分區資料。	檢查資料同步任務的調度Variant 運算式，即調度參數配置是否符合預期，調度時參數替換值是否符合預期。
資料類型、時區問題	您的源頭表資料類型、資料範圍和目標表不一致，導致資料非預期的截斷，或者資料寫出髒資料失敗。資料來源頭和目標端的時區不一致，導致兩側事件數目據查詢對比不一致。	確認源頭和目標類型、時區的差異。確認是否保持現狀，或者修改目標資料類和時區參數。
目標端資料發生了變化	目標資料來源也在持續變化中，可能有其他系統程式在訪問和更新目標資料來源，導致目標資料來源內容和源頭不一致。	一般符合業務預期，可以解釋資料不一致原因即可。

讀端資料一致性排查

Data Integration的Reader外掛程式用來串連具體的源頭資料存放區，抽取出待同步的資料並投遞給同步寫端。每一個儲存類型都會有對應的Reader外掛程式，Reader外掛程式會根據使用者配置的資料幫浦模式（包括資料過濾條件、表、分區、列等），使用JDBC或者對應資料來源SDK最終將資料幫浦出來。

說明資料實際讀出效果和資料同步機制、源頭資料是否變化、任務配置等有關。

如果資料同步任務執行完成後，對於資料同步品質（資料條數、資料內容）有相關疑問，在讀取端您可以嘗試從下列常見情況對照排查：

問題	問題描述	解決方案
源頭資料在持續發生變化	由於待讀取範圍的資料可能在持續變化中，因此實際同步到目標資料來源的資料和源頭最新資料可能不匹配。事務一致性以關聯式資料庫為例，資料讀取本質上是對源頭資料來源發起的資料查詢SQL。任務配置並發讀取時會切分出多個分區查詢SQL，由於資料庫事務一致性策略，每個查詢SQL查詢的都是當前提交時的資料快照，並且多個SQL並不在一個事務上下文內。因此在源頭資料變化時會同步不到查詢SQL之後的變化。	這類原因導致的問題一般是符合預期的。這種情況一般多次運行同步任務每次同步的記錄條數會有差異。
錯誤的查詢檢查條件	以MySQL為例，可以配置資料幫浦過濾where條件，在where條件中有調度參數變數，具體如`gmt_modify >= ${bizdate}`，常見的錯誤是調度參數沒有合理的替換，比如需要最近兩天的資料卻只過濾讀取1天的資料。以MaxCompute為例，在讀取分區表時往往會對分區參數組態變數運算式，比如`pt=${bizdate}`，也容易出現分區參數未正確配置和替換的現象。	檢查資料同步任務的調度Variant 運算式，即調度參數配置是否符合預期，調度時參數替換值是否符合預期。
髒資料	資料在讀取源頭儲存時失敗，導致出現讀端髒資料，進而目標資料來源記錄條數和源頭對不上。	確認髒資料出現的原因，並解決髒資料問題確認可否容忍忽略髒資料。說明讀端髒資料一般比較少見，主要出現在半結構化類型的資料來源中，比如OSS、FTP、HDFS等。

環境資訊排查

問題	解決方案
查詢了錯誤或不完整的資料來源、表、或者分區等。	DataWorks標準專案分為開發資料來源、生產資料來源，在開發環境運行任務使用開發資料來源，在生產環境運行任務使用生產資料來源，再對資料數量和內容比對時，需要確認下使用的資料來源環境，避免開發、生產查詢不一致。在實際生產業務當中，線上資料來源往往有對應的預發或者測試環境，而實際同步任務使用的生產資料庫和預發測試資料庫不一致，需要進行資料檢查對比是否有環境差異。在半結構化資料同步時往往涉及多個檔案同步，您需要確認資料讀取、寫出的檔案集合是否完整。
依賴產出未完成	如果是周期產出的資料（周期的資料同步任務、周期的全增量資料融合Merge任務等），需要檢查下對應的資料產出任務是否正常執行並完成。

說明通用排查在您遇到資料品質方面的疑惑時，您可以嘗試多次運行任務觀察比對資料同步效果，也可以嘗試切換源或者對目標資料來源做對比測試，通過多次對比測試可以協助您縮小問題排查範圍。