hive在E-MapReduce集群的实践(一)hive异常排查入门

727 阅读5分钟
原文链接: click.aliyun.com

hive是hadoop集群最常用的数据分析工具,只要运行sql就可以分析海量数据。初学者在使用hive时,经常会遇到各种问题,不知道该怎么解决。

本文是hive实践系列的第一篇,以E-MapReduce集群环境为例,介绍常见的hive执行异常,定位和解决方法,以及hive日志查看方法。

除作者本人的知乎专栏外,其他转载需要先联系我。


一.常见异常表现

主要是执行hive sql时卡住,提示异常信息。

如执行sql时直接提示异常信息,执行sql时卡住,显示mapreduce进度一直0%,mapreduce进度长时间不变化,执行一半提示异常退出,等等。


二.异常定位和解决

2.1.执行sql直接提示异常信息

一般是语法问题,资源问题或hive服务异常。

2.1.1 语法解析错误

sql写的有问题。如ParseException


hive> show table;

FAILED: ParseException line 1:10 mismatched input '<EOF>' expecting EXTENDED near 'table' in show statement

提示table语法错误,正确的是show tables。遇到查阅hive语法确定正确写法。

hive> select * from test;
FAILED: SemanticException [Error 10001]: Line 1:14 Table not found 'test'
表test不存在。检查表名是否拼写错误,大小写是否正确,等等。

2.1.2.MetaException

一般是metastore有问题。如

hive> show tables;
FAILED: SemanticException MetaException(message:Could not connect to meta store using any of the URIs provided. Most recent failure: org.apache.thrift.transport.TTransportException: java.net.ConnectException: Connection refused (Connection refused)

连不上metastore,说明metastore服务有问题,如oom,被操作系统kill,等。先检查metastore进程是否存在,看进程启动时间是否有重启。再来看metastore的日志,是否有oom,操作系统kill。查看metastore日志的方式第三章介绍。

如果有oom,一般需要配大metastore的内存。如果有被操作系统kill,说明机器使用的总内存比物理内存大了,要么升级机器配置,要么合理规划主节点内存,尤其是要注意限制在主节点上提交作业的进程数,避免占用过多内存。

2.2.执行卡住

要看hive日志分析原因,一般是hive客户端遇到某种可重试异常一直在重试,未返回异常信息。

有一次遇到,查看hive客户端日志,反复有报错说不能识别一个机器域名。确定问题是因为使用的hive on tez,hive client要通过【集群内域名:端口】来访问tez作业的appmaster,而执行hive命令的服务器没有配置集群内域名的解析,所以无法识别该域名。在/etc/hosts下增加域名配置,拷贝主节点的/etc/hosts域名配置,解决了该问题。


2.3.mapreduce进度一直0%

一般是集群或者作业所属的yarn资源池队列没有资源,导致作业状态一直pending。

可以打开yarn ui,默认是主节点的8088端口(EMR控制台可以在开源组件快捷入口进入),查看该hive作业是不是一直在pending。

pending首先确定是否配置了yarn资源池,资源池配置有无问题,如配置的资源太少,运行的作业太多。如有问题要修改资源池配置,根据配置修改情况刷新资源队列或重启resourcemanager。

如果排除了资源池问题,还有可能是运行的hadoop作业太多,那么要等待其他作业完成释放资源,或者直接杀掉其他不重要的作业。


2.4. 所有job的mapreduce进度长时间不变化

极有可能有死锁。常见场景是集群或yarn资源池队列资源有限,同时运行了好多作业job。各作业appmaster,提前启动的reduce用光了资源,没资源继续启动map了,于是死锁。

解决方案是避免reduce提前启动占用资源,设置reduce在map都执行完后再启动。修改maped-site.xml的mapreduce.job.reduce.slowstart.completedmaps参数,改为0.98,或者1,杀掉所有作业重新执行。这样只有98%或100%的map都执行完,才会启动reduce进程。

要注意修改该参数会延长单个job的运行总时间,只有同时运行很多job,瞬时资源需要远大于集群/资源队列规模,才有必要调整该参数。


2.5. 执行一半异常退出

常见map/reduce oom。

查看job client运行日志,并用yarn ui查看sql任务的map,reduce task日志,是否有oom信息。如果有,根据实际需要,调大内存。可以在执行的sql前,通过set mapreduce.map.memory.mb =4096;(该数值仅为举例,以实际需要来确定)修改map,set mapreduce.reduce.memory.mb = 4096;修改reduce的内存来避免oom。

还有其他一些造成oom的原因和解决办法,下篇文章再来介绍。



三.hive日志位置

近期的版本更新会支持在EMR控制台上查看各服务的日志,敬请期待。当前可以登录集群查看hive的日志。

服务进程日志

hive日志默认是 /tmp/[user]/hive.log,由于tmp目录机器重启后会清空,所以在EMR集群里,hiveserver和metastore进程在启动时配置了额外的日志参数,日志输出在/var/log/hive/目录,分别为hiveserver2.log和metastore.log。每天会滚动生成一个带日期的新文件,最多保留30天。

服务进程日志一般用来调查异常日志信息,是否有oom,操作系统kill,元数据访问错误,等等。


作业运行日志

运行hive的client日志依然在 /tmp/[user]/hive.log里,例如用root用户运行sql,日志会在/tmp/root/hive.log文件里。

hive job的mapreduce task跟其他hadoop job的mapreduce task一样,日志分散在集群的各个节点上,可以通过yarn ui点击job信息跳转查看。