第三章：DataX数据源与目标（Reader/Writer）详解

第三章：DataX数据源与目标（Reader/Writer）详解

DataX 的能力边界由插件决定。本章按数据源类型梳理主流 Reader/Writer：关系型数据库、大数据生态、NoSQL、文件系统。我们不讲每个插件的全部参数，而是挑高频字段、讲清它们背后的读写机制，让你换一种数据源也能举一反三。

学习目标

能根据源端类型选对插件；说清关系型插件里 splitPk 为什么能提速；理解 HDFS Writer 的 fileType 与压缩选项对下游的影响；知道 MongoDB、Redis、ES 这类插件在批量与一致性上的取舍。

核心概念速览

插件围绕统一接口生长，新增一种数据源只需实现两端协议。

子章节导航

3.1 关系型数据库插件：连接、查询、分片的全套参数。
3.2 大数据生态插件：HDFS/Hive/HBase 等的写入形态。
3.3 NoSQL 插件：Mongo、Redis、ES 的批量策略。
3.4 文件系统插件：本地、FTP、FTP、OSS 的读写。

逻辑关系

本章给第四章的配置提供「字段清单」，给第五章的 Reader/Writer 端优化提供作用点。比如 3.1 的 splitPk 正是 5.3 并发读取的基础。插件机制本身又依赖第二章的 Plugin Loader。

前置与延伸

前置是第二禅的插件接口概念。延伸可挑一个你最常用的数据源，去读它插件目录下的 doc 文档，把本章的概括和它的一手参数表对照，收获最大。

关键术语对照

我们建议挑一个你最常用的数据源，去读它插件目录下的 doc，把本章的概括和它的一手参数表对照。插件能力边界以官方 doc 为准，本章只给导航。

本章补充要点

脏数据阈值设得太高，会掩盖源端的数据质量问题，反而埋雷。
splitPk 的列若分布不均，分片会倾斜，部分 Task 拖慢整体。
星型拓扑把 N 乘 M 的对接降到 N 加 M，变更成本随之下降。
数据湖贴源层保留原始形态，方便后续 schema 演化。
任务的读写速率差，比绝对速率更能说明瓶颈在哪一段。
eswriter 的批量 bulk 写入，比逐条插入快一个数量级。
自定义插件最容易踩的坑是依赖冲突，provided 范围能治本。
限速不是限制能力，而是给其他任务留出生存空间。
生产环境的稳定性，常常取决于部署习惯而非某个高级特性。
插件目录名必须和 job.json 的 name 完全一致，大小写都不能错。
监控指标和 DataX 日志交叉看，能锁定九成瓶颈。
Web 平台解决协作与可观测，不提升同步能力本身。
关系型 Writer 的批量提交大小，要在往返开销和回滚成本间权衡。
Redis 同步重跑要防重复 key，靠固定模板才能幂等。
机器核数、内存、带宽三者共同决定 channel 的甜点值。
把复杂 join 留在计算引擎，DataX 只做贴源搬运。
Hive 表的分区设计直接影响下游查询性能，写入时就该想清楚。
调优的本质是在 CPU、网络带宽和磁盘 IO 之间找平衡点，不是堆资源。
writeMode 必须和数据更新语义对齐，不能凭感觉选。
querySql 与 column 二选一，混用会直接报错。
权限收得越紧，凭据泄露的爆炸半径越小。
一张参数与吞吐的经验曲线，比任何通用公式都贴近你的环境。