JobContainer 是什么？

jobContainer 是许多job的组合体，比如我有个任务是同时读取mysql和oracle的表然后写导hdfs的。此时mysqlreader+oraclereader打包起来就是一个container。但是实际来说我们都是只有一种reader的。

job是什么？

简单的理解就是我要 mysql->hdfs这这任务就是一个job

task是什么？

task是job的更细层次划分，比如mysql id 1->100w 共计100w条数据

我把 mysql->hdfs 这个job划分为10个task

mysql 1-10w ->hdfs

mysql 10-20w->hdfs

。。。。

mysql 90w-100->hdfs

这十个任务每个任务就是一个task。

taskgroup 是什么？

顾名思义就是将几个task划分为一个小组进行管理。几个呢？5个。可以在datax_home/conf/core.json调整。

 

channel是什么？

channel可以理解为在部分的job 种可以控制 taskgroup的数量。可以控制并发数

例如mysql postgresql oracle 这种 task的数量=channel数*5+1，

但是hdfsreader这种 设置channel数多少也不起作用。

下面是源码的学习和分析。

JobContainer.java

 这里是将一个job切分为多个任务，这里我还是举例，oraclereader->oraclewriter channel=10

注意我们之前配置的json只是job的config。

doReaderSplit的返回值就是task的config，taskconfig和jobconfig的不同有，里面加个标记 类似reader=oracle，然后job的sql是 select * from t  ,taskconfig是 select * from t where  xx<id<xx

sliceConfig.set(CommonConstant.LOAD_BALANCE_RESOURCE_MARK, DataBaseType.parseIpFromJdbcUrl(jdbcUrl));

dowriterSplit的返回值就是writerTaskConfig，其实就是jobconfig。

备注：我这里全都是简化的比喻，有的人写多个oraclewriter和多个oraclereader，然后table里有多个表，由于情况比较多我就不举例了，只说最常用的情况。

  List<Configuration> contentConfig = mergeReaderAndWriterTaskConfigs(
                readerTaskConfigs, writerTaskConfigs, transformerList);

这里还有个transformerList 怎么说？我查了参数没有 暂且看作0

那么此时readerTaskConfigs.size=51, writerTaskConfigs.size=51

这个merge方法的作用就是把readerTaskConfig和writerTaskConfigs 组装起来，成为了一个完整的taskconfig，同时还给task编号1 ，2，3，4....51.

举个简单例子

就是将这个job复制了51份，每一份reader的查询内容不一样，将where切分为了51份。

        this.configuration.set(CoreConstant.DATAX_JOB_CONTENT, contentConfig);

 最后this.configuration是jobConfguration，将contentConfig（51个taskConfig）set到jobContent里， 至此 JobContainer的start方法中的 split就完了。

然后重点是schedule方法，怎么分配这51个任务好好工作？

private void schedule() {
        /**
         * 这里的全局speed和每个channel的速度设置为B/s
         */
        //按照说明 这里=5
        int channelsPerTaskGroup = this.configuration.getInt(
                CoreConstant.DATAX_CORE_CONTAINER_TASKGROUP_CHANNEL, 5);
        //这个获取的json里的job.content 的个数，由于split里已经set了51个task 这里=51
        int taskNumber = this.configuration.getList(
                CoreConstant.DATAX_JOB_CONTENT).size();
        //needChannelNumber=10 taskNumber=51 所以这里=10
        this.needChannelNumber = Math.min(this.needChannelNumber, taskNumber);
        PerfTrace.getInstance().setChannelNumber(needChannelNumber);

        /**
         * 通过获取配置信息得到每个taskGroup需要运行哪些tasks任务
         */
        //这里就是计算taskGroup有多少个task 其实就是(int) Math.ceil(1.0 * 10/ 5)=2;
        //其实这里面真鸡儿的复杂，写这个方法的人考虑到不同的reader，比如mysql的task1和oracle的task1总不能放到一个group里把。所以简单的来看就是 channels/ 5 向上取整。
        //然后将task组装放到了taskGroup里，此时就是2个group 一个有25个task 一个有26个task
        //同时还将channel数也拆分了 每个group 有5个channel
        List<Configuration> taskGroupConfigs = JobAssignUtil.assignFairly(this.configuration,
                this.needChannelNumber, channelsPerTaskGroup);

        ("Scheduler starts [{}] taskGroups.", taskGroupConfigs.size());

        ExecuteMode executeMode = null;
        AbstractScheduler scheduler;
        try {
        	executeMode = ExecuteMode.STANDALONE;
            scheduler = initStandaloneScheduler(this.configuration);

            //设置 executeMode
            for (Configuration taskGroupConfig : taskGroupConfigs) {
                taskGroupConfig.set(CoreConstant.DATAX_CORE_CONTAINER_JOB_MODE, executeMode.getValue());
            }

            if (executeMode == ExecuteMode.LOCAL || executeMode == ExecuteMode.DISTRIBUTE) {
                if (this.jobId <= 0) {
                    throw DataXException.asDataXException(FrameworkErrorCode.RUNTIME_ERROR,
                            "在[ local | distribute ]模式下必须设置jobId，并且其值 > 0 .");
                }
            }

            ("Running by {} Mode.", executeMode);

            this.startTransferTimeStamp = System.currentTimeMillis();

            scheduler.schedule(taskGroupConfigs);

            this.endTransferTimeStamp = System.currentTimeMillis();
        } catch (Exception e) {
            LOG.error("运行scheduler 模式[{}]出错.", executeMode);
            this.endTransferTimeStamp = System.currentTimeMillis();
            throw DataXException.asDataXException(
                    FrameworkErrorCode.RUNTIME_ERROR, e);
        }

        /**
         * 检查任务执行情况
         */
        this.checkLimit();
    }

