2016-06-16 4 views
0

Я получаю некоторые нечетные результаты от HIVE при работе с датами.HIVE возвращает неверную дату

Для начала, я использую улей 1.2.1000.2.4.0.0-169

Я таблица определена (пропущено) из рода:

hive> DESCRIBE proto_hourly; 
OK          
elem     string          
protocol    string          
count     bigint 
date_val    date           
hour_id     tinyint         

# Partition Information   
# col_name    data_type    comment    

date_val    date           
hour_id     tinyint          
Time taken: 0.336 seconds, Fetched: xx row(s) 
hive> 

Ok поэтому у меня есть данные, загруженные за текущий год. Я начал замечать некоторые «странности» в запросах с конкретными датами, но для острого примера, вот довольно простой запрос, где я просто прошу «2016-06-01», но я вернусь «2016-05-31». .why

hive> SET i="2016-06-01"; 
hive> with uniq_dates AS (
    >  SELECT DISTINCT date_val as date_val 
    >  FROM proto_hourly 
    >  WHERE date_val = date(${hiveconf:i})) 
    > select * from uniq_dates; 
Query ID = hive_20160616154318_a75b3343-a2fe-41a5-b02a-d9cda8695c91 
Total jobs = 1 
Launching Job 1 out of 1 


Status: Running (Executing on YARN cluster with App id application_1465936275203_0023) 

-------------------------------------------------------------------------------- 
     VERTICES  STATUS TOTAL COMPLETED RUNNING PENDING FAILED KILLED 
-------------------------------------------------------------------------------- 
Map 1 .......... SUCCEEDED  1   1  0  0  0  0 
Reducer 2 ...... SUCCEEDED  1   1  0  0  0  0 
-------------------------------------------------------------------------------- 
VERTICES: 02/02 [==========================>>] 100% ELAPSED TIME: 3.63 s  
-------------------------------------------------------------------------------- 
OK 
2016-05-31 
Time taken: 6.738 seconds, Fetched: 1 row(s) 
hive> 

ответ

1

Тестирование этого немного больше, я обнаружил, что в кластере был настроен другой сервер в другом часовом поясе. Два из трех узлов были UTC, но один узел все еще находился в Америке/Денвере.

Я считаю, что происходит то, что работа Map/Reduce выполнялась на сервере в разных часовых поясах, что давало мне странную проблему смещения данных.

Дата 2016-06-01 UTC делает действительно равны Дата 2016-05-31 Америка/Денвер

Бесшумный TZ преобразования ...