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在集群上的分布比较均匀，问题解决。
