HiveServer2表结构变更太耗时分析

转至元数据结尾

• 创建： 李星，最新修改于： 十二月 23, 2016

转至元数据起始

HiveServer2启动端口为10002，可以看到大量galaxy过来的请求以及少量主数据过来的请求。

 

jstack查看HiveServer2的进程，发现有大量线程被block了。

 

发现大都是block在了org.apache.hadoop.hive.ql.Driver.compileInternal(Driver.java:1122) 这上，hive 1.2.1相应源码如下图所示。

 

可以看到Driver类的compileInternal函数中有个synchronized，并且compileMonitor变量是static的。

 

由于HiveServer2就是一个Java进程，即使多个请求过来，开启了多线程进行处理，每个线程都有一个Driver类，但这个static锁会把所有线程的Driver都锁住。也就是说，HiveServer2中使用Driver类进行compile的过程是串行的。这解释了为什么会有那么多个线程block在compileInternal函数上，再次使用jstack查看各线程状态，发现确实是有一个线程进入了同步块，其他的则在等待。

从上面的hive架构图可以看到，compiler需要从metastore获取元数据信息。经过远程调试(hive --debug)发现普通表结构变更语句的compile是非常快就完成的，但如果变更语句带了cascade后在compile时会有2个地方耗时特别长。在我的测试用例中，sem.analyze(tree, ctx);这句大概会卡5分钟，doAuthorization(sem, command);这句会卡10分钟左右。从源码来看，具体耗时会和分区数量有很大关系，doAuthorization中会检查每个分区的权限。

因此，一旦执行时遇到了某个表结构变更语句带了cascade参数，由于compile时需要较长时间，从而导致其他变更语句都需要等待其compile完成才能进行compile。

另外由于HiveServer2会每5分钟通过BeeLine进行检测，也加剧了HiveServer2的负担，同时每2小时会kill HiveServer2重启，所以等待超过2个小时的也不可能会有结果。所以，用户说新建表时也卡了非常久、变更表结构几个小时也没返回都可以解释得通。

 

总结：

HiveServer2的compile是串行的，而加上cascade关键字时会导致compile时间需要十几甚至几十分钟，compile过程成为一个非常大的瓶颈。包含了cascade的多个表结构变更语句在一段时间内一起提交时就会在compile阶段进行排队等待了。

另外，带有cascade的DDL在执行阶段肯定也会比普通的DDL更耗时，但没进行测试，不过执行DDL应该是可以并行的。

 

后续：

搜索了下发现社区似乎在Hive 2.0.0版本上新增了相关的参数用于设置是否开启并行compile。

Remove lock on compilation stage：https://issues.apache.org/jira/browse/HIVE-4239

 

patch在compileInternal函数上的主要修改就是增加了判断语句，如果是HiveServerQuery并且开启了并行compile，则不会进行加锁(patch中加锁方式从用synchronized关键字改成了ReentrantLock类)。