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信息跳转查看。