记一次DataX-MysqlReader性能优化
一、问题背景
最近在做Datax从阿里云rds数据库到Hive数据同步任务时，发现同步耗时很久，500万的数据同步配置了splitPk并配置了50个线程并发需要212s，任务同步的平均速率一直保持在3-4M/s，而本地的Mysql测试数据库同步时不分片的平均速率就能到20M/s。
二. 集群环境
Rds环境：8000iops; 8core; 16g内存
分片字段类型：bigint类型
Mysql驱动版本: 5.1.31
Datax版本：3.0
三. Datax日志
接下来直接看datax日志最后打印的统计日志。
可以很明显的看到datax给我们的提示是：
All Task WaitReaderTime 6449.159s ，All Task WaitWriterTime 2.202s
说明肯定是datax在读取rds时的速度很慢，耗时在读等待中，说明读的慢，而写的时间只有2秒，因此定位的重点需要看一下datax对于rds的读取逻辑，看看是不是有提升的空间。看task源码后得知，datax本身是额外加了一些监控设置的，但默认不开启的，因此需要改一下{datax-path}/conf/core.json配置文件将其开启
将trace :enable改为true，重跑一下任务可以看到更加详细的日志文件
发现是RESULT_NEXT_ALL平均耗时在191秒，最大的一个任务耗时248秒。全局搜索一下这个参数，可以定位到这个是统计了CommonRdbmsReader中rs.next()的时间。
进入到Mysql driver的源码底层，发现当fetchSize值为Integer.MIN_VALUE时，每次都只从服务器获取一条记录，因此顺着这个思路需要验证下最终是不是走的这个逻辑。
package com.mysql.jdbc;
public class RowDataCursor implements RowData {
private void fetchMoreRows() throws SQLException {
if (this.lastRowFetched) {
this.fetchedRows = new ArrayList(0);
return;
}
synchronized (this.owner.connection.getConnectionMutex()) {
boolean oldFirstFetchCompleted = this.firstFetchCompleted;
if (!this.firstFetchCompleted) {
this.firstFetchCompleted = true;
}
int numRowsToFetch = this.owner.getFetchSize();
if (numRowsToFetch == 0) {
numRowsToFetch = this.prepStmt.getFetchSize();
}
if (numRowsToFetch == Integer.MIN_VALUE) {
// Handle the case where the user used 'old'
// streaming result sets
numRowsToFetch = 1;
}
this.fetchedRows = this.mysql.fetchRowsViaCursor(this.fetchedRows,
this.statementIdOnServer, this.metadata, numRowsToFetch,
this.useBufferRowExplicit);
this.currentPositionInFetchedRows = BEFORE_START_OF_ROWS;
if ((this.mysql.getServerStatus() & SERVER_STATUS_LAST_ROW_SENT) != 0) {
this.lastRowFetched = true;
if (!oldFirstFetchCompleted && this.fetchedRows.size() == 0) {
this.wasEmpty = true;
}
}
}
}
}
因此接下来主要的代码逻辑需要重新梳理一下这个fetchSize是怎么一步步传下来的。所以从Datax Reader开始看看有没有设置fetchSize的地方（重点需要查看的代码逻辑：MysqlReader.task->CommonRdbmsReader.task）
四、Datax-MysqlReader
注：以下代码经过删减，为了方便查看。
先看MysqlReader，果然它在init时做了一步操作，直接忽略用户设置的fetSize任何值，将fetchSize默认配置成了 Inter.MIN_VALUE，并且在task中将其取了出来。（主要注意的是：虽说job中的conf和task的conf名称不一样，但值是一样的都是 super.getPluginJobConf()而来，因此在job初始化时，就已经默认将fetchsize设置成了int的最小值）
package com.alibaba.datax.plugin.reader.mysqlreader;
public class MysqlReader extends Reader {
private static final DataBaseType DATABASE_TYPE = DataBaseType.MySql;
public static class Job extends Reader.Job {
private static final Logger LOG = LoggerFactory
.getLogger(Job.class);
@Override
public void init() {
this.originalConfig = super.getPluginJobConf();
Integer userConfigedFetchSize = this.originalConfig.getInt(Constant.FETCH_SIZE);
if (userConfigedFetchSize != null) {
LOG.warn("对 mysqlreader 不需要配置 fetchSize, mysqlreader 将会忽略这项配置. 如果您不想再看到此警告,请去除fetchSize 配置.");
}
this.originalConfig.set(Constant.FETCH_SIZE, Integer.MIN_VALUE);
this.commonRdbmsReaderJob = new CommonRdbmsReader.Job(DATABASE_TYPE);
this.commonRdbmsReaderJob.init(this.originalConfig);
}
}
public static class Task extends Reader.Task {
@Override
public void init() {
this.readerSliceConfig = super.getPluginJobConf();
this.commonRdbmsReaderTask = new CommonRdbmsReader.Task(DATABASE_TYPE, super.getTaskGroupId(), super.getTaskId());
this.commonRdbmsReaderTask.init(this.readerSliceConfig);
}
@Override
public void startRead(RecordSender recordSender) {
int fetchSize = this.readerSliceConfig.getInt(Constant.FETCH_SIZE);
this.commonRdbmsReaderTask.startRead(this.readerSliceConfig, recordSender,
super.getTaskPluginCollector(), fetchSize);
}
}
}可以看到mysqlReaderTask初始化之后，最终走的是commRdbmsReaderTask.startRead方法。
package com.alibaba.datax.plugin.rdbms.reader;
public class CommonRdbmsReader {
public static class Task {
public void startRead(Configuration readerSliceConfig,
RecordSender recordSender,
TaskPluginCollector taskPluginCollector, int fetchSize) {
String querySql = readerSliceConfig.getString(Key.QUERY_SQL);
String table = readerSliceConfig.getString(Key.TABLE);
PerfTrace.getInstance().addTaskDetails(taskId, table + "," + basicMsg);
LOG.info("Begin to read record by Sql: [{}\n] {}.",
querySql, basicMsg);
PerfRecord queryPerfRecord = new PerfRecord(taskGroupId,taskId, PerfRecord.PHASE.SQL_QUERY);
queryPerfRecord.start();
Connection conn = DBUtil.getConnection(this.dataBaseType, jdbcUrl,
username, password);
// session config .etc related
DBUtil.dealWithSessionConfig(conn, readerSliceConfig,
this.dataBaseType, basicMsg);
int columnNumber = 0;
ResultSet rs = null;
try {
rs = DBUtil.query(conn, querySql, fetchSize);
queryPerfRecord.end();
ResultSetMetaData metaData = rs.getMetaData();
columnNumber = metaData.getColumnCount();
//这个统计干净的result_Next时间
PerfRecord allResultPerfRecord = new PerfRecord(taskGroupId, taskId, PerfRecord.PHASE.RESULT_NEXT_ALL);
allResultPerfRecord.start();
long rsNextUsedTime = 0;
long lastTime = System.nanoTime();
while (rs.next()) {
rsNextUsedTime += (System.nanoTime() - lastTime);
this.transportOneRecord(recordSender, rs,
metaData, columnNumber, mandatoryEncoding, taskPluginCollector);
lastTime = System.nanoTime();
}
allResultPerfRecord.end(rsNextUsedTime);
//目前大盘是依赖这个打印，而之前这个Finish read record是包含了sql查询和result next的全部时间
LOG.info("Finished read record by Sql: [{}\n] {}.",
querySql, basicMsg);
}catch (Exception e) {
throw RdbmsException.asQueryException(this.dataBaseType, e, querySql, table, username);
} finally {
DBUtil.closeDBResources(null, conn);
}
}
protected Record transportOneRecord(RecordSender recordSender, ResultSet rs,
ResultSetMetaData metaData, int columnNumber, String mandatoryEncoding,
TaskPluginCollector taskPluginCollector) {
Record record = buildRecord(recordSender,rs,metaData,columnNumber,mandatoryEncoding,taskPluginCollector);
recordSender.sendToWriter(record);
return record;
}
}
接着再看fetchSize传入到了DBUtil.query中
DBUtil.java:
public static ResultSet query(Connection conn, String sql, int fetchSize, int queryTimeout)
throws SQLException {
// make sure autocommit is off
conn.setAutoCommit(false);
Statement stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(fetchSize);
stmt.setQueryTimeout(queryTimeout);
return query(stmt, sql);
}将fetchSize=Integer.MIN_VALUE值设置到了Statement 中，并且通过游标的方式去服务器端获取结果。
至此结合最开始看的mysql driver底层，就可得知当fetchSize=Integer.MIN_VALUE时，导致每次从外网读取rds记录时，是以每次一条去获取，会浪费大量的网络开销，因此解决方案就是将fetchSize值改大，减少取数据时的网络开销。
结合网上查阅资料：mysql的jdbc中fetchsize支持的问题
下边开始调整：
1、修改MysqlReader代码使其能够使用用户自定义配置，而不是粗暴的都走fetchSize=Integer.MIN_VALUE
需要调整MysqlReader代码，加个判断逻辑，如果driver版本低于5.0的还是走默认的fetchSize（当然如果你的Mysql 服务的版本低于5.0，即使用的高版本驱动，fetchSize也可能不生效），否则可以使用用户自定义配置的fetchSize去取数据。这里如果确定了版本，把那行默认设置的代码直接删了也是可以的。
public static class Job extends Reader.Job {
@Override
public void init() {
this.originalConfig = super.getPluginJobConf();
Integer userConfigedFetchSize = this.originalConfig.getInt(Constant.FETCH_SIZE);
if("5.0".compareTo(Driver.VERSION) > 0 ){
if (userConfigedFetchSize != null) {
LOG.warn("对mysql版本低于5.0的 mysqlreader 不需要配置 fetchSize, mysqlreader 将会忽略这项配置. 如果您不想再看到此警告,请去除fetchSize 配置.");
}
this.originalConfig.set(Constant.FETCH_SIZE, Integer.MIN_VALUE);
}
this.commonRdbmsReaderJob = new CommonRdbmsReader.Job(DATABASE_TYPE);
this.commonRdbmsReaderJob.init(this.originalConfig);
}
}接着修改自己的job.json去指定一个fetchSize值
{
"job": {
"content": [{
"reader": {
"parameter": {
"modifyUserName": "",
"password": "",
"column": [],
"connection": [{
"jdbcUrl": [],
"table": []
}],
"username": "root",
"fetchSize": 5000
},
"name": "mysqlreader"
},
"writer": {
"parameter": {},
"name": ""
}
}],
"setting": {
"errorLimit": {
"record": 0
},
"speed": {
"channel": 5,
"throttle": false
}
}
}
}
2、修改运行的job.json或者修改datax源码方式，去修改jdbc连接参数
在DataBaseType里可以看到datax默认会为我们加上一系列参数，因此很简单，我们只需要在后边加上
&useCursorFetch=true
package com.alibaba.datax.plugin.rdbms.util;
import com.alibaba.datax.common.exception.DataXException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
/**
* refer:http://blog.csdn.net/ring0hx/article/details/6152528
*
*/
public enum DataBaseType {
public String appendJDBCSuffixForReader(String jdbc) {
String result = jdbc;
String suffix = null;
switch (this) {
case MySql:
case DRDS:
suffix = "yearIsDateType=false&zeroDateTimeBehavior=convertToNull&tinyInt1isBit=false&rewriteBatchedStatements=true&useCursorFetch=true";
if (jdbc.contains("?")) {
result = jdbc + "&" + suffix;
} else {
result = jdbc + "?" + suffix;
}
break;
case Oracle:
break;
case SQLServer:
break;
case DB2:
break;
case PostgreSQL:
break;
case RDBMS:
break;
case HANA:
break;
case ELK:
break;
default:
throw DataXException.asDataXException(DBUtilErrorCode.UNSUPPORTED_TYPE, "unsupported database type.");
}
return result;
}
}
五、优化效果
自己配置的fetchSize。看一下优化后的效果
效果还是挺明显的，从212s提升到135s，但继续增加fetchSize提升也不是很明显。在大佬的提醒下，mysql在网络传输时应该有压缩的策略。因此网上找了一下jdbc连接参数里有没有，找到了另一个参数useCompression默认还是关闭的状态。
&useCompression=true
所以立马将这个参数也加到了代码中，运行测试一下。
运行时间又从135s缩减到了78s，效果也是很明显的。
六、总结
不得不说datax设计很强大。已经提供了比较好的监控统计的日志，对于定位问题节省了我们大量的时间。