timestamp字段在emr上以0.170的速度显示1970-01-01

dz6r00yl  于 2021-05-29  发布在  Hadoop
关注(0)|答案(1)|浏览(424)

我有一个外部配置单元表,指向通过s3上的spark作业编写的Parquet文件,它有日期、时间戳字段,当我通过配置单元进行查询时,我得到了正确的日期

CREATE EXTERNAL TABLE events(
event_date date, 
event_timestamp timestamp, 
event_name string, 
event_category string
PARTITIONED BY ( 
dateid  int, 
STORED AS PARQUET
LOCATION 's3a://somebucket/events'

hive> SELECT event_timestamp, event_date from events limit 10; 
2017-01-02 13:40:23 2017-01-02
2017-01-02 13:40:23.013 2017-01-02
2017-01-02 13:40:23.419 2017-01-02
2017-01-02 18:51:57.637 2017-01-02
2017-01-02 18:52:03.512 2017-01-02
2017-01-02 18:52:03.769 2017-01-02
2017-01-02 18:52:30.945 2017-01-02
2017-01-02 18:52:32.757 2017-01-02
2017-01-02 18:52:37.083 2017-01-02
2017-01-02 18:52:38.099 2017-01-02

然而,当我通过运行在emr集群版本(emr-5.6.0)上的presto(版本0.170)运行它时,我看到所有日期都是1970-01-01

presto-cli --catalog hive --schema default
presto:default> SELECT event_timestamp, event_date from events limit 10; 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01 
 1970-01-01 00:00:17.197 | 1970-01-01

在通过presto查询parquet的配置单元中,时间戳字段是否存在任何未解决的问题?

4uqofj5v

4uqofj5v1#

经过所有的网上调查,我没有得到任何进展,我做了比较,在Parquet文件和Hiveddl语句领域的顺序,似乎在Spark工作发展的顺序领域得到了改变。虽然hive可以通过名称读取列,但presto是按顺序进行的。因此,一个愚蠢的错误导致了一场白费力气的追逐。不管怎样,无耻地回答我自己的问题在这里结束线程。

相关问题