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

背景信息

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

同步原理

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

說明 在數據同步過程中，涉及到讀插件Reader，寫插件Writer。
  • Reader插件連接具體的數據源頭讀取數據，并將數據放到內部緩沖隊列，Writer插件從數據緩沖隊列消費數據并將數據寫出到目標存儲中。
  • 由Reader插件和Writer插件完成具體的數據同步過程，同步插件會遵循數據源本身的數據讀寫協議，以及數據讀寫規則（如數據約束等）。因此在檢查源頭、目標數據源的實際同步效果時，會受到實際數據讀寫協議、讀寫規則方面的影響。

寫端數據一致性排查

數據集成的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 updatePostgreSQL協議族的數據庫寫出模式，類似于MySQL協議的 insert into on duplicate key update。
  • 如果寫出數據和目標存儲已有數據發生數據約束（主鍵沖突、唯一鍵約束、外鍵約束等），數據庫則使用來源數據update更新目標表已有數據行，在目標表存在多個數據約束的情況下，數據替換可能會失敗并產生臟數據。
  • 如果寫出數據和目標存儲已有數據沒有發生數據約束，數據庫則將來源數據插入（和insert into行為限制一致）到目標存儲中。
copy on conflict do nothingPostgreSQL協議族的數據庫寫出模式，使用copy語法將數據寫出到目標端，并且在遇到沖突時丟棄來源數據，數據沖突不會導致臟數據；如果寫出數據和目標存儲已有數據沒有發生數據約束，數據庫則將來源數據插入到目標存儲中。
copy on conflict do updatePostgreSQL協議族的數據庫寫出模式，使用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中）。
  • 或者下游在查詢使用數據時，分區表達式沒有正確賦值，查詢使用了錯誤的分區數據。
檢查數據同步任務的調度變量表達式，即調度參數配置是否符合預期，調度時參數替換值是否符合預期。
數據類型、時區問題
  • 您的源頭表數據類型、數據范圍和目標表不一致，導致數據非預期的截斷，或者數據寫出臟數據失敗。
  • 數據源頭和目標端的時區不一致，導致兩側事件數據查詢對比不一致。
  • 確認源頭和目標類型、時區的差異。
  • 確認是否保持現狀，或者修改目標數據類和時區參數。
目標端數據發生了變化目標數據源也在持續變化中，可能有其他系統程序在訪問和更新目標數據源，導致目標數據源內容和源頭不一致。一般符合業務預期，可以解釋數據不一致原因即可。

讀端數據一致性排查

數據集成的Reader插件用來連接具體的源頭數據存儲，抽取出待同步的數據并投遞給同步寫端。每一個存儲類型都會有對應的Reader插件，Reader插件會根據用戶配置的數據抽取模式（包括數據過濾條件、表、分區、列等），使用JDBC或者對應數據源SDK最終將數據抽取出來。
說明 數據實際讀出效果和數據同步機制、源頭數據是否變化、任務配置等有關。
如果數據同步任務執行完成后，對于數據同步質量（數據條數、數據內容）有相關疑問，在讀取端您可以嘗試從下列常見情況對照排查：
問題問題描述解決方案
源頭數據在持續發生變化由于待讀取范圍的數據可能在持續變化中，因此實際同步到目標數據源的數據和源頭最新數據可能不匹配。事務一致性以關系數據庫為例，數據讀取本質上是對源頭數據源發起的數據查詢SQL。任務配置并發讀取時會切分出多個分片查詢SQL，由于數據庫事務一致性策略，每個查詢SQL查詢的都是當前提交時的數據快照，并且多個SQL并不在一個事務上下文內。因此在源頭數據變化時會同步不到查詢SQL之后的變化。這類原因導致的問題一般是符合預期的。這種情況一般多次運行同步任務每次同步的記錄條數會有差異。
錯誤的查詢檢查條件
  • 以MySQL為例，可以配置數據抽取過濾where條件，在where條件中有調度參數變量，具體如gmt_modify >= ${bizdate}，常見的錯誤是調度參數沒有合理的替換，比如需要最近兩天的數據卻只過濾讀取1天的數據。
  • 以MaxCompute為例，在讀取分區表時往往會對分區參數配置變量表達式，比如pt=${bizdate}，也容易出現分區參數未正確配置和替換的現象。
檢查數據同步任務的調度變量表達式，即調度參數配置是否符合預期，調度時參數替換值是否符合預期。
臟數據數據在讀取源頭存儲時失敗，導致出現讀端臟數據，進而目標數據源記錄條數和源頭對不上。
  • 確認臟數據出現的原因，并解決臟數據問題
  • 確認可否容忍忽略臟數據。
說明 讀端臟數據一般比較少見，主要出現在半結構化類型的數據源中，比如OSS、FTP、HDFS等。

環境信息排查

問題解決方案
查詢了錯誤或不完整的數據源、表、或者分區等。
  • DataWorks標準項目分為開發數據源、生產數據源，在開發環境運行任務使用開發數據源，在生產環境運行任務使用生產數據源，再對數據數量和內容比對時，需要確認下使用的數據源環境，避免開發、生產查詢不一致。
  • 在實際生產業務當中，在線數據源往往有對應的預發或者測試環境，而實際同步任務使用的生產數據庫和預發測試數據庫不一致，需要進行數據檢查對比是否有環境差異。
  • 在半結構化數據同步時往往涉及多個文件同步，您需要確認數據讀取、寫出的文件集合是否完整。
依賴產出未完成如果是周期產出的數據（周期的數據同步任務、周期的全增量數據融合Merge任務等），需要檢查下對應的數據產出任務是否正常執行并完成。
說明 通用排查在您遇到數據質量方面的疑惑時，您可以嘗試多次運行任務觀察比對數據同步效果，也可以嘗試切換源或者對目標數據源做對比測試，通過多次對比測試可以幫助您縮小問題排查范圍。