Impala/Doris链接多的时候会慢？一个实用简单配置能提速！

有些小伙伴就疑问了，已经是分布式数据库了，已经是MMP了，怎么还需要做负载均衡吗？我的答案是需要的，至少是JDBC或者调用客户端的时候使用，文后有个人理解。

“每一个产品，不论它吹得多牛B，想要用好都是要不断做调优的。”——鲁 ...闲哥。

 一、现象和分析：

某天下午小伙伴反报表应用打开很慢，想都没想一定是DB资源的问题了，具体就是BI工具直连impala有问题。（小小说明下我们大部分报表连的impala，DorisDB还不够稳定没大部分切换）。

1、impala查询都集中在某台机。（集中在某台机子提交查询，CDH的＞ｉｍｐａｌａ管理界面）

2、原因分析

报表工具数据源只配置了一个节点直连Impala，报表所有的提交语句压力都在那个直连的节点上。

二、解决思路和方案 （也能应用到其他类似的DorisDB等）

将其他节点也加进来（impala Deamon角色），将21050端口（impala JDBC)做个负载均衡。Impala Deamon是提交查询及调度及执行角色。文末有架构图。

三、具体安装和配置步骤

有了方案和思路，就是找合适的工具和安装了，这里推荐Haproxy代理，也是Cloudera推荐的负载均衡工具。

1、找一台非Deamon节点的机子，安装Haproxy代理 。（Cloudera推荐的平衡工具）

2、修改配置文件和启动任务

加２个负载：

21000端口，是impala-shell的端口；

21050是impala jdbc的工具。

# yun install haproxy -y


# 配置文件


vim etc/haproxy/haproxy.cfg
# 配置内容 for impala
listen status#定义管理界⾯
bind 0.0.0.0:1080#管理界⾯访问IP和端⼝
mode http#管理界⾯所使⽤的协议
option httplog
maxconn 5000#最⼤连接数
stats refresh 30s#30秒⾃动刷新
stats uri stats
listen impalashell
bind 0.0.0.0:25003#ha作为proxy所绑定的IP和端⼝
mode tcp#以4层⽅式代理，重要
option tcplog
balance roundrobin#调度算法 'leastconn' 最少连接数分配，或者 'roundrobin'，轮询分
server impalashell_1 w02:21000 check
server impalashell_2 w04:21000 check
server impalashell_3 w05:21000 check
listen impalajdbc
bind 0.0.0.0:25004#ha作为proxy所绑定的IP和端⼝
mode tcp#以4层⽅式代理，重要
option tcplog
balance roundrobin #调度算法 'leastconn' 最少连接数分配，或者 'roundrobin'，轮询分
server impalajdbc_1 w02:21050 check
server impalajdbc_2 w04:21050 check
server impalajdbc_3 w05:21050 check
# 启动任务 


开启：service haproxy start
关闭：service haproxy stop
重启：service haproxy restart

4、测试是否生效

1）可以访问管理界面，查看代理情况：

http://w03:1080 

2）测试在03打开impala-shell，看是否生效：

impala-shell -u hive -i w03:25003 

发现Coordinator: http://w04:2500 是在04上调度。

换另外一个节点测试impala-shell，调度在另外一台了，Coordinator: http://w02:25000 是在02上调度。已生效。

四、最后结合impala架构，和Haproxy 代理简图，说下为什么会有效。

1、 Impala架构 

impala在哪个节点提交查询，会在这节点上启动查询调度器（QueryCoordinator），会和另外的工作节点（查询执行器Query Executor）有数据交互。会占用一些资源（内存）等。所以所有的查询都提交到同一台时，会有压力。这里也类似其他MPP架构用这方法也能解决单一节点链接瓶颈问题（有一些连接工具会带自动负载均衡可忽略）。别以为分布式就能无脑连了。

2、 Haproxy代理

简单画了一个，结合配置的内容不难理解。

‍