Streamsets FAQ（二）关于SS的8小时问题

1、问题描述

在使用SS进行数据同步的过程中发现有8小时差值问题，具体表现为在使用JDBC Query Consumer这样的stage入到kudu时发现数据比MySQL中数据小8小时。在使用MySQL Binary Log这样的stage解析binlog数据时数据比MySQL中数据大了8小时，针对2种情况处理方式是不一样的。

 

2、解决方案

2.1、JDBC Query Consumer

在JDBC Query Consumer这个stage的JDBC配置项中往下拉，在最后的Additional JDBC Configuration Properties中增加2个配置

serverTimezone    UTC
useTimezone    true

 

清空kudu数据，重置pipeline的offset，运行一下发现数据到kudu后时区不一致的问题解决了

 

2.2、MySQL Binary Log

SS中解析binlog使用的是一个开源项目mysql-binlog-connector-java

https://github.com/shyiko/mysql-binlog-connector-java

该问题github上有人遇到过

https://github.com/shyiko/mysql-binlog-connector-java/issues/193

我们看一下当前SS服务中的mysql-binlog-connector-java是哪个版本

sudo find /opt/ -name mysql-binlog-connector-java* 

 

 

/opt/cloudera/parcels/STREAMSETS_DATACOLLECTOR/streamsets-libs/streamsets-datacollector-mysql-binlog-lib/lib

streamsets-3.13.0中使用的mysql-binlog-connector-java是0.13.0版本，找到0.13.0的源码，

https://github.com/shyiko/mysql-binlog-connector-java/blob/0.13.0/src/main/java/com/github/shyiko/mysql/binlog/event/deserialization/AbstractRowsEventDataDeserializer.java

修改其中的AbstractRowsEventDataDeserializer.java，修改其中的fallbackToGC方法，重新定义Calendar类对象，去除TimeZone.getTimeZone("GMT")

private static long fallbackToGC(int year, int month, int dayOfMonth, int hourOfDay,
                                         int minute, int second, int millis) {
	// 将原先的Calendar c = Calendar.getInstance(TimeZone.getTimeZone("GMT"));注释掉
	//Calendar c = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
	// 重新定义Calendar
	Calendar c = Calendar.getInstance();
	c.set(Calendar.YEAR, year);
	c.set(Calendar.MONTH, month - 1);
	c.set(Calendar.DAY_OF_MONTH, dayOfMonth);
	c.set(Calendar.HOUR_OF_DAY, hourOfDay);
	c.set(Calendar.MINUTE, minute);
	c.set(Calendar.SECOND, second);
	c.set(Calendar.MILLISECOND, millis);
	return c.getTimeInMillis();
}

使用maven打包

mvn package -DskipTests

修改好之后打成jar包，替换SS服务器上的mysql-binlog-connector-java-0.13.0.jar，重启SS服务，再运行一下这个pipeline，往test表插入几条数据，验证本地输出的datetime类型的数据值，发现其数值已经正常

 

注：修改mysql-binlog-connector-java源码重新打包来解决8小时问题最终并带来了新的问题，即解析binlog入库kudu导致kudu的timestamp字段时间比mysql的datetime字段少8小时，最终还是将mysql-binlog-connector-java还原为系统自带的，务必注意，如果mysql的字段类型不是datetime而是timestamp的话使用自带的mysql-binlog-connector-java会导致kudu比mysql少8小时，因此最好mysql时间都定义为datetime类型。