DataX的框架的核心部分
1、配置贯穿DataX,all in configuration,将配置的json用到了极致
2、另一块是通过URLClassLoader实现插件的热加载。
Job&Task概念
在DataX的逻辑模型中包括job、task两个维度,通过将job进行task拆分,然后将task合并到taskGroup进行运行。
job实例运行在jobContainer容器中,它是所有任务的master,负责初始化、拆分、调度、运行、回收、监控和汇报,但它并不做实际的数据同步操作。
Job: Job是DataX用以描述从一个源头到一个目的端的同步作业,是DataX数据同步的最小业务单元。比如:从一张mysql的表同步到odps的一个表的特定分区。
Task: Task是为最大化而把Job拆分得到的最小执行单元。比如:读一张有1024个分表的mysql分库分表的Job,拆分成1024个读Task,用若干个并发执行。
TaskGroup: 描述的是一组Task集合。在同一个TaskGroupContainer执行下的Task集合称之为TaskGroup。
JobContainer: Job执行器,负责Job全局拆分、调度、前置语句和后置语句等工作的工作单元
TaskGroupContainer: TaskGroup执行器,负责执行一组Task的工作单元。
简而言之, Job拆分成Task,分别在框架提供的容器中执行,插件只需要实现Job和Task两部分逻辑。
启动过程
datax开启本地debug模式
1、github上下载DataX的源码并通过以下命令进行编译,github官网有编译命令,如果遇到依赖包无法下载可以省去部分writer或reader插件,不影响debug。
进到本地项目下,执行打包命令:
mvn -U clean package assembly:assembly -Dmaven.test.skip=true
可能遇到的依赖包问题:
2、启动类:Engine类 需要的配置的启动参数:
VM options:
-server -Xms1g -Xmx1g -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=E:\workspace\DataX\target\datax\datax\log
-Dloglevel=info -Dfile.encoding=UTF-8
-Dlogback.statusListenerClass=ch.qos.logback.core.status.NopStatusListener
-Djava.security.egd=file:///dev/urandom -Ddatax.home=E:\workspace\DataX\target\datax\datax
-Dlogback.configurationFile=E:\workspace\DataX\target\datax\datax\conf\logback.xml
-classpath E:\workspace\DataX\target\datax\datax\lib*
-Dlog.file.name=s_datax_job_job_json
Program arguments:
-mode standalone -jobid -1
-job E:\workspace\DataX\target\datax\datax\job\job.json
启动步骤解析
1、解析配置,包括job.json、core.json、plugin.json三个配置
2、设置jobId到configuration当中
3、启动Engine,通过Engine.start()进入启动程序
4、设置RUNTIME_MODEconfiguration当中
5、通过JobContainer的start()方法启动
6、依次执行job的preHandler()、init()、prepare()、split()、schedule()、- post()、postHandle()等方法。
7、init()方法涉及到根据configuration来初始化reader和writer插件,这里涉及到jar包热加载以及调用插件init()操作方法,同时设置reader和writer的configuration信息
8、prepare()方法涉及到初始化reader和writer插件的初始化,通过调用插件的prepare()方法实现,每个插件都有自己的jarLoader,通过集成URLClassloader实现而来
9、split()方法通过adjustChannelNumber()方法调整channel个数,同时执行reader和writer最细粒度的切分,需要注意的是,writer的切分结果要参照reader的切分结果,达到切分后数目相等,才能满足1:1的通道模型
10、channel的计数主要是根据byte和record的限速来实现的,在split()的函数中第一步就是计算channel的大小
11、split()方法reader插件会根据channel的值进行拆分,但是有些reader插件可能不会参考channel的值,writer插件会完全根据reader的插件1:1进行返回
12、split()方法内部的mergeReaderAndWriterTaskConfigs()负责合并reader、writer、以及transformer三者关系,生成task的配置,并且重写job.content的配置
13、schedule()方法根据split()拆分生成的task配置分配生成taskGroup对象,根据task的数量和单个taskGroup支持的task数量进行配置,两者相除就可以得出taskGroup的数量
14、schdule()内部通过AbstractScheduler的schedule()执行,继续执行startAllTaskGroup()方法创建所有的TaskGroupContainer组织相关的task,TaskGroupContainerRunner负责运行TaskGroupContainer执行分配的task。scheduler的具体实现类为ProcessInnerScheduler。
15、taskGroupContainerExecutorService启动固定的线程池用以执行TaskGroupContainerRunner对象,TaskGroupContainerRunner的run()方法调用taskGroupContainer.start()方法,针对每个channel创建一个TaskExecutor,通过taskExecutor.doStart()启动任务
启动过程源码分析
Engine入口main函数
public class Engine {
//main函数主要做两件事情,分别是:
//1、解析job相关配置生成configuration。
//2、依据配置启动Engine。
public static void main(String[] args) throws Exception {
int exitCode = 0;
try {
Engine.entry(args);
} catch (Throwable e) {
System.exit(exitCode);
}
}
public static void entry(final String[] args) throws Throwable {
// 省略相关参数的解析代码
// 获取job的配置路径信息
String jobPath = cl.getOptionValue("job");
// 如果用户没有明确指定jobid, 则 datax.py 会指定 jobid 默认值为-1
String jobIdString = cl.getOptionValue("jobid");
RUNTIME_MODE = cl.getOptionValue("mode");
// configuration解析包括三部分的配置解析合并解析结果并返回,分别是:
//1、解析job的配置信息,由启动参数指定job.json文件。
//2、解析DataX自带配置信息,由默认指定的core.json文件。
//3、解析读写插件配置信息,由job.json指定的reader和writer插件信息
Configuration configuration = ConfigParser.parse(jobPath);
// 省略相关代码
boolean isStandAloneMode = "standalone".equalsIgnoreCase(RUNTIME_MODE);
configuration.set(CoreConstant.DATAX_CORE_CONTAINER_JOB_ID, jobId);
// 根据配置启动参数
Engine engine = new Engine();
engine.start(configuration);
}
}
Engine的start过程
public class Engine {
private static final Logger LOG = LoggerFactory.getLogger(Engine.class);
private static String RUNTIME_MODE;
/* check job model (job/task) first */
//start过程中做了两件事:
//1、创建JobContainer对象