异构数据源同步之数据同步 → datax 再改造，开始触及源码

前情回顾

异构数据源同步之数据同步 → datax 改造，有点意思

主要讲到了2点

• 去 Python，直接在命令行用 java 命令来启动
• 通过 java 代码拉起 DataX 进程来启动

虽说很简单，但也涉及一些细节，推荐你们去看看

说是改造 DataX ，其实算不上，顶多算是在新手村蹦跶，对 DataX 来说无关痛痒

班门弄斧

我们总不能一直待在新手村吧，觉醒姐 都说了

女性现在是已经清醒觉醒，独立的在走向成长的道路上 希望广大男同胞，能够自信起来，睁眼看世界 然后要好好的努力，不要破防了之后就骂骂咧咧、哭哭啼啼的

我就断章取义下，就是说猿友们要好好努力，走出新手村，去改造 DataX 源码！

基础准备

既然是改源码，那么我们肯定得先获取源码，对不对？

不然我们改个毛呀

如何获取源码，我再教你们一遍

1. 找到 DataX 官网 https://github.com/alibaba/DataX
2. 源码下载

源码下载

下载方式有很多，概括为 2 种

1. git clone
2. 源码压缩包

推荐用 git clone ，存在版本管理，修改错了能够回滚，对我们改造源码好处多多

此时不要慌，我们可以从 Gitee 下载

https://gitee.com/mirrors/DataX

下载方式与上面讲的一致，不再赘述

下载下来后，你们会发现 plugin 模块太多

datax plugin

这么长，就问你们怕不怕？

我反正挺害怕的，根本不想改，要不算了，散了吧

散了吧

等等，先别散，还有得救，不就是 plugin 太多吗

那就都删了，只留一对不就好了

这里不推荐真的直接去删，因为要删的太多了

我们可以将必要的复制出来，进行简化，就像这样

简化后结构

因为模块名调整了，所以每个模块的 pom.xml 需要微调下，而不能完全复制

至于 pom.xml 怎么个微调法，我相信你们都懂得

assembly 也需要微调，你们别漏了

其他的，例如 src、doc ，完全复制即可

qsl-datax-debug 就是 DataX 中的模块 datax-example

qsl-datax-debug

只是我做了一个合并处理，作用是一样的

qsl-datax 源码地址

https://gitee.com/youzhibing/qsl-datax

执行 com.qsl.executor.DebugTest#mysql2Mysql ，结果如下

初次同步

出现上图，说明我们的简化抽取是没有问题的

至此，基础准备算是完成了，是不是很简单？

不是试试

后续的操作都是基于 qsl-datax ，请尽情的开始你们的改造吧

修复组件安全漏洞

不知道你们公司是怎么看待组件安全漏洞的，反正我司是非常重视的

就我个人而言，我是比较反感组件安全漏洞修复的

因为升级组件版本是有前提的，不是说升到安全版本就升到安全版本的

必须保证业务功能不受影响，如何保证了？

这可不是小孩子过家家，来不了一点虚的，必须将组件涉及到的业务功能都测一遍，就问你慌不慌？

有时候某个小组件的升级, 不亚于一次系统的改造

反正我是经历过血的教训的

都说了能不动就别动，非要去调整，出生产事故了吧

不到万不得已，千万不要去手贱

手贱

有点扯远了，我们继续看组件安全漏洞修复

虽说我对安全漏洞可以忍，但是代码 标黄警告 我是真的不能忍

安全

反手就是一个 Ignore，眼不见心不烦！

还有谁

但是非常不推荐这样做，指标不治本，躲得过初一躲不过十五，还是推荐升级到安全版本

尤其是项目初期，反正要进行全业务功能测试的，所以随便升

根据提示，升级到安全版本还是非常容易的，但是组件升级了还不算完

爽完了你得给钱，不然交易不算完成，是有隐患的！

不好意思，说漏嘴了，组件升级了一定要进行业务流程验证

程序还能不能跑起来，业务流程是否正常，等等

我就不一一演示每个组件的升级了，我全量改了之后提交，你们直接去看源码

最后要给你们打个预防针

当下安全的版本在未来不一定安全，所以组件安全漏洞修复是一项长期的工作！！！

好难

core.json 配置化

面对此命题，你们是不是有疑问

core.json 在 conf 目录下已经存在了

core_json

难道这不算配置化？

