赞
踩
mysql和hive中的数据类型存在差异,在mysql集成数据到hive中这样的场景下,我们希望在hive中的数据是贴源的,所以在hive中希望创建和mysql结构一致的表。
mysql到hive数据类型映射参考如下:
mysql数据类型 | hive数据类型 | |
---|---|---|
整型 | bigint | BIGINT |
整型 | int | BIGINT |
整型 | smallint | BIGINT |
整型 | tinyint | BIGINT |
浮点型 | decimal | decimal |
浮点型 | double | DOUBLE |
浮点型 | float | DOUBLE |
二进制 | binary | BINARY |
二进制 | varbinary | BINARY |
字符 | char | STRING |
字符 | varchar | STRING |
字符 | mediumtext | STRING |
字符 | text | STRING |
时间 | datetime | STRING |
时间 | time | STRING |
时间 | timestamp | STRING |
时间 | date | date |
json | json | MAP<STRING,STRING> |
用公司的大数据平台(DataX)导数,已经开发上线一个多月的一批报表,突然有同事说有个报表数据不准。出在时间字段上。
分析:
1、先看了原数据MySQL字段类型为datetime,目标字段为timestamp类型;
2、经发现所有时间的差距都是8小时,怀疑是因为时区转换的原因;
3、对比其他表,看看是大范围现象还是特殊情况,发现其他的同样情况字段的一样没有问题,也有改变为string字段类型的也没有问题;
经过对比:发现DATAX(sqoop也类似)在转换MySQL datatime字段类型为hive的timestamp时会出现问题:默认先转为零食去对应时间戳,再转换为北京市区时间,就会使时间多8小时。
解决办法有两个:
1、转换为string类型;
2、继续用timestamp类型,但是需要行存储(即text存储)。
遇见时间类型转换问题时要小心,保守最好是string,简单的比较大小不会影响后续计算。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。