前言

大家好，我是明哥!

本片博文是，大数据问题排查系列，之一，讲述某HIVE SQL 作业因为 HIVE 中的元数据与 HDFS中实际的数据不一致引起的一个问题的排查和修复。

以下是正文。

问题现象

客户端报错如下:

Unabletomovesourcexxxtodestinationxxx

客户端报错

问题分析

客户端的报错信息，并没有完全展现问题背后的全貌。我们进入 hiveserver2 所在节点查看hiveserver2的日志，可以看到如下相关信息:

从以上信息可以看到，hivesql 使用的是spark执行引擎，且 spark 作业已经执行成功了，但是在hiveser2做收尾工作时，移动临时文件到目标目录下时报错了，最底层的报错信息是 rename for src path xxx to dest path xxx returned false.

顺藤摸瓜，接下来去 hdfs 上查看问题。通过 hdfs dfs —ls 发现 hdfs上目标文件已经存在了，且通过时间信息可以发现该文件是几天前创建的，跟当前sql作业的执行没有关系:

hdfs—destination—path

问题原因

通过上述排查分析，问题直接原因已经清晰:hive sql 底层的spark作业已经执行成功，对应的数据已经计算完毕，但在移动临时结果文件到最终目标目录时，因为hdfs上最终目标目录已经存在且目标目录下存在同名文件，rename操作无法完成，作业执行失败。

回头看下我们的 sql，其本质就是个对分区表某个分区的 insert overwrite， 照道理来说，应该会覆盖目标分区对应的目录下的数据文件，但为什么这里没有执行删除动作呢。

这其实是因为该分区表在 HIVE 中的元数据与 HDFS 中的数据不一致。通过 show create table 和 show partitions 可以发现，在HIVE元数据中该分区表只有一个分区，但HDFS上存在该表其它分区对应的目录和文件:

show create table

show partitions

所以问题的根本原因是:该分区表在 HIVE中的元数据与HDFS上实际的数据不一致，当执行 insert overwrite 操作时，hive 通过存储在 metastore 中的元数据信息发现目标分区并不存在，也就不会尝试去执行hdfs上该分区对应目录的删除操作了，而实际上hdfs上该分区对应的目录和文件都是存在的，所以作业底层的 rename 操作失败了。

问题解决

知道了问题的直接原因和根本原因，解决方法也就顺理成章了:修复 hive 元数据跟hdfs实际的数据一致即可。

可以使用命令 msck repair table xxx来修复hive表的元数据:

元数据修复完毕，通过show partitions xx 发现，hive中已经可以查到原来遗失的分区然后重新执行上述 insert overwrite 语句，作业成功执行

问题总结 当 HIVE 中的元数据与 HDFS 上实际的数据不一致时，一些正常的 HIVE SQL 操作可能会执行失败 HIVE 中的元数据与 HDFS 上实际的数据不一致的原因有很多，常见的有: 使用了 HIVE 外表，由于外表的特性，在HIVE 中删除外表或外表的某些分区时， HDFS上对应的目录和文件仍会存在，此时就会造成不一致， HIVE 的元数据和底层HDFS的数据是从其他集群同步过来的，但同步过程中有问题，比如时间没对齐状态不一致， HIVE中的元数据或HDFS上的数据有损坏和丢失

声明：本网转发此文章，旨在为读者提供更多信息资讯，所涉内容不构成投资、消费建议。文章事实如有疑问，请与有关方核实，文章观点非本网观点，仅供读者参考。