前言
HiveThriftServer2是Spark基于HiveServer2实现的多Session管理的Thrift服务,提供对Hive的集中式管理服务。HiveThriftServer2作为Yarn上的Application,目前只支持yarn-client模式——即Driver运行在本地,ApplicationMaster运行在NodeManager所管理的Container中。yarn-client模式相较于yarn-cluster模式,在Driver和ApplicationMaster之间引入了额外的通信,因而服务的稳定性较低。
为了能够提高HiveThriftServer2的可用性,打算部署两个或者多个HiveThriftServer2实例,最终确定了选择HA的解决方案。网上有关HiveThriftServer2的HA实现,主要借助了HAProxy、Nginx等提供的反向代理和负载均衡功能实现。这种方案有个问题,那就是用户提交的执行SQL请求与HiveThriftServer2之间的连接一旦断了,反向代理服务器并不会主动将请求重定向到其他节点上,用户必须再次发出请求,这时才会与其他HiveThriftServer2建立连接。这种方案,究其根本更像是负载均衡,无法保证SQL请求不丢失、重连、Master/Slave切换等机制。
为了解决以上问题,我选择了第三种方案。
由于HiveThriftServer2本身继承自HiveServer2,所以HiveServer2自带的HA方案也能够支持HiveThriftServer2。对于HiveServer2自带的HA方案不熟悉的同学,可以百度一下,相关内容还是很多的。如果按照我的假设,就使用HiveServer2自带的HA方案的话,你会发现我的假设是错误的——HiveThriftServer2居然不支持HA。这是为什么呢?请读者务必保持平常心,我们来一起研究研究。
注意:我这里的Spark版本是1.6.0,Hive版本是1.2.1。
HiveServer2的HA分析
我从网上找到了一副能够有效展示HiveServer2的HA原理的图(具体来源无从考证)。
这幅图片很直观的为我们介绍了HiveServer2的HA架构。整个架构实际上围绕着ZooKeeper集群,利用ZooKeeper提供的创建节点、检索子节点等功能来实现。那么ZooKeeper的HA是如何实现的呢?让我们来进行源码分析吧。
HiveServer2本身是由Java语言开发,熟悉Java应用(如Tomcat、Spark的Master和Worker、Yarn的ResourceManager和NodeManager等)的同学应该知道,任何的Java应用必须要有一个main class。HiveServer2这个Thrift服务的main class就是HiveServer2类。HiveServer2的main方法如代码清单1所示。
代码清单1 HiveServer2的main方法
public static void main(String[] args) {
HiveConf.setLoadHiveServer2Config(true);
try {
ServerOptionsProcessor oproc = new ServerOptionsProcessor("hives