hive Couldn‘t acquire the DB log notification lock because we reache

Couldn’t acquire the DB log notification lock because we reached the maximu

背景

集群遇到了个问题，Hadoop 3版本的，有20个5分钟级任务，一个分钟级任务，这些任务都会创建分钟分区，现在在创建分区的时候卡那，看元数据库是锁那了，有什么解决办法，重试hiveserver2，开始好事一会又不行了，这些任务也没做啥复杂处理，就是先判断有没有分区，没有就建分区，然后再执行文件拷贝到分区目录下

sql脚本

为了防止重复分区，先drop再add

alter table hi_cloudjnt.int_loc_sigvolte_calling_hang_up_min drop if exists partition {date_no_=${batchNo?substnng(0,8)},hour_no_=${batchNo?substnng(0,10)},minute_no_=${batchNo?substring(0,12)});
alter table hi_cloudjnt.int_loc_sigvolte_calling_hang_up_min add if not exists partition (date_no_=${batchNo?substnng(0,8)},hour_no_=${batchNo?substnng(0,10)},minute_no_=${batchNo?substring(0,12)});

报错

查看hive报错
Hive DDL 间歇性失败并出现错误 - 无法获取数据库日志通知锁，因为我们达到了最大重试次数：10 次重试

2022-04-19 04:36:27 [pool-1-thread-2] [ERROR] Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. MetaException(message:Couldn't acquire the DB log notification lock because we reached the maximum # of retries: 10 retries. If this happens too often, then is recommended to increase the maximum number of retries on the hive.notification.sequence.lock.max.retries configuration :: Error executing SQL query "select "NEXT_EVENT_ID" from "NOTIFICATION_SEQUENCE" for update".)

解决

看来，该集群中的元存储操作很慢，因此并发写入/DDL 操作无法锁定行以进行更新。
目前，重试之间的睡眠间隔是通过配置hive.notification.sequence.lock.retry.sleep.interval指定的。默认值是 500 毫秒，这似乎太小了。我们可以为睡眠间隔和重试次数设置更高的值吗？

hive.notification.sequence.lock.retry.sleep.interval=10s

hive.notification.sequence.lock.max.retries=10
修改hive.notification.sequence.lock.retry.sleep.interval=改成10s
之前是
hive.notification.sequence.lock.retry.sleep.interval=500ms

参考

问题描述

Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. MetaException(message:Couldn't acquire the DB log notification lock because we reached the maximum # of retries: 5 retries. If this happens too often, then is recommended to increase the maximum number of retries on the hive.notification.sequence.lock.max.retries configuration :: Error executing SQL query "select "NEXT_EVENT_ID" from "NOTIFICATION_SEQUENCE" for update".)
2018-08-28 01:17:56,808|INFO|MainThread|machine.py:183 - run()||GUID=94e6ff4d-5db8-45eb-8654-76f546e7f0b3|java.sql.SQLException: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. MetaException(message:Couldn't acquire the DB log notification lock because we reached the maximum # of retries: 5 retries. If this happens too often, then is recommended to increase the maximum number of retries on the hive.notification.sequence.lock.max.retries configuration :: Error executing SQL query "select "NEXT_EVENT_ID" from "NOTIFICATION_SEQUENCE" for update".)

后续

背景

修改后，现在metastore 重启后5、6分钟就开始卡 。然后我们任务就跑不动了 。

原因分析

自动管理分区

您可以发现分区更改并自动同步Hive元数据。与手动执行相反，自动执行同步可以节省大量时间，尤其是在分区数据（例如日志）频繁更改时。您还可以配置将分区数据和元数据保留多长时间。

创建分区表后，Hive不会更新有关您添加或删除的文件系统上相应对象或目录的元数据。添加或删除相应的对象/目录后，Hive元存储中的分区元数据变得陈旧。您需要同步元存储和文件系统。

您可以手动或自动刷新Hive Metastore分区信息。

• 手动

您运行MSCK（元存储一致性检查）Hive命令： MSCK REPAIR TABLE table_name SYNC PARTITIONS每次需要将分区与文件系统同步时。

• 自动

您将分区发现设置为定期发生。

discover.partitions表属性是自动创建的，并已为外部分区表启用。当discover.partitions 对一个表被启用，蜂巢如下执行自动刷新：

• 将文件系统中但不在metastore中的相应分区添加到metastore。

• 如果您从文件系统中删除了相应的分区，则从元存储中删除分区架构信息。

您可以配置保留分区元数据和数据多长时间，并在保留期限过后将其删除。

局限性

通常，不建议在托管表上使用分区发现和保留。Hive元存储在表上获取排他锁，从而启用分区发现，这会减慢其他查询的速度。

自动进行分区发现和修复

Hive可以自动并定期发现Hive元存储中分区元数据中以及文件系统上相应目录或对象中的差异。发现差异后，Hive执行同步。自动分区发现对于处理Spark和Hive目录中的日志数据以及其他数据很有用。

该discover.partitions表属性启用或禁用并与分区的文件系统同步。在外部分区表中，创建表时默认情况下启用此属性（true）。对于旧版外部表（使用不支持此功能的Hive版本创建），您需要添加discover.partitions到表属性中以启用分区发现。

默认情况下，分区的发现和同步每5分钟进行一次，但是您可以按照此任务中所示配置频率。

启用压缩（请参见下面的链接）作为解决以下已知问题的解决方法：除非启用压缩，否则发现不会开始。

1.假设您使用不支持分区发现的Hive版本创建了一个外部表，请对该表启用分区发现。

ALTER TABLE exttbl SET TBLPROPERTIES ('discover.partitions' = 'true');

复制

2. 将分区同步设置为每10分钟发生一次，以秒为单位：设置metastore.partition.management.task.frequency为600。

ALTER TABLE exttbl SET TBLPROPERTIES ('metastore.partition.management.task.frequency' = 600

discover.partitions参数设置为true了，导致我drop分区后，内容没有被删除，分区有自动发现了，造成锁表

解决

第一种关闭自动分区发现（不推荐）

ALTER TABLE exttbl SET TBLPROPERTIES ('discover.partitions' = 'false');

第二种 修改external.table.purge

external.table.purge这个参数建表的时候设成true,加了这个删分区就文件了。

ALTER TABLE exttbl SET TBLPROPERTIES ('external.table.purge' = 'true');

删除外部表数据

当您在外部表上运行 DROP TABLE 时，默认情况下 Hive 仅删除元数据（模式）。如果您希望 DROP TABLE 命令也删除外部表中的实际数据，就像 DROP TABLE 对托管表所做的那样，您需要相应地配置表属性。

1. 创建要在 Hive 中查询的数据的 CSV 文件。

2. 启动蜂巢。

3. 创建一个外部表来存储 CSV 数据，配置该表以便您可以将其与数据一起删除。

   CREATE EXTERNAL TABLE IF NOT EXISTS names_text(
     a INT, b STRING)
     ROW FORMAT DELIMITED
     FIELDS TERMINATED BY ','
     STORED AS TEXTFILE
     LOCATION '<file system>://andrena'
     TBLPROPERTIES ('external.table.purge'='true');          
   

4. 在外部表上运行 DROP TABLE。

   DROP TABLE names_text;
   

   该表从 Hive Metastore 中删除，数据存储在外部。例如，names_text从 Hive Metastore 中删除，并且存储数据的 CSV 文件也从文件系统中删除。

5. 防止外部表中的数据被 DROP TABLE 语句删除。

   ALTER TABLE addresses_text SET TBLPROPERTIES ('external.table.purge'='false');
   

参考

管理分区
删除外部表数据