用公司的大数据平台(DataX)导数,已经开发上线一个多月的一批报表,突然有同事说有个报表数据不准。出在时间字段上。
分析:
1、先看了原数据MySQL字段类型为datetime,目标字段为timestamp类型;
2、经发现所有时间的差距都是8小时,怀疑是因为时区转换的原因;
3、对比其他表,看看是大范围现象还是特殊情况,发现其他的同样情况字段的一样没有问题,也有改变为string字段类型的也没有问题;
MySQL表名:test
MySQL字段类型如下:
field_name | type |
---|---|
id | int |
name | varchar |
creat_day_time | datetime |
create_day | date |
create_time | time |
create_time_stamp | timestamp |
-----测试数据如下
id name create_day_time create_day create_time create_time_stamp
1 xiaoming 2023-04-10 14:20:42 2023-04-10 14:20:42 2023-04-10 14:20:42
2 xiaohong 2023-04-21 14:21:02 2023-04-21 14:21:02 2023-04-21 14:21:02
hive中用 text 文件格式存储
hive 表名:test_text
field_name | type |
---|---|
id | int |
name | string |
creat_day_time | string |
create_day | string |
create_time | string |
create_time_stamp | string |
-----hive 表中的数据:
id name create_day_time create_day create_time create_time_stamp
1 xiaoming 2023-04-10 14:20:42 2023-04-10 14:20:42 2023-04-10 14:20:42
2 xiaohong 2023-04-21 14:21:02 2023-04-21 14:21:02 2023-04-21 14:21:02
与mysql表里面数据一致;
hive表名:test_parquet
导入hive命令:
field_name | type |
---|---|
id | int |
name | string |
creat_day_time | string |
create_day | string |
create_time | string |
create_time_stamp | string |
-----hive 表中的数据:
id name create_day_time create_day create_time create_time_stamp
1 xiaoming 1681107642000 1681056000000 22842000 1681107642000
2 xiaohong 1682058062000 1682006400000 22862000 1682058062000
结论:
1、sqoop(DataX) 导 mysql 到 hive以text文件格式存储时,mysql时间类型:datetime,date,time,timestamp 会被转成 hive 的 string 类型,值保存格式化后的时间字符串
2、sqoop(DataX) 导 mysql 到 hive以parquet(orc)l列式文件格式存储时,mysql时间类型:datetime,date,time,timestamp 会被转成 hive的相应类型,值保存时间戳
hive表存储格式为:行式存储(text)格式,hive表相应字段(mysql里面datetime字段)设置为string类型;
mysql表中字段类型是tinyint(1),同步到hive中,也会显示出布尔类型,就是true和false。
官网解释如下:
Mysql中存在tinyint(1)时,在数据导入到HDFS时,该字段默认会被转化为boolean数据类型,导致数据内容丢失(都变为NULL)。
1、可以在mysql中在建立一张表,将新建立的表修改为int类型,之后在进行同步。
2、修改sqoop的同步脚本。
解决方案:
在–connect参数后的jdbc连接上添加参数:tinyInt1isBit=false
注意:
若有多个参数,需要使用双引号将整个参数值括起来
如:–connect " jdbc:mysql://ip:3306/db?serverTimezone=Asia/Shanghai&tinyInt1isBit=false "