1. 并发数
1.1 问题描述
由于 FineDataLink 中定时任务需要占用内存和并发资源等,因此用户可能需要根据实际的使用情况进行任务调整。
阅读此部分,你可以解决和理解如下问题:
问题一:如何配置定时任务的并发数?
问题二:为什么我的定时任务跑的比较慢,实际运行的并发数不够?
问题三:为什么我的定时任务并发数配置的很高,但是任务运行速度仍然很慢?
1.2 解释说明
并发数是指可以从源端并行读取和向目标存储端并行写出数据的最大线程数。
1.2.1 4.1.4 及之后版本
并发数详细说明参见:并发控制
为了提高定时任务的效率,可以适当调整任务的并发数,以缩短数据搬迁需要的时间。在产品中配置位置如图所示:
1.2.2 4.1.4 之前版本
FDL 能同时执行的任务数跟 cpu 的线程数有关,默认是 cpu 线程数的 1/2 。假如 cpu 线程数为 8,FDL 则可以同时执行 4 个定时任务,若定时任务数有 5 个,另外一个需要排队。
1.3 任务并发数配置最佳实践
任务并发数越大,任务运行需要抢占的资源越多,,即前面提交任务先抢占资源运行,后提交的任务后抢占资源运行。建议合理配置任务并发数,避免大并发任务长时间运行,进而阻塞后续任务获得资源得到执行。
小数据量的数据表建议配置小并发,小并发需要的执行资源比较少,有利于任务快速抢占碎片资源得到运行。由于数据量比较小执行耗时可以控制在合理的范围内。
同一个数据源上定时任务,建议错峰运行,可以降低对数据源访问的并发压力。
2. 脏数据阈值
脏数据容忍功能详情参见:脏数据容忍
2.1 问题描述
阅读此部分,可以解决和理解如下问题:
问题一:什么是定时任务的脏数据?
问题二:如何配置定时任务脏数据限制?
2.2 解释说明
脏数据阈值容忍能力用来控制任务在遇到脏数据时的行为,脏数据是指数据条目在写入目标数据源过程中发生了异常,则此条数据被视为脏数据。
以下为定时任务脏数据出现的情况:
1)与目标字段配置不匹配而无法写入的数据(目标字段长度/类型不匹配、目标字段缺失、违反目标字段非空约束等)。
2)当写入方式-主键冲突策略为「主键相同,记录为脏数据」时,主键冲突的数据将被视为脏数据。
由于各类异构系统对数据处理的复杂和差异性,目前写入失败的数据均被归类于脏数据。
目前定时任务在进行「任务控制」时,支持脏数据阈值限制能力,对于支持脏数据阈值限制的配置:
常见配置场景介绍如下:
不配置脏数据容忍:表示不容忍所有出现的脏数据,只要遇到脏数据就会导致任务失败。
配置脏数据限制为一个正整数N:表示最多容忍N条脏数据,在脏数据超过N条时,任务会失败退出。
2.3 最佳实践
关系数据库(MySQL、SQL Server、PostgreSQL、Oracle、ClickHouse 等对于数据要求比较敏感的场景,建议不配置脏数据容忍,以及时发现数据质量风险。
对于数据要求不敏感的场景,可以配置脏数据限制,或者配置一个业务上合理的脏数据阈值上限,以降低日常脏数据处理运维负担。
关键任务配置任务失败和延迟告警,以及时发现线上问题。
3. 任务重试
3.1 单个节点自动重试
对于运行失败或者有脏数据的任务,若用户需要从失败的节点自动触发任务再次执行,可配置任务失败自动重试,对定时任务中单个节点进行重试,以降低偶发环境问题对任务的影响。
但该重试无法回滚数据,即写入目标数据库中但只写了一半,则重跑不会处理已经写入的数据,因此用户需要特别注意。若需要处理该问题,可使用下文中的「重试」手动进行任务调整重试。
3.2 手动调整重试
若用户定时任务设置比较复杂,需要手动调整每次写入数据,则可在定时任务运维-运行记录中进行任务级别重试,如下图所示:
可以自定义重试任务范围和重试方式,如下图所示:
重试的场景可参考下表所示:
场景 | 增量同步的方式 | 重试后是否会存在数据问题 | 建议处理措施 |
---|---|---|---|
全量同步 | - | 否 | - |
增量同步-使用时间戳 | 动态参数:如:配置 now-1 作为数据范围,每次更新前一天数据 | 是 | 在重试时,用户可以指定本次运行的临时任务参数值 且用户的任务设计需要支持幂等,即同一数据范围的定时任务需要支持多次运行 |
获取目标表的最新数据时间戳 如:每次任务先从目标表获取最大的时间戳,作为本次同步的起始时间 同步方式示例详情参见:增量更新-有时间戳 | 是 | 用户需要手动删除目标表大于本批次的数据,以进行重试 且用户的任务设计需要支持幂等,即同一数据范围的定时任务需要支持多次运行 | |
自定义配置表存储断点 如:每次任务最后一步存储本次同步的最大时间至一张表存储 | 是 | 用户需要手工修改断点值,以进行重试 且用户的任务设计需要支持幂等、即同一数据范围的定时任务需要支持多次运行 | |
全表比对 | - | 否 | - |