DataWorks：單表即時同步營運與調優

啟動和停止

• 啟動任務後，先確認結構準備是否完成，再觀察全量初始化是否啟動和推進，最後確認即時增量是否持續有讀取和寫入。訊息源任務需要同時觀察消費位點和訊息堆積；資料庫日誌型任務需要關注 Binlog、WAL 或日誌保留時間。

• 停止任務前，確認源端日誌或訊息保留時間是否能覆蓋停機視窗。停機時間超過保留期後，任務可能無法從原位點恢複，通常需要重設位點、跳過歷史積壓或重新初始化，執行前需要評估重複寫入和資料丟失風險。

修改配置

單表即時任務常見修改包括調整欄位對應、主鍵、寫入模式、分區規則、並發、資源、位點和髒資料策略。

警示配置

單表即時任務建議至少關注任務狀態、業務延遲和 Failover。根據通道能力和任務配置，再補充資源使用率、寫入異常、DDL 通知、訊息堆積量。

訊息源任務還需要關注源端 Topic、Shard、Logstore 或消費組的積壓；資料庫日誌型任務需要關注 Binlog、WAL、歸檔日誌或複製槽保留情況。只配置任務失敗警示，無法發現任務仍在運行但延遲持續升高、寫入變慢或位點長期不推進的問題。

任務無資料輸出

任務顯示運行中但目標端沒有新資料時，先確認源端是否真的有新增資料，再區分是讀端沒有消費、鏈路處理異常，還是寫端沒有提交。

排查順序：

1. 檢查源端表、Topic、Logstore 或日誌位點是否有新增資料。

2. 檢查任務是否處於全量初始化、即時增量或 Failover 狀態。

3. 檢查讀取指標、寫入指標、業務延遲和 Checkpoint 是否正常推進。

4. 檢查目標表、目標資料分割、主鍵和寫入模式是否符合配置。

5. 檢查是否存在髒資料、欄位對應失敗或目標端許可權問題。

如果運行詳情中的 DML/DDL 統計短時間沒有資料，但日誌和目標端寫入正常，應同時排查指標採集延遲或採集異常，避免把監控展示問題誤判為同步中斷。

全量初始化慢或失敗

全量初始化慢時，先確認瓶頸在源端讀取、網路、資源群組、目標端寫入，還是切分不均。

全量階段不要只看平均吞吐。少數大分區、寬表、大欄位或熱點分區可能決定整體完成時間。

即時延遲升高

即時延遲升高時，先看延遲是否持續下降。如果任務剛完成全量初始化，即時鏈路可能正在回放全量期間積累的增量資料；如果延遲持續增長，再定位瓶頸在讀端、寫端、資源、網路還是外部系統。

建議按以下順序排查：

1. 在任務運行詳情中查看視窗等待時間，判斷瓶頸主要在讀端還是寫端。

2. 查看延遲時間段的任務日誌，搜尋 Error、Exception、OutOfMemory 等關鍵字。

3. 查看 Failover 記錄，確認是否存在頻繁 Failover、OOM 或外部服務異常。

4. 查看運行指標和事件，重點關注吞吐、反壓、Checkpoint、JVM 記憶體、GC、DDL 事件和髒資料。

5. 再按源端、目標端、資源、並發和網路繼續定位原因，不建議在未定位瓶頸前直接加並發或資源。

視窗等待時間可以作為第一層判斷：

明確瓶頸所在的位置後，可針對不同的現象進一步排查：

• Kafka、DataHub、LogHub 等訊息源要重點看分區或 Shard 數量。單個分區或 Shard 通常只能被一個並發消費，資料集中在少數分區時，單純增加總並發不一定有效。可以結合不同 Reader 線程的累計位元組數和源端監控，判斷是否存在熱點分區或熱點 Shard。

• MySQL 等資料庫日誌型源端要重點看大事務、大量 DML、頻繁 DDL 和 Binlog 增長速率。如果同步速度不高但延遲持續增加，建議結合源庫審計日誌、CPU、IO、串連數和 Binlog 增長情況判斷是否存在源端壓力或未同步庫表產生大量 Binlog。

• 寫入 MaxCompute 時，如果日誌出現 uploader map size has reached uploaderMapMaximumSize，通常說明單個 Flush 間隔內動態分區值過多。優先調整分區粒度或動態分區欄位，避免使用秒級時間、訂單號、使用者識別碼 等高基數欄位作為分區值，再評估是否需要增加並發或資源。

DDL 事件處理異常

DDL 後任務失敗、延遲升高或目標端結構不一致時，先確認當前通道是否支援該 DDL 類型，以及任務中對該 DDL 的處理策略。

排查重點：

• 源端發生了哪些 DDL，例如加列、刪列、改類型、重新命名、建表、刪表、索引變更。

• 目標端是否支援相同 DDL 或等價結構變更。

• 任務策略是正常處理、忽略、警示還是停止。

• 目標端帳號是否具備改表許可權。

• DDL 前後欄位對應、主鍵和分區是否仍一致。

不支援的 DDL 不建議直接忽略。忽略 DDL 可能讓任務繼續運行，但後續 DML 寫入可能因為欄位不匹配、主鍵變化或目標端結構不一致繼續失敗。

Update 或 Delete 不符合預期

Update、Delete 後目標端資料不符合預期時，優先檢查目標端是否具備可定位記錄的主鍵或唯一鍵，以及源端和目標端主鍵映射是否一致。

常見原因包括：

• 目標端沒有主鍵或唯一鍵，無法按記錄更新或刪除。

• 源端主鍵和目標端主鍵不一致。

• 主鍵欄位被轉換、重新命名或寫入為空白。

• 目標端寫入模式不支援更新或刪除。

• 任務配置了忽略 Delete 或特殊寫入策略。

• 寫入失敗被記錄為髒資料，但任務仍繼續運行。

處理時先用少量範例記錄核對源端事件、任務映射和目標端結果，再決定是否調整主鍵、寫入模式或重新初始化目標表。

髒資料增多

髒資料增多時，不建議直接放大髒資料閾值。先確認髒資料是否會導致目標端缺數、欄位為空白、欄位截斷、主鍵衝突或分區異常。

排查重點：

• 欄位類型、長度、精度和非空約束是否匹配。

• 目標端主鍵、唯一鍵或分區欄位是否滿足要求。

• 源端是否新增了超長字串、非法編碼、特殊 JSON、不可解析時間或不支援的資料類型。

• 目標端是否有限流、寫入失敗或服務端過濾。

只有確認業務可以接受丟棄這些異常記錄時，才考慮臨時提高髒資料閾值，並在後續修複源端資料或目標端結構。