hive元数据全面优化详解

hive元数据库中的TBL_COL_PRIVS，TBL_PRIVS 、PART_COL_STATS表相当大，
部分特殊情况下NOTIFICATION_LOG也可能存在问题，如果集群中有关联的操作时会导致元数据库响应慢，从而影响整个Hive的性能，

统计信息表清理：
1、TAB_COL_STATS、PART_COL_STATS：在每个Hive表、分区表都有写入数据的情况下，通常来说这个表的数据量约为库表分区数*列 。
并且每当有分区更新时会写该表或者Hive启用CBO时会查询该表，如果该表数据量过大，可能会出现超时问题。

处理方案：备份后进行truncate TAB_COL_STATS、PART_COL_STATS 两个表。如果Hive中不需要启用CBO进行查询优化，
那么可以设置如下参数进行禁用：hive.stats.autogather:false (默认 true ,开启/禁用表、分区级别统计信息收集)
后续可以通过执行ANALYSE TABLE或者开启autogather在执行INSERT OVERWRITE操作时自动收集表的统计信息。

2、TBL_COL_PRIVS、TBL_PRIVS：记录了每张表、每列每个权限信息，从而允许用户直接通过SQL来查询权限信息。
当集群中的表数量和权限数量过多时会影响性能，除非表或者权限被清理则会删除这两个表关联的数据，否则这两个表可能会无限制增长。

处理方案： 备份后进行truncate TBL_COL_PRIVS、TBL_PRIVS 两个表。禁用权限同步至TBL_COL_PRIVS，TBL_PRIVS，
设置hive.privilege.synchronizer=false，hive.privilege.synchronizer.interval 参数会失效。
影响是无法使用beeline较为方便的查询到table/column的权限信息。

日志数据清理：
NOTIFICATION_LOG.ibd
TXN_WRITE_NOTIFICATION_LOG.ibd

notification_log记录的都是日志，由于存的数据太多导致访问这个表性能很低。
如果NOTIFICATION_LOG 表的最早的EVENT_TIME 时间已经超过了2天+默认2个小时间隔时间，
那么说明期间的元数据变更事件太多自动清理程序处理不过来导致，如果集群一直比较繁忙，这个数值会累积到很高的情况。
把notification_log表里的数据直接truncate掉。

调整notifcation清理周期参数：
hive.metastore.event.db.listener.timetolive: 1 （单位：天，事件生存周期，默认2天）
hive.metastore.event.db.listener.clean.interval: 1800（单位：秒，事件清理间隔周期，默认7200秒）
hive.metastore.event.db.clean.maxevents : 20000 （默认10000，周期清理最大事件数）

其他元数据优化：
1、如果不需要impala 的自动更新元数据操作可以禁用notification，取消勾选并保存重启生效即可。
2、如果有使用impala 的元数据自动更新操作，可以通过调整impala自动更新元数据的周期减少对NOTIFICATION_LOG表的查询频率来达到调优的目的，代价是impala元数据更新周期会变长。
hms_event_polling_interval_s: 30 (单位：秒，默认2秒，impala元数据更新周期)
3、Disable Hive Metastore Canary (Optional) 如果不需要Canary监控信息，可以禁用该选项，可以减少很多事件的产生。
4、hive设置“启用数据库中的存储通知”（Hive Metastore Server Default Group）会导致大量日志写入这个表导致数据很多，建议关闭。
5、ACID事务开启会导致表锁，也会增加大量notification_log记录。
查找事务表：select * from TABLE_PARAMS where PARAM_KEY=‘transactional’ and PARAM_VALUE=‘true’;
注意：关闭ACID前转事务表。