您的位置:首页 > 运维架构 > Apache

Hive出现异常 FAILED: Error In Metadata: Java.Lang.RuntimeException: Unable To Instantiate Org.Apache.Had

2015-10-04 08:55 1001 查看
在公司的虚拟机上运行hive计算,因为要计算的数据量较大,频繁,导致了服务器负载过高,mysql也出现无法连接的问题,最后虚拟机出现The remote system refused the connection.重启虚拟机后,进入hive。

hive> show tables;

出现了下面的问题:

FAILED: Error in metadata: java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.metastore.HiveMetaStoreClient

FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask

FAILED: Error in metadata: java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.metastore.HiveMetaStoreClientFAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask

网上查找解决的办法:

看到有一些别人说明的原因,如:mysql的权限不够。修改数据库用户权限,或者hive/bin目录权限。还有告诉要在hadoop bin/hadoop namenode -format目录的(这个办法很扯,自己去查看一下hadoop fs -ls /,hadoop运行正常)。还有说要情况/tmp目录的。这些办法都不是真正解决问题的办法。

用下面的命令,重新启动hive

./hive -hiveconf hive.root.logger=DEBUG,console

hive> show tables;

能够看到更深层次的原因的是:

Caused by: java.lang.reflect.InvocationTargetException

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at org.apache.hadoop.hive.metastore.MetaStoreUtils.newInstance(MetaStoreUtils.java:1076)

… 23 more

Caused by: javax.jdo.JDODataStoreException: Exception thrown obtaining schema column information from datastore

NestedThrowables:

com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table ‘hive.DELETEME1370713761025′ doesn’t exist

根据提示的信息,登陆mysql或者mysql客户端查看hive的数据库的表信息

mysql -u root -p

mysql> use hive;

mysql> show tables;

+—————————+

| Tables_in_hive |

+—————————+

| BUCKETING_COLS |

| CDS |

| COLUMNS_V2 |

| DATABASE_PARAMS |

| DBS |

| DELETEME1370677637267 |

| DELETEME1370712928271 |

| DELETEME1370713342355 |

| DELETEME1370713589772 |

| DELETEME1370713761025 |

| DELETEME1370713792915 |

| IDXS |

| INDEX_PARAMS |

| PARTITIONS |

| PARTITION_KEYS |

| PARTITION_KEY_VALS |

| PARTITION_PARAMS |

| PART_COL_PRIVS |

| PART_COL_STATS |

| PART_PRIVS |

| SDS |

| SD_PARAMS |

| SEQUENCE_TABLE |

| SERDES |

| SERDE_PARAMS |

| SKEWED_COL_NAMES |

| SKEWED_COL_VALUE_LOC_MAP |

| SKEWED_STRING_LIST |

| SKEWED_STRING_LIST_VALUES |

| SKEWED_VALUES |

| SORT_COLS |

| TABLE_PARAMS |

| TAB_COL_STATS |

| TBLS |

| TBL_COL_PRIVS |

| TBL_PRIVS |

+—————————+

36 rows in set (0.00 sec)

能够看到“DELETEME1370713792915”这个表,问题明确了,由于计算的压力过大,服务器停止响应,mysql也停止了响应,mysql进程被异常终止,在运行中的mysql表数据异常,hive的元数据表异常。

解决问题的办法有两个:

1. 直接在mysql中drop 异常提示中的table;

mysql>drop table DELETEME1370713761025;

2. 保守的做法,根据DELETEME*表的结构,创建不存在的表

CREATE TABLE `DELETEME1370713792915` ( `UNUSED` int(11) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

通过实践,第一个方法就能够解决问题,如果不行可以尝试第二个方法。

总结:hive、hadoop的上层异常原因可能很多情况导致,一定要找到真正的问题原因,不能急于尝试网上异常的解决办法。hive的元数据依赖关系型数据库,一定做好数据库的备份

又碰到一个hive的Exception,Caused by: org.apache.hadoop.hive.ql.parse.SemanticException: Unable to fetch table XXX,追溯更直接的原因,找到Caused by: java.sql.SQLException: Got error 28 from storage engine。

问题原因:服务器的根目录的/tmp中日志文件生成过多,磁盘空间满了。以SemanticException: Unable to fetch table关键字在google中搜索,发现结果很少,也没什么有价值的信息,搜索结果是这种情况,说明这个问题不常见,很可能是其他低级错误导致的问题。
标签:
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: