DataWorks实时任务延迟

（一）实时任务为什么会同步慢或延迟

● 网络。

走公网相对于内网速度较慢；跨域，跨国网络更建议走内网。

数据库、引擎服务端、数据集成独享资源组网络的带宽（吞吐量TPS）。

● 服务端本身的读写性能。CPU、内存、SSD 硬盘、硬盘、网络带宽。

● 任务配置的读写端的并发数，部分还受限于源服务的特性，比如DataHub并发受限于shard数等。

● 同步起始位点较早，需要一段时间来追平，只要界面延迟时间是在逐渐减小，就是在追平的状态。

（二）实时任务提速或降低延迟的常见案例

通用场景

【案例一】

现象：跨域、跨账号数据同步实时同步任务读不到数据，离线任务可以正常读到或者实时同步读取非常慢，延迟高；

原因：可能被cen带宽吞了，或者带宽太小。

读取MySQL相关场景

【说明】

MySQL输入基于Binlog实时订阅的方式实时读取配置的MySQL数据库表数据。

延迟时间的计算方式：当前系统时间-从binlog里拉取的最后一条记录的时间=显示延迟时间。

【案例一】

现象：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。