datax 同步hive表到其他数据源的时区问题

问题描述

公司同事使用 datax 同步 hive表(parquet格式) 到 starrocks。
但是同步成功之后，发现starrocks中的etl_update_time字段 比源表的 该字段早了8小时。 源表该字段为 timestamp类型，目标表的该字段为 datetime类型

问题分析

一听到早了8小时，大概率知道，应该是impala的时区问题导致的。 于是联想到 datax的限制：由于datax hdfsreader无法读取 parquet格式表， 于是使用了 rdbmsReader，利用impala jdbc去查询hive表的数据，然后将查询结果导入 starrocks。
这里就会出现问题，因为公司impala版本 有时区漂移问题，导致如果hive表 格式为parquet，字段为timestamp，那么impala读取出来的数据，默认使用的是UTC，结果会不正确，假设本地是中国时间，即CST时区，会慢8个小时。

问题验证

建立一张parquet格式的hive表

CREATE TABLE sync2startrocks2(
id int,
name string,
etl_update_time TIMESTAMP
)PARTITIONED BY (`dt` string)
STORED AS PARQUET
;

插入两条数据:

--1
insert into table bd_sync.sync2startrocks2 partition(dt='2022-03-20') select 1, '1', current_timestamp();

--2
insert into table bd_sync.sync2startrocks2 partition(dt='2022-03-20') select 2, '2', current_timestamp();

在hive查询刚插入的数据,确认时间没有问题

1	1	2022-03-21 15:24:38.747	2022-03-20
2	2	2022-03-21 15:24:58.068	2022-03-20

切换查询引擎为impala，查询该表中的数据

SELECT id,name,etl_update_time from bd_sync.sync2startrocks2

1	1	2022-03-21 07:24:38.747000000
2	2	2022-03-21 07:24:58.068000000

可以观察到， 目标端的etl_update_time字段明显比源端的该字段要慢8小时。

• 问题得到验证，确实是由于impala的时区问题导致。

解决办法

在拼写datax配置文件时，需要将impala的查询sql进行特殊处理，如下：

select id,name,from_utc_timestamp(`etl_update_time`,'Asia/Shanghai') from bd_sync.sync2startrocks2;

1	1	2022-03-21 15:24:38.747000000
2	2	2022-03-21 15:24:58.068000000

这样的话，相当于将查询出来的结果的时区转换一下，得到原来正确的时区数据。搞定

结论

• 如果带有timestamp字段的表由Impala生成无论是文本文件还是parquet文件时，无论是由Hive查询还是Impala，均不会有时区的问题。
• 由Hive生成的带有timestamp字段的表，如果是文本格式的，无论是由Hive查询还是Impala，均不会有时区的问题。
• 由Hive生成的带有timestamp字段的表，如果是parquet格式的，由Hive查询不会有时区的问题，由Impala查询时，默认使用的是UTC时区，结果会不正确，假设你本地是中国时间，即CST时区，会慢8个小时。