第五章：性能优化与故障排查

第五章：性能优化与故障排查

任务跑起来只是开始，跑得快、跑得稳才是生产要求。本章给出瓶颈定位的方法论，再分别压 Reader 端、Writer 端、并发与速率这几根旋钮，最后给出一套报错排查的肌肉记忆。

学习目标

能判断一条慢任务卡在源端、通道还是目标端；会根据数据量与机器核数估算合理 channel；能给 Reader 加 splitPk、给 Writer 提批量；面对连接失败、类型不匹配、OOM 三类高频故障能按顺序定位。

核心概念速览

调优本质是平衡三股资源：CPU、网络带宽、磁盘 IO。

子章节导航

5.1 性能瓶颈定位与分析方法：先看哪个指标。
5.2 并发度与速率限制调优：channel 与 byte 怎么配。
5.3 Reader 端优化：SQL、索引、批量读取。
5.4 Writer 端优化：批量写入、事务、预分区。

逻辑关系

本章所有旋钮都接在第二章的并发模型和第四章的配置字段上。读本章前请确认你已知道 channel 落在哪里、splitPk 属于哪个插件参数，否则会看得云里雾里。

前置与延伸

前置是第二、四章。延伸建议建一张小表，记录不同 channel 下的吞吐，形成你自己环境的经验曲线，比任何通用建议都准。脏数据治理已并入排错实践讲解。

关键术语对照

我们建议建一张小表记录不同 channel 下的吞吐，形成你自己环境的经验曲线。这条曲线比任何通用建议都准，也是本章方法能落地的关键。

本章补充要点

channel 数超过源端连接承受能力时，瓶颈会从 DataX 转移到数据库。
writeMode 必须和数据更新语义对齐，不能凭感觉选。
反压机制保护内存，看到任务变慢应去优化下游而非加并发。
Redis 同步重跑要防重复 key，靠固定模板才能幂等。
测试样本先小后大，几分钟校验能省下几小时排错。
对象存储比 FTP 更适合做跨机房中转，因为它支持断点和内网加速。
Web 平台解决协作与可观测，不提升同步能力本身。
配置进版本库、密码进环境变量，是跨环境复用的基础。
多租户隔离交给编排层，DataX 保持简单最稳妥。
一张参数与吞吐的经验曲线，比任何通用公式都贴近你的环境。
preSql 里带 truncate 的任务，上线前必须二次确认目标表名。
querySql 与 column 二选一，混用会直接报错。
关系型 Writer 的批量提交大小，要在往返开销和回滚成本间权衡。
任务的读写速率差，比绝对速率更能说明瓶颈在哪一段。
JVM 堆要给 Channel 缓冲留足空间，否则 GC 频繁拖慢吞吐。
DataX 的设计哲学是把连接差异收敛到插件，让核心只管调度与缓冲。
数据湖贴源层保留原始形态，方便后续 schema 演化。
调优的本质是在 CPU、网络带宽和磁盘 IO 之间找平衡点，不是堆资源。
把 DataX 当搬运工而非加工车间，链路才简单可排查。
生产环境的稳定性，常常取决于部署习惯而非某个高级特性。
源库索引评审应作为同步查询上线的前置环节。
Channel 是有界缓冲，填满即触发反压保护内存。
插件目录名必须和 job.json 的 name 完全一致，大小写都不能错。
全量基线加增量补充，是批流配合的常见稳妥组合。
日志里周期打印的读写速率，是定位瓶颈的第一手材料。
rowkey 的散列前缀设计，能避免 HBase 写入热点。
Reader 和 Writer 互不知晓，正是插件能独立扩展的原因。
eswriter 的批量 bulk 写入，比逐条插入快一个数量级。