（一）资源优先级
补充说明：资源分为调度资源、计算资源、数据集成同步资源。
- 一个数据集成任务需要一级调度资源组下发任务到二级数据集成资源组来同步数据；
- 像odps sql等其他计算引擎任务需要一级调度资源下发任务到二级计算资源来处理任务；
- 通用节点一般仅需要一级调度资源完成。
（二）数据集成
离线同步
离线任务同步速度有哪些影响因素？
- 网络
- 走公网相对于内网速度较慢；跨域，跨国网络更建议走内网。
- 数据库、引擎服务端、cen带宽、数据集成独享资源组网络的带宽（吞吐量TPS）。
- 服务端本身的读写性能：大部分读写插件会转换成SQL在数据库、引擎服务端侧执行，一部分是接入的数据库、引擎提供的接口，所以同步的快慢受限于服务端本身的读写性能。
- CPU、内存、SSD 硬盘、硬盘、网络带宽
- 写端插件中前置语句或后置语句耗时久导致整体任务慢，同步传输速度本身不慢（仅部分插件支持前或后置语句）。
- 读端全表扫描。
- 任务配置的并发数：实际并发低。包括假如配置了8并发，由于参数或服务端本身限制原因实际生效3并发的场景。
- 任务配置的限流。
离线任务如何调优？
调优通用逻辑
- 走内网相对走公网速度、安全性、稳定性更优，跨国网络建议走专线打通内网。
- 离线任务通常情况下并发（"concurrent"参数）数越高，同步速度越快，部分插件需要配置切分键（例如"splitPk参数"）才生效，否则使用单通道进行同步，具体可参见插件文档。注意资源可用并发数；单机任务并发上限15。
"setting": {
"speed": {
"concurrent": 10
}
}
- 写端数据库负载不高的情况下，可以关闭限流，不限流的情况下则会提供现有硬件环境下最大的传输性能。
"setting": {
"speed": {
"throttle": true // 是否限流。
"mbps": 1, // 具体速率值。
}
}
- 大并发任务（>=8个并发）且独享数据集成资源组有2台及以上，可以开启分布式"executeMode":"distribute"
分布式模式的计算逻辑：
子进程数 = 并发数 / 6
消耗的总资源内存 = 子进程数 * 手动分配的内存
比如以最大的kafka_2_odps任务为例：120个并发分布式模式下 -> 总共切分了20个子进程 -> 每个子进程分配了8GB内存 -> 总消耗资源为 20 * 8 = 160
- 将写端插件中前后置语句移出同步任务外执行。
- 读端插件过滤条件中尽量使用索引字段避免全表扫描，避免或减少函数等复杂处理。
常用的插件调优
插件 |
调优/提速 |
典型场景 |
|
\ |
|
Datahub Reader |
\ |
|
\ |
|
|
|
\ |
|
|
\ |
实时同步
实时任务为什么会同步慢或延迟？
- 网络
- 走公网相对于内网速度较慢；跨域，跨国网络更建议走内网。
- 数据库、引擎服务端、数据集成独享资源组网络的带宽（吞吐量TPS）
- 服务端本身的读写性能
- CPU、内存、SSD 硬盘、硬盘、网络带宽。
- 任务配置的读写端的并发数，部分还受限于源服务的特性，比如DataHub并发受限于shard数等。
- 同步起始位点较早，需要一段时间来追平，只要界面延迟时间是在逐渐减小，就是在追平的状态。
实时任务调优或降低延迟的常见案例？
通用场景
【案例一】
现象：跨域、跨账号数据同步实时同步任务读不到数据，离线任务可以正常读到或者实时同步读取非常慢，延迟高；
原因：可能被cen带宽吞了，或者带宽太小。
读取MySQL相关场景
【说明】
- MySQL输入基于Binlog实时订阅的方式实时读取配置的MySQL数据库表数据。
- 延迟时间的计算方式：
【案例一】
现象：MySQL实时同步到ADB for MySQL延迟高调整并发不生效
原因：整库实时同步到ADB，因为支持DDL同步，所以目前并发数被系统控制到了和目标端表数目一致。同步1张表，并发数只能为1。页面的并发配置调整也无效。
如果使用ETL单表实时同步，不支持DDL同步（DDL消息会被忽略），如果存在主键列的话，用户配置的并发可以生效。
读取Kafka相关场景
【说明】
- 读kafka的并发上限值受限于kafka的分区数
【案例一】
现象：实时kafka-odps显示当前同步位点1970年，52的业务延迟，当前起始位点为2022-03-21。
原因：这类问题一般都是源端数据设置的时间戳不对或者没有设置时间戳，需检查源端数据。
写入MaxCompute相关场景
【说明】
- 如果源端数据比较稀疏，可以调大内存，调大Flush间隔，开启并行Flush，增大缓存队列，降低和MaxCompute的交互频率，可以减少小文件的数量，提升性能。
【案例一】
现象：数据写入MaxCompute等待时间远大于kafka数据读取等待时间。查看日志中，如图，读线程有48个，写线程只有3个，数据写入等待时间久。
原因：写的线程数少于读的线程数
解决：加并发，保持和读端一致，加到48。
（三）调度
参考上文“资源优先级”
（四）计算引擎
- MaxCompute计算优化：https://help.aliyun.com/document_detail/100461.html
