获取 Error in acquiring locks ，尝试对分区表运行count（*）时。该表有365个分区，当按<=350个分区进行筛选时，查询工作正常。当尝试为查询包含更多分区时，失败并返回错误。
使用以下默认值处理配置单元管理的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=非严格
尝试通过直线会话增加/减少以下值。
hive.lock.numretries配置单元
hive.unlock.numretries配置单元
hive.lock.sleep.between.retries配置单元
hive.metastore.batch.retrieve.max={default 300}//更改为10000
hive.metastore.server.max.message.size={default 104857600}//更改为10485760000
hive.metastore.limit.partition.request={default-1}//没有更改，因为-1是无限的
hive.metastore.batch.retrieve.max={default 300}//更改为10000。
hive.lock.query.string.max.length={default 10000}//更改为更高的值
使用hdi-4.0交互式查询llap集群，meta存储由随附的默认sqlserver支持。
1条答案
按热度按时间xnifntxz1#
我们在hdinsight中也遇到了同样的错误，在做了许多类似于您所做的配置更改之后，唯一有效的方法就是扩展我们的hivemetastoresqldb服务器。
我们必须将它扩展到一个p2层，其中包含250个dtu，这样我们的工作负载才能在没有这些锁异常的情况下工作。如您所知，随着层和dtu计数的增加，sql服务器的iops和响应时间都得到了提高，因此我们怀疑随着工作负载的增加，metastore性能是这些锁异常的根本原因。
下面的链接提供了有关azure中sql服务器中基于dtu的性能变化的信息。
https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-dtu
另外，如我所知，当您选择在集群创建中不提供外部db时，所配置的默认配置单元元存储只是s1层db。这不适合任何高容量工作负载。同时，作为一种最佳实践，始终在集群外部配置元存储，并在集群配置时附加，因为这样可以灵活地将同一元存储连接到多个集群（这样您的配置单元层架构可以在多个集群之间共享，例如hadoop for etls和spark for processing/machine learning），您可以随时根据需要完全控制metastore的大小。
扩展默认元存储区的唯一方法是让microsoft支持人员参与进来。