这肯定算配置化，但是我觉得不够灵活

假设针对不同的 job，我们需要配置不同的 core.json，你们想如何应对

你们肯定会说

每启动一个 job，就修改一次 core.json，so easy

可行是可行，但你们不觉得有很大的局限吗

面对一个两个 job，可以这样手动去改

但如果是十个八个，甚至上百个 job 了，你们又该如何应对

所以，我说的配置化是指

core.json 作为 Datax 的启动参数之一 如果没有指定，则用默认的 conf 目录下的 core.json 如果参数指定，则用指定的 core.json

需求是不是清楚了

但是问题又来了，该怎么改了？

但凡看过我上篇文章

异构数据源同步之数据同步 → datax 改造，有点意思

你们都应该知道从哪里切入

找 DataX 的启动类嘛

corejson修改切入点

然后再找到它的 main 方法

main

是不是没得选了，只能进 entry 方法了

entry

很幸运，我们已经找到我们想要的了；分两点说明下

1. 获取 DataX 参数 java -server -Xms1g -Xmx1g -XX:+HeapDumpOnOutOfMemoryError -Ddatax.home=/datax -classpath /datax/lib/* com.alibaba.datax.core.Engine -mode standalone -jobid -1 -job job.json 哪些是 jvm 参数，哪些是 DataX 参数，你们能区分出来吗
2. 解析 job 配置 core.json 的解析包含在 job.json 解析中

很明显这两处我们都得改

1. 新增 core 参数

core_参数支持

照葫芦画瓢嘛，应该没问题吧

1. core.json 解析调整

core 解析

ConfigParser.parseJobConfig(jobPath) 跟进去后有个细节

job解析_从core读取参数

这里仅仅只是用到了 core.json 中的一个配置值

所以我们可以将这个参数值作为 getJobContent 方法的参数

serverTimeout

上游调用的地方也要记得改

job parse

core.json 配置化就改完了，此处是不是应该有点什么？

640 (4)

集成 DataX

如果只是偶尔的数据同步，那么手动操作 DataX 就够了，又不是不能用

又不是不能用

但是如果是定时同步，并且有非常多的同步，你们还手动操作吗

所有要加个模块

https://gitee.com/youzhibing/qsl-datax/tree/master/qsl-datax-hook

由这个模块去拉起 DataX 进程的同时去对接调度平台

调度平台有很多，例如 XXL-JOB 、DolphinScheduler Elastic-Job 等等

qsl-datax-hook 目前只实现了 DataX 进程的拉起

datax集成

至于调度平台的对接，需要你们去对接（楼主又不知道你们用的哪个调度平台！）

接下来做什么？

是不是调试 qsl-datax-hook 与 DataX 的对接

1. 打包我们改造的 DataX

打包改造的datax

不出意外的话，在 qsl-datax/target/datax/datax/ 目录下出现了我们熟悉的目录结构

改造datax后的目录结构

所以请大声的告诉我，DataX 的 home 目录 是什么？

G:\qsl-datax\target\datax\datax

1. 执行 com.qsl.hook.DataXManagerTest#exec 这个代码就比较简单了，相信你们都能看懂

exec

顺利的话，同步成功日志如下

exec_log

至此，集成算是基本完成

但是我还要补充一点，就是日志问题

DataX 有自己的日志

datax日志目录

而 qsl-datax-hook 的日志正好包含了 DataX 的日志，所以呢？

是不是重复了，是不是可以取消一个？

因为后续主要是跟 qsl-datax-hook 打交道，所以推荐做法是

保留 DataX 的日志控制台输出，但不写入文件 qsl-datax-hook 既要控制台输出，还要写入文件

yes-我全都要

1. DataX 日志调整

datax 日志调整

1. qsl-data-hook 日志调整

qsl-datax-hook日志调整

具体怎么保留日志，是否需要都保留，你们根据自己项目的实际情况进行调整

切勿生搬硬套！！！

总结

1. 组件安全漏洞修复，虽说不情愿，但还是要修滴
2. 关于对 DataX 的改造，除非必要，不推荐大家去改 如果对 DataX 掌握的不够，很容易改出问题 能不动就不要动，改好没绩效，改出问题要背锅，吃力不讨好，又不是不能跑
3. DataX + datax-web 基本满足大部分需求，直接拿来用，不推荐重复造轮子