【hive】CDH5.13的HiveMetaStore因Sentry同步导致的慢查询锁表问题

前言

最近公司HADOOP集群突然变慢了，具体的表现为进入hive后，提交查询语句，很久之后才会提交到YARN 集群上。并且Yarn 集群资源使用比较空闲。所以并不是集群资源不足导致的。也查询了很多网上的文章，最后解决问题了。这里整理并记录下。

异常表现

当提交sql 后，进入阶段一特别慢，有时甚至卡个几分钟。并且进入第阶段二也是很慢。并且hive 的日志也有很多与 Lock 相关的报错，如NoSuckLock 或 timeout 等错。

在受影响的版本中，某些工作负载可能导致Hive Metastore（HMS）死锁。内部的自动机制可以从这种死锁中恢复。但是，在高并发且写入较重的工作负载中，HMS从死锁中恢复比查询作业的执行时间还长，于是导致HMS的性能下降或者挂起。反过来影响HiveServer2的性能，从而影响查询性能。

升级到受影响的版本后，如果工作负载的性能急剧恶化或停滞，你可能遇到了这个问题。如果你使用MySQL或MariaDB作为元数据库的话，你会在HMS中的日志看到以下错误。

com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction

适用版本

1.CDH5.13.0, 5.13.1, 5.13.2

2.CDH5.14.0

3.同时使用Hive和Sentry

解决方法一

1.升级到5.13.3或更高版本

2.升级到5.14.2或更高版本

解决方法二

如果你无法升级，为缓解此问题，请修改一下配置：

1. 进入 hive -> 配置 -> 搜索 Hive Metastore Server 高级配置代码段
   

2. 设置 hive.metastore.transactional.event.listeners 为空值

3. 设置 hive.metastore.event.listeners”为“org.apache.hive.hcatalog.listener.DbNotificationListener

4. 重启HMS服务使配置生效。

使用此解决方法的副作用可能是某些DDL查询（如删除表和使用相同名称创建的新表）失败，并显示报错“No valid privileges”。重新运行这些查询应该可以解决该问题。

如果做了上述修改后问题仍然存在，考虑升级到推荐的新版本。

参考

• https://cloud.tencent.com/developer/article/1158312
• https://docs.cloudera.com/documentation/enterprise/release-notes/topics/cdh_rn_hive_ki.html