5.2 并发度（channel）与速率限制（speed）调优

5.2 并发度（channel）与速率限制（speed）调优

channel 与 speed 是 DataX 调优最常拧的两个旋钮。拧对了，同样的机器吞吐翻番；拧错了，要么浪费要么压垮。

channel 怎么定

channel 决定并发 Task 数。经验起点：取「目标端单连接写入能力」和「源端可承受连接数」的较小值，再参考机器核数。关系型源还要乘上 splitPk 分片能否支撑这么多发并发查询。我们不会一上来就开 32，而是从 4 起步翻倍试。

{
  "job": {
    "setting": {
      "speed": {
        "channel": 8,
        "byte": 5242880,
        "record": 20000
      }
    }
  }
}
​

byte 与 record 限速

byte 限制每秒传输字节，record 限制每秒记录数。两者同时设时取更紧的那个。限速的价值不在「快」，而在「可控」：在共享集群上，留出余量让别的任务也能跑，避免自己快了别人挂了。我们把限速看作对邻居的尊重。

内存的硬约束

每个 Channel 都占一块堆内缓冲。channel 乘单缓冲大小，不能超过 JVM 堆的合理比例。我们一般给 DataX 进程留 1G 以上堆，channel 开到 16 时缓冲占用就要精算，否则 GC 频繁反而拖慢。

我们的调优节奏

先用 4 个 channel 拿到基线吞吐，再 8、16 各跑一次，记录曲线拐点。超过拐点继续加 channel，吞吐不升反降，那就是资源到顶了。这个拐点就是这条任务在你环境里的「甜点」，记下来比记任何通用公式都管用。

限速是给邻居留余地

speed.byte / record 限速的价值不在「快」，而在「可控」。在共享集群上，留出余量让别的任务也能跑，避免自己快了别人挂了。我们把限速看作对邻居的尊重，也是对自己任务稳定性的投资。

我们一般把 byte 限速设为集群可用带宽的七成，channel 不超过核数一半。这样任务稳，也不容易因抢占资源被运维找上门。

延伸与提醒

插件目录名必须和 job.json 的 name 完全一致，大小写都不能错。
配置进版本库、密码进环境变量，是跨环境复用的基础。
自定义插件最容易踩的坑是依赖冲突，provided 范围能治本。
数据湖贴源层保留原始形态，方便后续 schema 演化。
splitPk 的列若分布不均，分片会倾斜，部分 Task 拖慢整体。
对象存储比 FTP 更适合做跨机房中转，因为它支持断点和内网加速。
全量基线加增量补充，是批流配合的常见稳妥组合。
把复杂 join 留在计算引擎，DataX 只做贴源搬运。
把转换逻辑下推到源库，通常比在 DataX 内部处理更高效。
日志里周期打印的读写速率，是定位瓶颈的第一手材料。
把 DataX 当搬运工而非加工车间，链路才简单可排查。
JVM 堆要给 Channel 缓冲留足空间，否则 GC 频繁拖慢吞吐。
rowkey 的散列前缀设计，能避免 HBase 写入热点。
orc 加 snappy 是 Hive 落地的常见稳妥组合，省空间且查询快。
Web 平台解决协作与可观测，不提升同步能力本身。
限速不是限制能力，而是给其他任务留出生存空间。
Hive 表的分区设计直接影响下游查询性能，写入时就该想清楚。
权限收得越紧，凭据泄露的爆炸半径越小。
星型拓扑把 N 乘 M 的对接降到 N 加 M，变更成本随之下降。
Redis 同步重跑要防重复 key，靠固定模板才能幂等。
退出码接进调度系统，才能让失败在半夜被及时发现。
脏数据阈值设得太高，会掩盖源端的数据质量问题，反而埋雷。
调优的本质是在 CPU、网络带宽和磁盘 IO 之间找平衡点，不是堆资源。
关系型 Writer 的批量提交大小，要在往返开销和回滚成本间权衡。
测试样本先小后大，几分钟校验能省下几小时排错。
writeMode 必须和数据更新语义对齐，不能凭感觉选。
channel 数超过源端连接承受能力时，瓶颈会从 DataX 转移到数据库。
机器核数、内存、带宽三者共同决定 channel 的甜点值。
preSql 里带 truncate 的任务，上线前必须二次确认目标表名。
生产环境的稳定性，常常取决于部署习惯而非某个高级特性。
反压机制保护内存，看到任务变慢应去优化下游而非加并发。
eswriter 的批量 bulk 写入，比逐条插入快一个数量级。

用循环做翻倍测试，找出 channel 的甜点。

for ch in 2 4 8 16; do
  sed -i "s/"channel": [0-9]*/"channel": $ch/" job/x.json
  time python bin/datax.py job/x.json
done
​

背景

channel 与 speed.byte 是 DataX 调速最重要的两个旋钮。理解它们的关系，才能把吞吐调到「源端能承受的上限」而不压垮它。

操作：不同 channel 的实测配置

{
  "job": {
    "content": [
      {
        "reader": { "name": "mysqlreader", "parameter": {
          "connection": [ { "jdbcUrl": ["jdbc:mysql://db:3306/order"], "table": ["t_order"], "splitPk": "id" } ],
          "column": ["id","amount"]
        } },
        "writer": { "name": "hdfswriter", "parameter": {
          "defaultFS": "hdfs://ns", "path": "/data/order", "fileType": "text",
          "column": [ {"name":"id","type":"bigint"}, {"name":"amount","type":"double"} ]
        } }
      }
    ],
    "setting": { "speed": { "channel": 16, "byte": 5242880 } }
  }
}
​

启动命令

# 用 time 包裹，对比不同 channel 下的总耗时，找到甜点
time python bin/datax.py job/order_tune.json
​

结果解读

speed.byte 是「每通道字节限速」，所以总带宽 ≈ channel × byte。当 channel 很小而 byte 很大时，受限于并发数；当 channel 很大而 byte 很小时，受限于单通道流速。实践中先固定 byte 上限保护源端，再逐步加大 channel 直到耗时不再明显下降——那一刻就是源端能力的天花板。

变式

源端是脆弱的生产库时，反过来：先把 channel 压低、byte 设小，优先保生产稳定，再利用业务低峰窗口提 channel 抢进度。

调速旋钮对照

💡 关键直觉：把 channel 想成「车道数」、byte 想成「每车道限速」，总通行能力 = 车道数 × 限速。优化就是在不引发事故（OOM / 源端过载）的前提下，把这个乘积推到道路（源端）容量上限。

⚠️ 常见坑：忽略「总带宽 = channel × byte」，只调 channel 却发现 byte 太低成了短板，速度纹丝不动；两个旋钮要一起看，找到真正卡脖子的那个。