可以看到打印的日志和我的备注一样。 

此时这一步schedule就完了，然后就是执行。

继续查看

 

 注意看此时是根据taskgroup为单位开始任务的

 后面就很清楚了。就是开启线程池提交任务，然后就是监控任务。

那么我们任务实际的速度肯定和线程的个数有关，此时就开启了两个线程。

但是转眼一想不对啊 原先1个线程->2个线程，那任务不会提升那么明显。

接着看TaskGroupContainer的start 方法由于较长。截取关键的

 判断正在运行的任务是否是小与channel数的，如果小于channel数，则让任务运行。这里的channel数因为在划分到taskgroup那个阶段也拆分了。所以每个taskGroup为5个channel。

那么我们从头梳理一下

1个job 2个taskGroup 10个channel 51个task。

实际上是将task划分到两个group管理，group1里可以同行运行5个task，group2里可以同时运行5个task，那么并发数量就是channel。

怎么验证的这个并发数？很简单继续看日志

 可以看到最开始就是5个start，然后就是1个end，紧接着一个又开始start。

只要有一个end 立马就有start，那么taskGroup[0]就是5个并发，和我们拆想的一样。

看datax的githu的介绍

核心模块介绍：

1. DataX完成单个数据同步的作业，我们称之为Job，DataX接受到一个Job之后，将启动一个进程来完成整个作业同步过程。DataX Job模块是单个作业的中枢管理节点，承担了数据清理、子任务切分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。
2. DataXJob启动后，会根据不同的源端切分策略，将Job切分成多个小的Task(子任务)，以便于并发执行。Task便是DataX作业的最小单元，每一个Task都会负责一部分数据的同步工作。
3. 切分多个Task之后，DataX Job会调用Scheduler模块，根据配置的并发数据量，将拆分成的Task重新组合，组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所有Task，默认单个任务组的并发数量为5。
4. 每一个Task都由TaskGroup负责启动，Task启动后，会固定启动Reader—>Channel—>Writer的线程来完成任务同步工作。
5. DataX作业运行起来之后， Job监控并等待多个TaskGroup模块任务完成，等待所有TaskGroup任务完成后Job成功退出。否则，异常退出，进程退出值非0

DataX调度流程：

举例来说，用户提交了一个DataX作业，并且配置了20个并发，目的是将一个100张分表的mysql数据同步到odps里面。 DataX的调度决策思路是：

1. DataXJob根据分库分表切分成了100个Task。
2. 根据20个并发，DataX计算共需要分配4个TaskGroup。
3. 4个TaskGroup平分切分好的100个Task，每一个TaskGroup负责以5个并发共计运行25个Task。

根据上面的例子就是我说的 100个task  20个并发就是20个channel   20/5=4个taskgroup

每个taskgroup内的task 100/4=25

但是能够同时运行的任务是 20个channel =20个并发。

由此 我们得到什么结论？

这个参数就是代表了taskGroup的并发度。

那么此时我有一个疑问了？

1个taskGroup 管理50个任务 10个并发度

和切分后 2个taskGroup 分别管理25个任务和5个并发度，这两种有什么区别嘛？

说实话我是没有看出区别，但是datax这么设计应该还是有它的原因的。

未完待续。。后面使用过程中如果想到了再补充