本文為您介紹實時同步任務延遲時的自助解決方案。
確認造成延遲問題在同步任務的讀端還是寫端
如果是在DataStudio創(chuàng)建的實時同步任務，您需要在界面單擊運行中的任務名稱，彈出任務運行詳情對話框。詳情請參見實時同步任務運行與管理。
在任務運行詳情中，查看窗口等待時間（5 min），該指標表示最近5分鐘窗口內，同步任務讀取數(shù)據(jù)或寫入數(shù)據(jù)的等待時間。用于幫助您判斷數(shù)據(jù)同步延遲的瓶頸方，當數(shù)據(jù)同步發(fā)生延遲時，指標數(shù)據(jù)較大的一般為瓶頸方。
確認造成延遲問題的系統(tǒng)是否有異常
當確認了延遲瓶頸是在同步任務的讀端還是寫端后，可在上述任務運行詳情中切換至日志頁簽，使用Error/error/Exception/exception/OutOfMemory等關鍵字搜索，查看在延遲時間段內是否有類似下圖所示的相關異常棧，如果有，根據(jù)異常信息，參考常見異常處理辦法，判斷是否可以通過優(yōu)化任務配置進行解決。
實時同步任務從一個系統(tǒng)讀數(shù)據(jù)，并將數(shù)據(jù)寫入另一個系統(tǒng)，當寫數(shù)據(jù)比讀數(shù)據(jù)慢時，則讀數(shù)據(jù)一側的系統(tǒng)會受到反壓，導致速度變慢。即造成瓶頸的系統(tǒng)可能會由于反壓導致另一側系統(tǒng)的一些異常，此時要優(yōu)先關注造成瓶頸的系統(tǒng)的異常情況。
確認實時同步任務是否有頻繁O(jiān)OM
您還可以在上述任務運行詳情界面中切換到Failover頁面，確認任務是否有頻繁的Failover（10分鐘內發(fā)生1一次以上Failover則表示頻繁），如果有，可在Failover事件列查看導致Failover的異常信息，并單擊查看詳情鏈接查看Failover發(fā)生前的完整任務日志，如果在Failover事件列的異常信息或者任務運行日志中能夠搜索到OutOfMemory關鍵字的異常信息，則說明實時同步任務內存設置不足，需要加大任務內存設置。
任務內存設置方法如下：
對于DataStudio新建的單表到單表ETL實時同步任務，您可以單擊右側的基本配置設置任務內存。
在DataStudio新建的數(shù)據(jù)庫遷至DataHub等類型實時同步任務，您可以單擊右側的基本配置設置任務內存。
同步解決方案任務，您可以在運行資源設置步驟中設置內存。
確認源端數(shù)據(jù)是否有傾斜或者是否需要擴展分區(qū)或shard的數(shù)量
對于源端是Kafka、DataHub和Loghub三種類型的實時同步任務，如果根據(jù)上述步驟未發(fā)現(xiàn)異常或Failover，則需要檢查源端系統(tǒng)數(shù)據(jù)是否有傾斜或者分區(qū)、shard的讀取流量是否達到了同步速率的上限。
對于源端是Kafka、DataHub和Loghub三種類型的實時同步任務，每個分區(qū)或者shard只能由一個并發(fā)消費，如果存在寫入源端系統(tǒng)的數(shù)據(jù)集中在個別分區(qū)或者shard，而其他分區(qū)或shard數(shù)據(jù)很少的情況，則很可能導致數(shù)據(jù)傾斜分區(qū)或shard的消費瓶頸，造成延遲。此時將無法通過數(shù)據(jù)集成任務設置解決延遲問題，需要從Kafka、DataHub和Loghub系統(tǒng)的上游數(shù)據(jù)生產側解決數(shù)據(jù)寫入傾斜問題后，延遲問題才能恢復。
您可以通過在上述任務運行詳情中切換到運行信息頁簽，查看不同Reader線程總字節(jié)數(shù)統(tǒng)計，如果有個別Reader現(xiàn)場總字節(jié)數(shù)明顯大于其他Reader線程，可以判斷存在數(shù)據(jù)傾斜情況。但由于總字節(jié)數(shù)包括任務從上次指定位點啟動開始的數(shù)據(jù)量，如果任務運行時間已經很長，則可能無法反映出最近的數(shù)據(jù)傾斜情況，您需要繼續(xù)通過源端系統(tǒng)的監(jiān)控指標確認是否存在數(shù)據(jù)傾斜情況。
如果寫入源端系統(tǒng)的單個分區(qū)或者shard數(shù)據(jù)流量已經達到了同步速率的上限，例如，Kafka集群側可以對分區(qū)讀取流量配置限流、DataHub單分區(qū)的最大讀取流量有4MB/s限制、Loghub單shard最大讀取流量有10MB/s限制，如果實時同步任務對于單分區(qū)的讀取速度超過了限制，則可通過擴展源端系統(tǒng)分區(qū)或shard數(shù)量來解決延遲。
如果有多個實時同步任務消費同一個Kafka Topic、DataHub Topic或者Loghub logstore的情況，您需要注意所有實時同步任務的讀取速度之和是否超過限制。
確認MySQL源端是否有提交大事務或者變更過于頻繁（如大量的DML和DDL的操作）
對于源端是MySQL的實時同步任務，如果根據(jù)上述步驟未發(fā)現(xiàn)異常或Failover，則需要檢查源端系統(tǒng)是否提交了大事務或者源端系統(tǒng)變更過于頻繁（如大量的DML和DDL的操作），導致Binlog增長過快超過同步任務消費速度導致延遲。
例如，更新全表某個字段的值或者刪除大量數(shù)據(jù)等。您可以在任務運行詳情中切換到運行信息頁簽，查看任務同步速度：
當同步速度很大時，說明Binlog增長速度快。
當同步速度不大，您可以在MySQL服務端查看Binlog的統(tǒng)計指標和審計日志確認實際增長速率。
但同步速度可能無法反映當前同步任務消費MySQL源端Binlog的實際速度，因為當事務或者變更涉及的庫表沒有包含在同步任務的配置中，同步任務會將這部分數(shù)據(jù)在讀取過后過濾掉，也不計入對同步速度和數(shù)據(jù)量統(tǒng)計。
如果確認是大事務或者臨時的大量變更導致了任務延遲，則可以等待大事務或者大量變更包含的變更數(shù)據(jù)被同步任務處理完成后，任務延遲會逐步被追上。
確認是否有寫入動態(tài)分區(qū)頻繁切換問題（uploader map size has reached uploaderMapMaximumSize）
對于寫入MaxCompute的實時同步任務，當分區(qū)方式選擇根據(jù)字段內容動態(tài)分區(qū)時，要特別注意選擇對應于MaxCompute表分區(qū)列的源端列，在實時同步任務右側基本配置中配置的Flush間隔內（默認為1分鐘）包含的可枚舉值個數(shù)不能太大。
由于在Flush間隔內待寫入MaxCompute表的數(shù)據(jù)實際是在實時同步任務的一組隊列中保存，每個隊列會緩存一個MaxCompute的寫入數(shù)據(jù)，隊列的默認最大個數(shù)是5個，如果對應于MaxCompute表分區(qū)列的源端列在配置的Flush間隔內可枚舉值個數(shù)超過了緩存隊列的最大個數(shù)，會立即觸發(fā)對所有寫入數(shù)據(jù)的Flush操作，而頻繁的Flush操作將嚴重影響寫入性能。
您需要確認是否存在MaxCompute表分區(qū)緩存隊列個數(shù)耗盡觸發(fā)頻繁Flush操作問題。您可以在實時同步任務的運行詳情頁切換到日志頁簽，在日志中搜索是否有uploader map size has reached uploaderMapMaximumSize。
增加并發(fā)設置或開啟分布式運行模式解決延遲問題
如果根據(jù)上述步驟確認非讀寫異常引發(fā)的任務延遲，而是源端業(yè)務流量增長導致的延遲，則需要通過提高實時同步任務并發(fā)設置緩解延遲。
并發(fā)加大后也需要同步增加任務的內存設置，比例關系可以按照并發(fā)每增大4，內存增加1GB。
任務并發(fā)及內存設置方法如下：
對于DataStudio新建的單表到單表ETL實時同步任務，您可以單擊右側的基本配置設置任務并發(fā)和內存。
在DataStudio新建的數(shù)據(jù)庫遷至DataHub等類型實時同步任務，您可以在運行資源設置步驟中設置并發(fā)，在右側的基本配置設置任務內存。
同步解決方案任務，您可以在運行資源設置步驟中設置并發(fā)和內存。
在未開啟分布式運行模式情況下，任務并發(fā)建議不超過32，如果超過20則會由于單機資源瓶頸導致任務延遲，此時特定通道可以通過開啟分布式運行模式提升性能，目前支持開啟分布式運行模式的通道如下：
任務類型 | 源端 | 目標端 |
DataStudio ETL任務 | Kafka | MaxCompute |
DataStudio ETL任務 | Kafka | Hologres |