Streamsets FAQ（六）关于SS的8小时问题总结

1、问题描述

关于SS的8小时问题之前也写了2个文章，以为问题已经得到了解决，但是发现想的太简单，再次遇到这个问题，折腾了2天，现在把这个问题梳理一下。大数据平台使用的是CDH-6.2.0版本，安装在Centos7.6 64位服务器上，服务器时区为CST时区，SS使用的是3.13.0版本。

数据同步的需要首先是从各个业务系统MySQL同步到中间库MySQL上，再根据数据分析的需要，有选择性的从中间库MySQL同步到大数据平台的kudu中，MySQL版本统一为5.6的，MySQL时区和安装MySQL的服务器保持一致，即CST时区。中间库的表结构完全与业务系统保持一致。现在需要保证数据从业务库同步到中间库，中间库同步到kudu都是准确的。

业务库MySQL表时间字段既有date也有datetime和timestamp类型，中间库保持和业务系统一致，因此也是这三种类型都存在，kudu的时间类型只有timestamp。

先说一下业务库到中间库同步的时间问题，存量数据同步时三种MySQL时间类型同步到中间库MySQL都没有问题。增量数据通过binlog实时同步，业务系统MySQL的datetime类型同步到中间库会多出8小时，在JDBC Producer中配置serverTimezone为GMT+8无效，timestamp类型的没问题，date类型没问题。

再说一下中间库同步到kudu的时间问题（这里假设中间库时间都是正确的），存量数据同步时MySQL的date、datetime、timestamp到kudu的timestamp后时间都少了8小时，在JDBC Query Consumer中JDBC项的Additional JDBC Configuration Properties增加时区配置

serverTimezone UTC
useTimezone	true

配置后MySQL的datetime和timestamp类型到kudu的timestamp类型时间正确，但是MySQL的date类型同步到kudu的timestamp后少8小时。增量数据通过binlog实时同步，MySQL的date类型和datetime类型同步到kudu的timestamp正确，但是MySQL的timestamp同步到kudu的timestamp后时间少了8小时。

 

2、解决方案

2.1、测试数据

MySQL建表

CREATE TABLE `test` (
  `id` int(11) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  `weight` float DEFAULT NULL,
  `start_date` date DEFAULT NULL,
  `date_created` datetime DEFAULT CURRENT_TIMESTAMP,
  `last_updated` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `na` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO `test`.`test`(`id`, `name`, `age`, `weight`, `start_date`,