记一次hive drop table 卡死的事故

最新推荐文章于 2025-05-20 16:13:04 发布

原创最新推荐文章于 2025-05-20 16:13:04 发布 · 3.6k 阅读

5 ·

CC 4.0 BY-SA版权

文章标签：

#hive

CDH 专栏收录该内容

8 篇文章

订阅专栏

本文详细记录了一次Hive Metastore连接缓慢及表无法删除的问题，问题根源在于中文分区字段导致元数据异常。通过删除特定元数据记录，成功解决了问题，并恢复正常服务。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

事故总述

这次事故是可以避免的，责任在于Hive的管理团队未把hive的使用规范告知使用者。

现象

A同事在测试程序时，首先发现Hive-metastore的连接非常缓慢。
B同事在测试程序时，在HUE发现有一个表drop不掉（卡死，直到timeout）。
查询资料发现：https://blog.youkuaiyun.com/u010689354/article/details/79844513 论述要改字符集，但是我们比较特殊：
1.之前使用均正常
2. 系统有将近140TB数据，不可能直接drop元数据。

排查

但是，按照字符编码这个思路排查下去，我们直接看mysql的元数据，

1在TBLS表中根据表名字找到TBL_ID

根据drop不掉的表格的名字，找到TBL_ID

2在PARTITIONS表格中根据TBL_ID找到分区信息PART_ID

在PARTITIONS表格中，发现了下图的样子：
在这里插入图片描述
可以看出PART_ID为359201的分区是有问题的，根据与B同事的对话，可以确定，此次metastore的问题大致上是由中文分区字段造成。

修复

在如下的表：PARTITION_PARAMS，PARTITION_KEY_VALS删除分区字段（根据PART_ID检索）
在如下的表：PARTITIONS删除分区（根据PART_ID检索）
在如下的表：TBLS中删除表格（根据上一个表的TBL_ID检索）【这一步可以不做，使用”drop表“更好】

测试

A同事反应：hive-metastore连接正常
B同事反应：此表格删除正常

连接数正常：（如下 60不多）

十一月 20, 2018 5:29:08 下午 base.config.HiveStatus getNumsHiveNode
警告: node=192.168.1.190,port1#num1=9083#60,port2#num2=10000#4
十一月 20, 2018 5:29:18 下午 base.config.HiveStatus getNumsHiveNode
警告: node=192.168.1.191,port1#num1=9083#11,port2#num2=10000#20
十一月 20, 2018 5:29:18 下午 base.config.HiveStatus getHiveNodesStatus
信息: bestHiveNode:192.168.1.191

防范

这次是因为一个表格生成的脚本，使得分区为中文，因此让使用者加上，加强过滤【至少保护hive】

flag=`echo ${project_name} | awk '{if($0~/^([0-9a-zA-Z])+$/) print $0}'`
if [ -z ${flag} ]; then
    echo "[ERROR]the input project_name ${project_name} is incorrect, please check it. "
    exit 1
fi