DataX 限流与错误控制是什么
DataX 的并发与限流配置在 job 的 setting 段：speed.channel 控制并发通道数、byte 限制每秒传输字节数、record 限制每秒记录数；errorLimit 控制允许的错误记录条数与比例，超出即任务失败。这几个参数是保护源库与目标库的关键闸门——通道开太大直接体现为源库连接数与锁竞争升高，限速没设则可能把带宽占满。
基本信息
| 配置位置 | job.json 的 setting.speed 与 setting.errorLimit |
|---|---|
| channel | 并发通道数，直接决定对源库的连接与读压力 |
| byte | 每秒传输字节上限（-1 表示不限），按带宽预算设置 |
| record | 每秒记录数上限（-1 表示不限），按源库承受能力设置 |
| errorLimit | record 允许的错误行数（0 即零容忍）、percentage 允许的错误比例 |
| jvm | setting.jvm 可按任务调整堆内存，避免与其他任务互相挤占 |
典型使用场景
- 跨库全量抽取：白天跑任务时降低 channel 与 byte，避免影响在线业务
- 夜间批量搬运：可适度放开通道数换取更短窗口
- 初始化加载：大表按 splitPk 分片并行，同时限制总通道数
- 脏数据容忍：源端存在少量格式异常记录时设置 errorLimit 并收集脏数据
- 故障收敛：任务频繁 OOM 时调整堆内存与通道数，而不是一味加大内存
限流与错误上限配置
限流与错误上限配置
{
"job": {
"setting": {
"speed": { "channel": 2, "byte": 10485760, "record": -1 },
"errorLimit": { "record": 0, "percentage": 0.02 },
"jvm": "-Xms1g -Xmx2g"
},
"content": [
{ "reader": { "name": "mysqlreader",
"parameter": { "splitPk": "id", "username": "ro_user" } } },
{ "writer": { "name": "hdfswriter",
"parameter": { "path": "/warehouse/ods/orders" } } }
]
}
}限流生效的观察方式
限流生效的观察方式
# 任务日志中会打印每秒记录数与字节数，用来核对限速是否生效
python datax/bin/datax.py job_orders.json | grep -i 'records/s\|bytes/s\|speed'
# 同时观察源库连接数与当前长事务，确认通道数在承受范围内
# MySQL 侧：SHOW PROCESSLIST; 关注命令为 Query 且时间很长的连接参数职责对照
| 参数 | 作用 | 设置错误的影响 |
|---|---|---|
| channel | 并发通道数 | 过高把源库连接与锁竞争拉满 |
| byte | 每秒字节上限 | 不限时占满带宽，影响其他任务与在线业务 |
| record | 每秒记录上限 | 与 byte 二选一或同时使用，取值不当无法真正限速 |
| errorLimit.record | 允许的错误行数 | 设为 0 时一行脏数据即整体失败 |
| errorLimit.percentage | 允许的错误比例 | 比例过松会放过系统性错误 |
errorLimit 不是「自动跳过脏数据」：宽容错误要在业务上确认，并保证错误行被收集到脏数据文件后有留存与跟进机制，否则问题数据既没进目标表也没人知道。
开源 DataX 不支持断点续传：任务失败后需要整体重跑，这也是要把错题率与限速调稳的原因——失败一次就意味着重新拉一遍全量。