Impala负载均衡异常处理

1

背景介绍

文档编写目的

• 记录Impala的负载均衡踩坑记录

• • Hue配置Impala的负载均衡

  • Java应用将Impala作为查询引擎

环境介绍

• CDH5.16.2

• HA-proxy实现impala的负载均衡

为什么impala需要负载均衡

最近业务系统需要使用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在集群上的分布比较均匀，问题解决。