错误：失败：获取锁时出错：与元存储库org.apache.hadoop.hive.ql.lockmgr.LockException进行通信时出错

Question

尝试在分区表上运行count（*）时获取Error in acquiring locks。当在<= 350个分区上过滤时，该表具有365个分区，查询工作正常。尝试包括更多分区进行查询时，失败并显示错误。

使用Hive管理的ACID表，具有以下默认值

• hive.support.concurrency = true //不能将其设置为false，它抛出<table> is missing from the ValidWriteIdList config: null，对于ACID读取和写入应为true。
• hive.lock.manager = org.apache.hadoop.hive.ql.lockmgr.zookeeper.ZooKeeperHiveLockManager
• hive.txn.manager = org.apache.hadoop.hive.ql.lockmgr.DbTxnManager
• hive.txn.strict.locking.mode = false
• hive.exec.dynamic.partition.mode = nonstrict

为这些值增加/减少值，随后进行了直线训练。

• hive.lock.numretries
• hive.unlock.numretries
• hive.lock.sleep.between.retries
• hive.metastore.batch.retrieve.max = {默认300} //更改为10000
• hive.metastore.server.max.message.size = {默认104857600} //更改为10485760000
• hive.metastore.limit.partition.request = {默认-1} //未更改，因为-1是无限的]
• hive.metastore.batch.retrieve.max = {默认300} //更改为10000。
• hive.lock.query.string.max.length = {默认10000} //更改为更高的值

使用HDI-4.0交互式查询-llap群集，默认情况下，随同提供的sql-server支持元存储。

Answer 1

我们在HDInsight中也遇到了相同的错误，在进行了许多与您所做的配置更改相似的更改之后，唯一有效的方法是扩展Hive Metastore SQL DB服务器。

我们必须将其一直扩展到具有250个DTU的P2层，以使我们的工作负载能够在没有这些锁定异常的情况下工作。如您所知，随着层和DTU数量的增加，SQL Server的IOPS和响应时间得到了改善，因此我们怀疑随着存储量的增加，Metastore的性能是导致这些锁定异常的根本原因。

以下链接提供了有关Azure中SQL Server中基于DTU的性能变化的信息。

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-dtu

另外，据我所知，当您选择在集群创建中不提供外部数据库时，将置备的默认Hive元存储只是一个S1层数据库。这将不适用于任何大容量工作负载。同时，最佳做法是始终将您的元存储库配置在集群外部并在集群置备时附加，因为这使您可以灵活地将同一个Metastore连接到多个集群（以便您的Hive层架构可以在多个集群之间共享集群，例如用于ETL的Hadoop和用于处理/机器学习的Spark），您可以完全控制随时随地扩展或缩减元存储库。

扩展默认元存储库的唯一方法是通过获得Microsoft支持。