本文可以帮助您理解和配置任务通道控制参数，降低误配的数量和答疑。本文将为您介绍离线同步并发和限流之间的关系。
实践内容
并发数
阅读此部分，您可以解决和理解如下问题：
问题一：如何配置数据同步任务的并发数？
问题二：为什么我的数据同步任务跑的比较慢，实际运行的并发数不够？
问题三：为什么我的同步任务并发数配置的很高，但是任务运行速度仍然很慢，为什么我的独享资源组经常等待资源？
并发数是指数据同步任务中，可以从源端并行读取和向目标存储端并行写出数据的最大线程数。为了提高数据同步的效率，可以适当调整任务的并发数，以缩短数据搬迁需要的时间。在产品中配置位置如图所示：
文件类型（OSS、FTP、HDFS、S3）数据读取，主要基于文件粒度并发读取，待读取的文件数量少于任务配置并发数。上面任务期望最大并发数：即是任务配置的并发数，由于数据集成资源组或者任务本身特性等原因，任务实际执行的并发数可能小于等于任务配置并发数，如涉及任务并发数计费场景（数据集成调试资源组）会按照任务实际并发数计费。数据集成会尝试保障任务执行并发数符合配置并发数，常见的任务实际执行并发数小于配置并发数的场景有：
关系数据库（如MySQL、Polardb、SQLServer、PostgreSQL、Oracle等等）读取，没有配置切分键splitPk（切分列支持整型数字类型，Oracle在整型之外额外支持时间类型）或切分键配置无效，导致任务无法将数据表数据拆分，进而无法并行数据读取。
PolarDB-X（DRDS）是基于逻辑表的物理拓扑进行分片拆分读取，物理分表数少于任务配置并发数。
文件类型（OSS、FTP、HDFS、S3）数据读取，主要基于文件粒度并发读取，待读取的文件数量少于任务配置并发数。
在源端数据分布极不均衡的场景，会导致部分数据分片执行耗时较久（其他分片已经完成传输），在任务执行后期阶段任务实际并发数会少于配置并发数。
任务并发数配置最佳实践：
任务并发数越大，任务运行需要抢占的资源越多，DataWorks数据集成任务的资源队列是FIFO（先进先出），即前面提交任务先抢占资源运行，后提交的任务后抢占资源运行。建议您合理配置任务并发数，避免大并发任务长时间运行，进而阻塞后续任务获得资源得到执行。
小数据量的数据表建议配置小并发，小并发需要的执行资源比较少，有利于任务快速抢占碎片资源得到运行。由于数据量比较小执行耗时可以控制在合理的范围内。
同一个数据源上同步任务，建议错峰运行，一方面可以均衡资源组的使用水位，另外也可以降低对数据源访问的并发压力。
同步速率
阅读此部分，您可以解决和理解如下问题：
问题一：如何配置数据同步速率，如何理解任务限速、或不限速？
问题二：为什么有时候数据同步限速不生效？
问题三：为什么数据同步任务运行速率有时候相较限速阈值有较大差距？
同步速率：数据同步速率和任务期望最大并发数是比较强相关的参数，两者结合在一起可以保护数据来源和数据去向端的读写压力，以避免数据同步任务对数据源带来较大压力，影响数据源的稳定性。
同步速率（不限流）是指按照用户配置的任务期望最大并发数执行任务（假设实际运行并发为ActualConcurrent），每个并发分片执行则不做限速（假设分片实际执行速度为Speed），则任务实际执行的总体速度为ActualConcurrent * Speed。在不限流的情况下，数据集成会提供现有任务配置（并发、内存）、硬件环境（数据源规格、网络、）下最大的传输性能。
同步速率（限流）是指按照用户配置的作业整体速度限制、以及任务最大并发数来运行任务。数据集成在编排执行计划时，每个并发分片的速率是（作业速率 / 作业并发数，计算的分片速度向上取整），分片限速下限是 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写出模式，故遇到大量脏数据时会拖慢任务运行的最终效率。
目前数据集成绝大多数通道支持脏数据阈值限制能力，对于支持脏数据阈值限制的通道，常见配置场景介绍如下：
不配置脏数据限制：表示容忍所有出现的脏数据，遇到脏数据不会导致任务失败，任务配置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限制，功能入口（数据同步解决方案）如下图所示：