本文可以協助您理解和配置任務通道控制參數，降低誤配的數量和答疑。本文將為您介紹離線同步並發和限流之間的關係。
實踐內容
並發數
閱讀此部分，您可以解決和理解如下問題：
問題一：如何配置資料同步任務的並發數？
問題二：為什麼我的資料同步任務跑的比較慢，實際啟動並執行並發數不夠？
問題三：為什麼我的同步任務並發數配置的很高，但是任務運行速度仍然很慢，為什麼我的獨享資源群組經常等待資源？
並發數是指資料同步任務中，可以從源端並行讀取和向目標儲存端並行寫出資料的最大線程數。為了提高資料同步的效率，可以適當調整任務的並發數，以縮短資料搬遷需要的時間。在產品中配置位置如圖所示：
檔案類型（OSS、FTP、HDFS、S3）資料讀取，主要基於檔案粒度並發讀取，待讀取的檔案數量少於任務配置並發數。上面任務期望最大並發數：即是任務配置的並發數，由於Data Integration資源群組或者任務本身特性等原因，任務實際執行的並發數可能小於等於任務配置並發數，如涉及任務並發數計費情境（Data Integration調試資源群組）會按照任務實際並發數計費。Data Integration會嘗試保障任務執行並發數符合配置並發數，常見的任務實際執行並發數小於配置並發數的情境有：
關聯式資料庫（如MySQL、PolarDB、SQLServer、PostgreSQL、Oracle等）讀取，沒有配置切分鍵splitPk（切分列支援整型數字類型，Oracle在整型之外額外支援時間類型）或切分鍵配置無效，導致任務無法將資料表資料拆分，進而無法並行讀取資料。
PolarDB-X（DRDS）是基於邏輯表的物理拓撲進行分區拆分讀取，物理分表數少於任務配置並發數。
檔案類型（OSS、FTP、HDFS、S3）資料讀取，主要基於檔案粒度並發讀取，待讀取的檔案數量少於任務配置並發數。
在源端資料分布極不均衡的情境，會導致部分資料分區執行耗時較久（其他分區已經完成傳輸），在任務執行後期階段任務實際並發數會少於配置並發數。
任務並發數配置最佳實務：
任務並發數越大，任務運行需要搶佔的資源越多，DataWorksData Integration任務的資源隊列是FIFO（先進先出），即前面提交任務先搶佔資源運行，後提交的任務後搶佔資源運行。建議您合理配置任務並發數，避免大並發任務長時間運行，進而阻塞後續任務獲得資源得到執行。
小資料量的資料表建議配置小並發，小並發需要的執行資源比較少，有利於任務快速搶佔片段資源得到運行。由於資料量比較小執行耗時可以控制在合理的範圍內。
同一個資料來源上同步任務，建議錯峰運行，一方面可以均衡資源群組的使用水位，另一方面也可以降低對資料來源訪問的並發壓力。
同步速率
閱讀此部分，您可以解決和理解如下問題：
問題一：如何配置資料同步速率，如何理解任務限速、或不限速？
問題二：為什麼有時候資料同步限速不生效？
問題三：為什麼資料同步任務運行速率有時候相較限速閾值有較大差距？
同步速率：資料同步速率和任務期望最大並發數是比較強相關的參數，兩者結合在一起可以保護資料來源和資料去向端的讀寫壓力，以避免資料同步任務對資料來源帶來較大壓力，影響資料來源的穩定性。
同步速率（不限流）是指按照使用者配置的任務期望最大並發數執行任務（假設實際運行並發為ActualConcurrent），每個並發分區執行則不做限速（假設分區實際執行速度為Speed），則任務實際執行的總體速度為ActualConcurrent * Speed。在不限流的情況下，Data Integration會提供現有任務配置（並發、記憶體）、硬體環境（資料來源規格、網路）下最大的傳輸效能。
同步速率（限流）是指按照使用者配置的作業整體速度限制以及任務最大並發數來運行任務。Data Integration在編排執行計畫時，每個並發分區的速率是（作業速率 / 作業並發數，計算的分區速度向上取整），分區限速下限是 1MB/s。因此，任務實際啟動並執行速率上限是任務實際並發數 * 每個分區的實際限速。
針對限流情境，舉幾個常見案例介紹如下：
使用者配置並發數為5，任務限速為5MB/s，則任務會嘗試切分為5個分區並發執行，每個分區執行限制速率為1MB/s。
如果任務實際並發為5，則作業的最終速度上限為5MB/s，小於等於任務速度上限。
任務實際執行並發受限於資料來源具體情況，實際並發可能小於配置5並發（請參見：任務期望最大並發數）。如果實際運行並發為1，則作業的最終速度上限為1MB/s，小於等於任務速度上限。
使用者配置並發數為5，任務限速為3MB/s，則任務會嘗試切分為5個分區並發執行，每個分區執行速率為3 / 5 向上取整為1MB/s。
如果任務實際執行並發為5，則作業的最終速度上限為 5MB/s，超出任務速度上限。
如果任務實際執行並發為1，則作業的最終速度上限為 1MB/s，小於等於任務速度上限。
使用者配置並發數為5，任務限速為10MB/s，則任務會嘗試切分為5個分區並發執行，每個分區執行速率為10 / 5，即2MB/s。
如果任務實際執行並發為5，則作業的最終速度上限為10MB/s，小於等於任務速度上限。
如果任務實際執行並發為1，則作業的最終速度上限為2MB/s，小於等於任務速度上限。
分散式處理能力
閱讀此部分，您可以解決和理解如下問題：
問題一：什麼情境下需要配置分布式模式運行同步作業？
問題二：為什麼使用分布式模式運行同步作業，任務速率還是跑的慢？
不開啟分布式時，配置的並發數僅僅是單機上的進程並發，無法利用多機聯合計算。分布式執行模式可以將您的任務切片分散到多台執行節點上並發執行，進而做到同步速度隨執行叢集規模做水平擴充，突破單機執行瓶頸。如果您對同步效能有比較高的訴求可以使用分布式模式，另外分布式模式也可以使用機器的片段資源，對資源使用率友好。
限制和最佳實務：
分布式執行模式下，配置較大任務並發度可能會對您的資料存放區產生較大的訪問壓力，請評估資料存放區的訪問負載。
如果您的獨享資源群組機器台數為1，不建議使用分布式執行模式，因為執行進程仍然分布在一台Worker節點上，無法最大化享受分布式多機的好處。
小資料量的同步任務，不建議配置分布式，建議配置單機小並發任務。
並發數大於等於8個才能開啟分布式。
髒資料限制
閱讀此部分，您可以解決和理解如下問題：
問題一：什麼是資料同步的髒資料？
問題二：如何配置資料同步任務髒資料限制？
問題三：資料同步速率和髒資料有哪些關聯關係？
髒資料限制能力用來控制任務在遇到髒資料時的行為，所謂髒資料是指資料條目在寫入目標資料來源過程中發生了異常，則此條資料被視為髒資料。由於各類異構系統對資料處理的複雜和差異性，目前策略是寫入失敗的資料均歸類於髒資料。在一些資料同步情境，髒資料的出現會導致任務同步效率下降，以關聯式資料庫寫出為例，預設是執行batch批量寫出模式，在遇到髒資料時會退化為單條寫出模式（以找出batch批次資料具體哪一條是髒資料，保障正常資料正常寫出），但單條寫出效率會遠低於batch寫出模式，故遇到大量髒資料時會拖慢任務啟動並執行最終效率。
目前Data Integration絕大多數通道支援髒資料閾值限制能力，對於支援髒資料閾值限制的通道，常見配置情境介紹如下：
不配置髒資料限制：表示容忍所有出現的髒資料，遇到髒資料不會導致任務失敗，任務配置errorLimit留空。
配置髒資料限制為0：表示不容忍任何髒資料，在出現超過1條髒資料時，任務會失敗退出。
配置髒資料限制為一個正整數N：表示最多容忍N條髒資料，在髒資料超過N條時，任務會失敗退出。
最佳實務：
關聯式資料庫（MySQL、SQL Server、PostgreSQL、Oracle、PolarDB、PolarDB-X等）、Hologres、ClickHouse、AnalyticDB for MySQL等對於資料要求比較敏感的情境，建議配置髒資料限制為0，以及時探索資料品質風險。
對於資料要求不敏感的情境，建議不配置髒資料限制，或者配置一個業務上合理的髒資料閾值上限，以降低您日常髒資料處理營運負擔。
關鍵任務配置任務失敗和延遲警示，以及時發現線上問題。
可重跑的任務建議配置任務失敗自動重跑，以降低偶發環境問題對任務的影響。
資料來源串連數Quota限制
閱讀此部分，您可以解決和理解如下問題：
問題一：什麼是資料來源串連數（Quota）限制，以及如何合理配置串連數限制？
問題二：為什麼資料同步解決方案中的離線全量任務跑的慢，長時間任務處於Submit狀態？
資料來源串連數限制功能，是指：
目標端寫入並發數：在即時資料同步任務內，向目標端寫入資料的最大線程數。需要根據資源群組大小和目標端實際規模合理設定。目前可配置的上限為32，預設值為3。
來源端讀取支援最大串連數：同步解決方案的離線全量資料初始化階段，會基於JDBC建立到資料庫連接並讀取全量歷史資料。此串連數用來控制資料來源端支援的最大JDBC串連數，避免大量任務同時啟動打滿資料庫連接池，影響資料庫的穩定性。請根據資料庫資源的實際情況合理配置，預設為15。如果您發現任務長時間處於Submit狀態，一般是因為資料來源最大串連數限制導致（可以嘗試任務錯峰運行、評估增加最大串連數限制）。
資料來源串連數Quota限制，功能入口（資料同步解決方案）如下圖所示：