主要为了解决3.x+用户对某个表进行drop，rename，或者swap后权限丢失而开发的一个小工具（因为目前还没有继承apache ranger授权）。实现的功能主要是针对内表。当发现上面三种行为后，重新拾起权限。下面跟各位大牛们分享一下我的处理方式。
我们有些用户是这样用的：
（慎用）1.alter table a rename b
（慎用）2.create table a
（慎用）3.insert a select b
（慎用）4.drop b
这样就会导致其他用户本来有权限访问这个表的，后来变成没有权限了。
正确的顺序应该是：
（建议）1.create table c
（建议）2.insert c select a
（建议）3.alter table a rename b
（建议）4.alter table c rename a
（建议）5.drop table b
但是异常行为依旧无法杜绝。
rename也是，先rename了原表，然后再rename多次导致权限丢失。
开发思路：
0.备份原有的权限（权限表）
1.落地现有的SQL行为（审计表）
2.解析异常DDL语句拿到表名
3.根据表名去权限表里面匹配，将对该表有权限的语句全部拉出来，重新授权。
一、权限备份：
先实现一个很简单的策略，基本上就是把集群里面所有的用户权限都拿出来，并使用stream load把数据怼到一个表中，作为每天的权限备份。
数据大概就长这样已经满足需求了。
二、行为逻辑：
毕竟要发现每个用户是否提交过删表，重命名，原子替换这些操作，必须得有一个记录搜索才行。但是如果要跑去解析fe得audit就有点繁琐了。这下就可以使用官方得 AuditLoader去继承一个审计表。下面是我们得行为结构，拿的就是官方得结构，我们的数据行为较大。
这下权限表和审计表都有了。那么下一步编写工具
三、开发工具/脚本
逻辑：因为审计日志是1分钟更新一次。那么就可以每1分钟拿前3分钟的行为记录，然后解析SQL语句是否存在drop，rename，或者swap
如果存在，ok，解析这个语句拿到表名，并从权限表中查询是否有该表的记录。如果有，那么授权。
授权完成后，发出飞书群通知。
无论是drop表，重命名，还是原子替换，都给它授予一遍权限，并发出授予了谁谁，哪个表，等。
程序日志：
直接感知哪个queryid是操作了删表操作，支持配置多个集群。目前我们管理的是6个3.2+3.3的集群。