1
背景介绍
最近业务系统需要使用Impala作为查询引擎,在使用Impala JDBC连接Impala服务时,默认是不带负载均衡的,需要指定ImpalaD的机器。指定机器的情况下会产生单点故障和负载过重的问题,因此在多用户和生产环境下对于Impala的JDBC服务需要做负载均衡。
经过对比nginx和ha-proxy最终选定使用ha-proxy实现Impala的负载均衡,下面记录遇到的两个问题。
2
Hue配置Impala负载均衡
配置完Impala的ha-proxy之后,在hue上运行Impala的查询出现异常
Results have expired, rerun the query if needed
出现这个问题的原因是Hue的基础Thrift库在连接池中重用了连接,单个用户会话可能没有相同的impala连接导致。也就是用户会话或查询可能会丢失,并触发结果过期或会话ID无效的错误。
检查ha-proxy中关于impala-jdbc的配置,发现balance选择的是leastconn,这就是导致hue上查询过期的原因。查询cloudera官方的材料后,发现要保持hue的会话,需要对haproxy的balance配置为source算法,以确保每个hue实例将所有流量发送给单个的impalaD实例。本质上,这不是一个真正的负载均衡,而是一个高可用的配置。
修改haproxy的配置文件,将impala jdbc的balance配置为source,在此在hue上运行impala的查询,故障消失。
3
Java应用将Impala作为查询引擎
最近,业务系统越来越多的大数据查询需求跑在Impala上,出现了简单查询运行时间过长的情况。
PS:mybatis可以集成Impala,注意需要定制一下分页插件
查看haproxy上的impala jdbc负载情况,发现之前为了适配hue,impala jdbc的balance算法选择了source,整个impala集群承受的负载非常不均,下面的haproxy上的负载表现。
可以看出整个查询应用的负载是非常不均的,120W个session主要集中在6台impala服务器上。
为了实现应用系统的最佳负载均衡,需要为hue客户端和非hue的客户端做ha-proxy的端口分离,配置不同的ha-proxy balance算法。Hue客户端balance选择source,非Hue客户端balance选择leastconn
重启ha-proxy,应用系统的impala查询效率有明显改善,在此查看ha-proxy上的impala jdbc使用情况,发现整个查询sessions在集群上的分布比较均匀,问题解决。