Hive系列-unix_timestamp 问题

问题描述

环境测试集群
服务器系统版本:centos 7.2
cdh 版本:cdh5.9.0
hadoop 版本:2.6.0+cdh5.9.0
hive 版本:1.1.0+cdh5.9.0
nodeManger 节点:cdh003,cdh004, cdh005, cdh006
HiveServer2 节点:cdh001, cdh003,cdh004, cdh005, cdh006

需求:xxx_detail_incr_表的数据根据create_time字段按天分区导入xxx_detail_incr_par_表

mongodb同步数据到hive,按天分区时调用hive函数unix_timestamp 将时间字符串create_time=Sun May 20 23:59:21 CST 2018 格式化成 create_date=2018-05-20,格式化后的字符串当分区字符串,同样的sql,有时候跑任务格式化成功,有失败。效果十分诡异。

转换SQL如下:

INSERT OVERWRITE TABLE xxx_detail_incr_par_ PARTITION (create_date) 
SELECT *,from_unixtime(unix_timestamp(create_time,'EEE MMM dd HH:mm:Ss z yyyy'),'yyyy-MM-dd') AS create_date 
FROM xxx_detail_incr_;

查看是否成功:

show partitions xxx_detail_incr_par_;

成功时候:
这里写图片描述

失败时候:
这里写图片描述


问题分析

这里用了hive的两个时间函数 from_unixtime,unix_timestamp 估计是这两个刁民在害朕。

create_time的字符串中包含特殊字符

使用hive regexp_replace 函数将不是英文、数字、空格的字符串替换掉。

INSERT OVERWRITE TABLE xxx_detail_incr_par_ PARTITION (create_date) 
SELECT *,from_unixtime(unix_timestamp(regexp_replace(regexp_replace(create_time,'[^:a-zA-Z0-9 \s]+',''),'\\s+',' '),'EEE MMM dd HH:mm:Ss z yyyy'),'yyyy-MM-dd') AS create_date 
FROM xxx_detail_incr_;

重新执行,成功了,所有的分区都有。心中窃喜! 为了稳,多次执行,第二次执行的时候失败。
不是特殊字符。。

hiveserver2 问题

只留cdh004中的hiveserver2将集群中多余的停掉。多次执行,时间字符串个格式化有成功有失败。
不是hive server2 问题??

hive 转 mr job 时候问题

只留cdh003中的nodeManger 别的停掉。多次执行,时间字符串个格式化有全部失败。
问题出现了。。
依次单独只留一个nodeManger依次校验,发现
cdh003,cdh006 的 nodeManger 有问题启动的任务有问题。
cdh004,cdh005的 nodeManger 有问题启动的任务ok。
多次验证 hiveserver2 nodeManger 、服务器任务成功与失败的关系的得出
cdh003,cdh006 的机器环境和cdh004,cdh005 环境有差异。
网上找到unix_timestamp/from_unixtime 格式化时间是调用JAVA的SimpleDateFormat时间时间格式化的。
猜测 机器的时区不一致 ,语言不一致,检查发现时区ok,语言不一致。

这里写图片描述
这里写图片描述

心中窃喜,以为联系运维改系统语言。重启集群,重跑任务,问题解决。然并卵用,问题依旧。。。。

猜想定问题是因为本地化Locale的不同导致SimpleDateFormat转换失败,于是本地做了个小实验。

本地SimpleDateFormat实验

SimpleDateFormat使用默认Locale(中文)转换”Tue May 20 22:41:01 CST 2014”,报错
这里写图片描述

SimpleDateFormat使用Locale.ENGLISH转换,ok
这里写图片描述

看到这里问题貌似出来了,估计是服务器的默认Locale值存在差异。于是乎,撸起袖子就干。

服务器SimpleDateFormat实验

分别在服务器cdh003,cdh004 执行,代码,为了确定问题,指定使用coudera用的jdk版本:

/usr/java/jdk1.7.0_67-cloudera/bin/javac -d . LanTest.java && /usr/java/jdk1.7.0_67-cloudera/bin/java LanTest

这里写图片描述

然而的出来的结果出人意料,cdh003,cdh004结果都一样!!不应该啊,不应该啊,真的不应该这样子的。。

这里写图片描述

百思不得其解,郁闷。。。

SimpleDateFormat没有设定时区是会使用默认的操作系统的locale配置
Java 官方的说明:http://www.oracle.com/us/technologies/java/locale-140624.html

github翻阅hive源码

没办法了,是能去挖坟了,默默打开github,找出hive udf 实现的源码。
源码地址:里面有hive的所有udf源码实现 我用的版本是1.1所以看了1.1分支的代码

from_unixtime 函数的实现类 UDFFromUnixTime ,截图只是重点部分截图

这里写图片描述

源码中发现from_unixtime的实现中并没有指定Locale,跟我猜想的一样,不指定Locale是正常的啦,必将全世界都在用嘛。。

再看看unix_timestamp函数的实现类 GenericUDFUnixTimeStamp ,这哥们的代码稍等惊人。
这里写图片描述

然而这里并没有任何SimpleDateFormat的身影,别慌看父GenericUDFToUnixTimeStamp,熟悉的身影

这里写图片描述

GenericUDFToUnixTimeStamp的转换不走大致可以分为2个步骤:
1、根据输入的不同类型转成不同类型的ObjectInspector

这里写图片描述

2、根据不同类型的ObjectInspector格式化字符串

这里写图片描述

源码中发现unix_timestamp的实现中并没有指定Locale,还是那就老话,必将全世界都在用嘛,不指定是正常的啦。

unix_timestamp、from_unixtime 实现中都没有指定Locale,hive 跑 mr job 时候获得的Locale值跟我在服务器上跑测试例子 LanTest.java 一样的才对,这里为什么不一样呢?无解,真的无解,有被坑过的同学可以告诉下我吗?


问题原因

跟运维沟通确认后发现,服务集群中由于不同批次上线的机器的配置略不同,有些机器装机的时候选择的默认语言是中文的,有的是英文的,后来然统一改成了英文,这样会引发java的一些默认环境有说差异。由于java 默认解析的默认Locale 存在差异,有些机器使用中文,hive 的unix_timestamp函数,使用SimpleDateFormat 格式化这样的”Sun May 20 23:59:21 CST 2018”时间字符串时会报错。
但是,机器已经改已经修改成英文的,为什么hive 跑 mr job 时候获得的Locale值还是获取到原来的中文??????无解,真的无解,有被坑过的同学可以告诉下我吗?


解决方案

终极大法 :hiveServer2,mapreduce.map.java.opts,mapreduce.reduce.java.opts 添加 -Duser.language=en 指定语言

这里写图片描述

这里写图片描述

重启服务器之言,多次校验通过,世界和平,稳稳的。。


总结

  1. 服务集群中由于不同批次上线的机器的默认语言配置略不同,引发了本次血案
  2. 建议后又的服务器机器环境尽可能相同,默认语言,时区,jdk版本 等
  3. 不要一味的想着让机器的软环境适应jvm,能用-D指定的默认值尽可能用-D指定
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值