第二章：DataX核心架构与运行机制

第二章：DataX核心架构与运行机制

本章拆开 DataX 的黑盒。我们沿着一条记录的生命周期走：Job 被切分成 TaskGroup 和 Task，Reader 把源端数据转成内部 Record 推入 Channel，Writer 从 Channel 拉取并写出。理解这套分层调度，是后面所有调优的前提。

学习目标

能画出 Job 到 TaskGroup 到 Task 的切分关系；说清 Reader、Channel、Writer 各自的职责边界；解释 Plugin Loader 怎么在运行时加载一个 jar；描述一个任务从初始化、运行到结束经历的的阶段，以及反压是怎么保护内存的。

核心概念速览

下面这张图给出运行时的骨架：作业居中，向下切分，向内走数据管道。

子章节导航

2.1 整体架构设计：Job、TaskGroup、Task 三层的来历。
2.2 数据传输模型：Record 在 Channel 里怎么流动。
2.3 插件体系与扩展机制：Plugin Loader 的加载链路。
2.4 任务生命周期管理：初始化、运行、结束各做什么。

逻辑关系

本章是后面所有章节的枢纽。第三章的每个插件都实现这里的 Reader 或 Writer 接口；第四章的 speed 参数直接作用在本章的 TaskGroup 与 Channel 上；第五章的瓶颈分析也建立在本章的并发模型之上。

前置与延伸

前置是第一章的概念。读完本章务必动手跑一次任务并用 jstack 看线程，把抽象模型对应到真实线程。延伸可看 DataX 源码里 com.alibaba.datax.core 包，把文字描述和代码对上号。

关键术语对照

我们建议结合代码里的 com.alibaba.datax.core 包对照阅读。文字描述再清楚，也不如看一眼真实的线程启动过程来得扎实。读完本章，应能画出 Job 到 Task 的切分图。

本章补充要点

退出码接进调度系统，才能让失败在半夜被及时发现。
机器核数、内存、带宽三者共同决定 channel 的甜点值。
调优的本质是在 CPU、网络带宽和磁盘 IO 之间找平衡点，不是堆资源。
rowkey 的散列前缀设计，能避免 HBase 写入热点。
orc 加 snappy 是 Hive 落地的常见稳妥组合，省空间且查询快。
writeMode 必须和数据更新语义对齐，不能凭感觉选。
脏数据阈值设得太高，会掩盖源端的数据质量问题，反而埋雷。
把转换逻辑下推到源库，通常比在 DataX 内部处理更高效。
对象存储比 FTP 更适合做跨机房中转，因为它支持断点和内网加速。
Channel 是有界缓冲，填满即触发反压保护内存。
权限收得越紧，凭据泄露的爆炸半径越小。
测试样本先小后大，几分钟校验能省下几小时排错。
数据湖贴源层保留原始形态，方便后续 schema 演化。
DataX 的设计哲学是把连接差异收敛到插件，让核心只管调度与缓冲。
生产环境的稳定性，常常取决于部署习惯而非某个高级特性。
splitPk 的列若分布不均，分片会倾斜，部分 Task 拖慢整体。
配置进版本库、密码进环境变量，是跨环境复用的基础。
channel 数超过源端连接承受能力时，瓶颈会从 DataX 转移到数据库。
querySql 与 column 二选一，混用会直接报错。
反压机制保护内存，看到任务变慢应去优化下游而非加并发。
关系型 Writer 的批量提交大小，要在往返开销和回滚成本间权衡。
JVM 堆要给 Channel 缓冲留足空间，否则 GC 频繁拖慢吞吐。