其实追女生，没那么复杂
只要你花心思，花时间，陪她聊天，带她吃好吃的，耍好玩的，买好看的
慢慢你就会发现什么叫做 打水漂
不说了，我要去陪她看电影了
主要讲到了2点
- 去
Python，直接在命令行用java命令来启动- 通过
java代码拉起DataX进程来启动
虽说很简单，但也涉及一些细节，推荐你们去看看
说是改造 DataX ，其实算不上，顶多算是在新手村蹦跶，对 DataX 来说无关痛痒
我们总不能一直待在新手村吧，觉醒姐 都说了
女性现在是已经清醒觉醒，独立的在走向成长的道路上
希望广大男同胞，能够自信起来，睁眼看世界
然后要好好的努力，不要破防了之后就骂骂咧咧、哭哭啼啼的
我就断章取义下，就是说猿友们要好好努力，走出新手村，去改造 DataX 源码！
既然是改源码，那么我们肯定得先获取源码，对不对？
不然我们改个毛呀
如何获取源码，我再教你们一遍
找到 DataX 官网
源码下载
下载方式有很多，概括为 2 种
- git clone
- 源码压缩包
推荐用 git clone ，存在版本管理，修改错了能够回滚，对我们改造源码好处多多
但是，没梯子的化，有堵墙会阻碍我们下载源码
此时不要慌，我们可以从 Gitee 下载
下载方式与上面讲的一致，不再赘述
下载下来后，你们会发现 plugin 模块太多
这么长，就问你们怕不怕？
我反正挺害怕的，根本不想改，要不算了，散了吧
等等，先别散，还有得救，不就是 plugin 太多吗
那就都删了，只留一对不就好了
这里不推荐真的直接去删，因为要删的太多了
我们可以将必要的复制出来，进行简化，就像这样
因为模块名调整了，所以每个模块的 pom.xml 需要微调下，而不能完全复制
至于 pom.xml 怎么个微调法，我相信你们都懂得
assembly 也需要微调，你们别漏了
其他的，例如 src、doc ，完全复制即可
qsl-datax-debug 就是 DataX 中的模块 datax-example
只是我做了一个合并处理，作用是一样的
qsl-datax 源码地址
执行 com.qsl.executor.DebugTest#mysql2Mysql ，结果如下
出现上图，说明我们的简化抽取是没有问题的
至此，基础准备算是完成了，是不是很简单？
后续的操作都是基于 qsl-datax ，请尽情的开始你们的改造吧
不知道你们公司是怎么看待组件安全漏洞的，反正我司是非常重视的
就我个人而言，我是比较反感组件安全漏洞修复的
因为升级组件版本是有前提的，不是说升到安全版本就升到安全版本的
必须保证业务功能不受影响，如何保证了？
这可不是小孩子过家家，来不了一点虚的，必须将组件涉及到的业务功能都测一遍，就问你慌不慌？
有时候某个小组件的升级, 不亚于一次系统的改造
反正我是经历过血的教训的
不到万不得已，千万不要去手贱
有点扯远了，我们继续看组件安全漏洞修复
虽说我对安全漏洞可以忍，但是代码 标黄警告 我是真的不能忍
反手就是一个 Ignore，眼不见心不烦！
但是非常不推荐这样做，指标不治本，躲得过初一躲不过十五，还是推荐升级到安全版本
尤其是项目初期，反正要进行全业务功能测试的，所以随便升
根据提示，升级到安全版本还是非常容易的，但是组件升级了还不算完
爽完了你得给钱，不然交易不算完成，是有隐患的！
不好意思，说漏嘴了，组件升级了一定要进行业务流程验证
程序还能不能跑起来，业务流程是否正常，等等
我就不一一演示每个组件的升级了，我全量改了之后提交，你们直接去看源码
最后要给你们打个预防针
当下安全的版本在未来不一定安全，所以组件安全漏洞修复是一项长期的工作！！！
面对此命题，你们是不是有疑问
core.json 在 conf 目录下已经存在了
难道这不算配置化？
这肯定算配置化，但是我觉得不够灵活
假设针对不同的 job，我们需要配置不同的 core.json，你们想如何应对
你们肯定会说
每启动一个 job，就修改一次 core.json，so easy
可行是可行，但你们不觉得有很大的局限吗
面对一个两个 job，可以这样手动去改
但如果是十个八个，甚至上百个 job 了，你们又该如何应对
所以，我说的配置化是指
core.json 作为 Datax 的启动参数之一
如果没有指定，则用默认的 conf 目录下的 core.json
如果参数指定，则用指定的 core.json
需求是不是清楚了
但是问题又来了，该怎么改了？
但凡看过我上篇文章
你们都应该知道从哪里切入
找 DataX 的启动类嘛
然后再找到它的 main 方法
是不是没得选了，只能进 entry 方法了
很幸运，我们已经找到我们想要的了；分两点说明下
获取 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 参数，你们能区分出来吗
解析 job 配置
core.json 的解析包含在 job.json 解析中
很明显这两处我们都得改
新增 core 参数
照葫芦画瓢嘛，应该没问题吧
core.json 解析调整
ConfigParser.parseJobConfig(jobPath) 跟进去后有个细节
这里仅仅只是用到了 core.json 中的一个配置值
所以我们可以将这个参数值作为 getJobContent 方法的参数
上游调用的地方也要记得改
core.json 配置化就改完了，此处是不是应该有点什么？
如果只是偶尔的数据同步，那么手动操作 DataX 就够了，又不是不能用
但是如果是定时同步，并且有非常多的同步，你们还手动操作吗
所有要加个模块
https://gitee.com/youzhibing/qsl-datax/tree/master/qsl-datax-hook
由这个模块去拉起 DataX 进程的同时去对接调度平台
调度平台有很多，例如
XXL-JOB、DolphinSchedulerElastic-Job等等
qsl-datax-hook 目前只实现了 DataX 进程的拉起
至于调度平台的对接，需要你们去对接（楼主又不知道你们用的哪个调度平台！）
接下来做什么？
是不是调试 qsl-datax-hook 与 DataX 的对接
打包我们改造的 DataX
不出意外的话，在 qsl-datax/target/datax/datax/ 目录下出现了我们熟悉的目录结构
所以请大声的告诉我，DataX 的 home 目录 是什么？
G:\qsl-datax\target\datax\datax
执行 com.qsl.hook.DataXManagerTest#exec
这个代码就比较简单了，相信你们都能看懂
顺利的话，同步成功日志如下
至此，集成算是基本完成
但是我还要补充一点，就是日志问题
DataX 有自己的日志
而 qsl-datax-hook 的日志正好包含了 DataX 的日志，所以呢？
是不是重复了，是不是可以取消一个？
因为后续主要是跟 qsl-datax-hook 打交道，所以推荐做法是
保留 DataX 的日志控制台输出，但不写入文件
qsl-datax-hook 既要控制台输出，还要写入文件
DataX 日志调整
qsl-data-hook 日志调整
具体怎么保留日志，是否需要都保留，你们根据自己项目的实际情况进行调整
切勿生搬硬套！！！
组件安全漏洞修复，虽说不情愿，但还是要修滴
关于对 DataX 的改造，除非必要，不推荐大家去改
如果对 DataX 掌握的不够，很容易改出问题
能不动就不要动，改好没绩效，改出问题要背锅，吃力不讨好，又不是不能跑
DataX + datax-web 基本满足大部分需求，直接拿来用，不推荐重复造轮子
