datax里所有的关系型数据库都走通用的处理Reader，com.alibaba.datax.plugin.rdbms.reader.CommonRdbmsReader，当进行split的时候会进行切分获取channel的个数，
public List<Configuration> split(Configuration originalConfig,
int adviceNumber) {
return ReaderSplitUtil.doSplit(originalConfig, adviceNumber);
}
继续进入doSplit方法com.alibaba.datax.plugin.rdbms.reader.util.ReaderSplitUtil 此处会去判断是否是table配置的模式
if (isTableMode) {
// adviceNumber这里是channel数量大小, 即datax并发task数量
// eachTableShouldSplittedNumber是单表应该切分的份数, 向上取整可能和adviceNumber没有比例关系了已经
eachTableShouldSplittedNumber = calculateEachTableShouldSplittedNumber(
adviceNumber, originalSliceConfig.getInt(Constant.TABLE_NUMBER_MARK));
}
如果前面计算的adviceNumber=3 配置了一个table 则每个表分到的channel是3/1=3，
// 说明是配置的 table 方式
if (isTableMode) {
// 已在之前进行了扩展和`处理，可以直接使用
List<String> tables = connConf.getList(Key.TABLE, String.class);
Validate.isTrue(null != tables && !tables.isEmpty(), "您读取数据库表配置错误.");
String splitPk = originalSliceConfig.getString(Key.SPLIT_PK, null);
/**
* 1-判断是否配置了splitPk,如果没有配置则每个table都会当成一个任务，生成一个配置文件给任务运行使用
* 2-如果配置了splitPk，如果只配了一个table，则重新计算eachTableShouldSplittedNumber=eachTableShouldSplittedNumber * 5;
* 3-如果配置了多个table,eachTableShouldSplittedNumber不变，然后循环对每个表进行切分splitSingleTable
*/
//最终切分份数不一定等于 eachTableShouldSplittedNumber
boolean needSplitTable = eachTableShouldSplittedNumber > 1
&& StringUtils.isNotBlank(splitPk);
if (needSplitTable) {
if (tables.size() == 1) {
//原来:如果是单表的，主键切分num=num*2+1
// splitPk is null这类的情况的数据量本身就比真实数据量少很多, 和channel大小比率关系时，不建议考虑
//eachTableShouldSplittedNumber = eachTableShouldSplittedNumber * 2 + 1;// 不应该加1导致长尾
//考虑其他比率数字?(splitPk is null, 忽略此长尾)
eachTableShouldSplittedNumber = eachTableShouldSplittedNumber * 5;
}
// 尝试对每个表，切分为eachTableShouldSplittedNumber 份
for (String table : tables) {
tempSlice = sliceConfig.clone();
tempSlice.set(Key.TABLE, table);
List<Configuration> splittedSlices = SingleTableSplitUtil
.splitSingleTable(tempSlice, eachTableShouldSplittedNumber);
splittedConfigs.addAll(splittedSlices);
}
} else {
for (String table : tables) {
tempSlice = sliceConfig.clone();
tempSlice.set(Key.TABLE, table);
String queryColumn = HintUtil.buildQueryColumn(jdbcUrl, table, column);
tempSlice.set(Key.QUERY_SQL, SingleTableSplitUtil.buildQuerySql(queryColumn, table, where));
splittedConfigs.add(tempSlice);
}
}
} else {
// 说明是配置的 querySql 方式
List<String> sqls = connConf.getList(Key.QUERY_SQL, String.class);
// TODO 是否check 配置为多条语句？？
for (String querySql : sqls) {
tempSlice = sliceConfig.clone();
tempSlice.set(Key.QUERY_SQL, querySql);
splittedConfigs.add(tempSlice);
}
}
此处主要分为两种，一种是table模式配置，一种是querysql模式配置, querySql模式相对简单,配置了几个sql,就会生成几个任务的配置文件。
我们主要关注table模式,主要的流程:
/** * 1-判断是否配置了splitPk,如果没有配置则每个table都会当成一个任务，生成一个配置文件给任务运行使用 * 2-如果配置了splitPk，如果只配了一个table，则重新计算eachTableShouldSplittedNumber=eachTableShouldSplittedNumber * 5; * 3-如果配置了多个table,eachTableShouldSplittedNumber不变，然后循环对每个表进行切分splitSingleTable */
接下来关注splitSingleTable方法
大体流程是:
首先会根据 Configuration configuration, int adviceNum 配置文件信息和需要切分的个数进行切分会计算出splitPk的最大最小值，然后按照adviceNum进行分割，然后生成具体的sql
如果配置了15个channel，单表， 拆分，则此时通过上面的流程最后可以计算出task数目为75，在我的mysql表中有3089条数据，此时他会返回下面的配置总共75个有效配置，主要是看querySql,每个配置的条件都会不同。这只是其中一个
{
"column": "id,username,telephone",
"columnList": ["id", "username", "telephone"],
"fetchSize": -2147483648,
"isTableMode": true,
"jdbcUrl": "jdbc:mysql://localhost:3306/datax?yearIsDateType=false&zeroDateTimeBehavior=convertToNull&tinyInt1isBit=false&rewriteBatchedStatements=true",
"loadBalanceResourceMark": "localhost",
"password": "root123",
"pkType": "pkTypeLong",
"querySql": "select id,username,telephone from user where (547 <= id AND id < 588) ",
"splitPk": "id",
"table": "user",
"tableNumber": 1,
"username": "root"
}
第一个sql：
"querySql": "select id,username,telephone from user where (1 <= id AND id < 43) "
最后一个sql是:
"querySql": "select id,username,telephone from user where id IS NULL"
最后一个有效sql是:
"querySql": "select id,username,telephone from user where (3048 <= id AND id <= 3089) "
可以看到和表中的数据一致，这里主要是把数据量过大的表，按照配置计算出的channel进行切分，
然后生成分段的sql,一个sql对应一个任务，进行执行。
后面会根据taskGroup的个数，来对着75个任务进行分组，然后提交到线程池中并发执行任务.
如果没有SPLIT_PK（目前splitPk仅支持整形、字符串数据切分）,则为每个表生成一个任务
在DataX中，mysqlreader配置有两种模式，一种是table模式，另外一种是querySql模式，两种模式使用起来略有差别。
table模式
在table模式下， channel个数决定了reader和writer的个数上限，假设为m个：如果指定了splitPk字段，DataX会将mysql表中数据按照splitPk切分成n段，n大致为5倍的channel个数。
splitPk的字段限制了必需是整型或者字符串类型。由于DataX的实现方式是按照spliPk字段分段查询数据库表，那么spliPk字段的选取应该尽可能的选择分布均匀且有索引的字段，比如主键id、唯一键等字段。DataX会启动m个reader线程，消费DataX切分好的n个查询sql语句（task）， 对应的会有m个writer线程将查询出来的数据写入目标数据源中，并行度为m（也就是配置的channel个数），如果不指定splitPk字段，DataX将不会进行数据的切分，并行度直接退化成1。
需要指出的是，table模式下，如果用户指定了spliPk将数据切分成了n段，由于这些task不是在同一个事务下进行select，那么最终取出的全量数据很有可能是不一致的。为了拿到一致性数据，要么不要配置spliPk使用单线程，要么确保mysql中要导出的数据不会再发生变化。
querySql模式
querySql模式一般用于有条件的数据导出，
"connection": [
{
"querySql": [ #指定执行的SQL语句
"select bucket_name, delta , timestamp ,cdn_in, cdn_out ,total_request from vip_quota where bucket_name='xxx' "
],
"jdbcUrl": ["jdbc:mysql://10.10.0.8:3306/db1?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true" #jdbc连接串
]
}
]
在此模式下，DataX不会再按照指定的column、table参数进行sql的拼接，而是会直接略过这些配置（如果有），直接执行querySql语句，task数量总是1，因此在此模式下channel的配置不再有多线程的效果。
性能调优
有人肯定会有疑问，有什么办法可以尽可能加速数据的导出呢？
一般来说，大家首先想到的是提高并发度。在DataX中channel的个数决定了并发数量，但是要使channel参数生效，并不是简单配一下channel就完事了。在MySQL导入Tablestore表的场景下，channel生效仅在能够split出多个SQL语句的场景下，也就是table模式+spliPk下有用。
DataX的数据同步涉及三部分：
1.数据读取 2.数据交换 3.数据写入
对于以上三个环节，都有不同的优化方式，分析如下。
1.数据读取
对于数据源读取，导出的两种模式：table模式和sqlQuery模式前面做了阐述，这里不再重复。
2. 数据交换
对于数据交换，前面提到，发送给MySQL数据库SQL语句后会得到查询的数据集，缓存在DataX的buffer中；除此之外，每个channel也维护了自己的record队列，如果存在并发，channel的个数越多，也会需要更多的内存。因此首先需要考虑的是jvm的内存大小参数, 这个在启动jvm进程的时候配置。
除此之外，有几个控制channel的关键参数
"transport": {
"channel": {
"class": "com.alibaba.datax.core.transport.channel.memory.MemoryChannel",
"speed": {
"byte": -1,
"record": -1
},
"flowControlInterval": 20,
"capacity": 512,
"byteCapacity": 67108864
},
"exchanger": {
"class": "com.alibaba.datax.core.plugin.BufferedRecordExchanger",
"bufferSize": 32
}
},
以上配置位于conf/core.json中：capacity限制了channel中队列的大小（也就是最多缓存record的个数）byteCapacity限制了record占用的内存大小，core.json中的默认配置是64MB，若不指定将会被配置为8MB
这两个参数决定了每个channel能buffer的记录数量和内存占用情况，如果有需要调整，用户应该按照DataX实际的运行环境予以配置。例如MySQL中每个record都比较大，那么可以考虑适当调高byteCapacity，当然调整这个参数还要考虑机器的内存情况。
bufferSize指定了BufferedRecordExchanger的缓存，reader读了多少个往channel放。
一般情况下，channel队列本身配置的调整并不会很常见，但是对于另外几个流控参数，在使用DataX的时候应该注意。有两个常用的流控参数：
a. byte 限制通道的默认传输速率， -1表示不限制
b. record 限制通道的传输记录数，-1表示不限制
这两个参数都是在flowControlInterval间隔里采样后根据采样值来决定是否流控的。
{
"core": { #定义了全局的系统参数，不指定会使用默认值
"transport": {
"channel": {
"speed": {
"record": 5000,
"byte": 102400
}
}
}
},
"job": {
"setting": {
"speed": { #定义了单个channel的控制参数
"record": 10000,
},
"errorLimit": {
"record": 0,
"percentage": 0.02
}
},
"content": [
{
"reader": {
.....#省略
},
"writer": {
.....#省略
}
}
]
}
}
3.数据写入
适当的提高批量写入的批次大小（batchWriteCount），也可以有效地提高吞吐率。相关关键配置如下：
{
"job": {
"setting": {
....#省略
},
"content": [
{
"reader": {
.....#省略
},
"writer": {
"name": "otswriter",
"parameter": {
.......
"writeMode":"UpdateRow",
"batchWriteCount":100
}
}
}
]
}
}