impala学习sql优化之summary(实战分析)

impala查询优化和explain学习_cclovezbf的博客-CSDN博客

接着上篇学了一点explain。接着学习summary。

学了explain 我们获得了哪些信息

explain
select count(1)
from 
odserpjdata_kd.gl_code_combinations  gcc ,
odserpjdata_kd.gl_balances  gb 
where gb.code_combination_id =gcc.code_combination_id 

gcc  =11005694 

gb   =107250223

count(1)=32973207

show table  stats  odserpjdata_kd.gl_code_combinations --399.65MB
show table  stats  odserpjdata_kd.gl_balances -- 6.62GB 

这两个表都是kudu表。。。没用hive。  

join的方式，内存的预估(说实话这个我还没看懂)，表是否统计过信息

还有一些row-size  cardinalty 也是不是特别懂，对于优化来说好像缺了点意思。

所以我们要学习一个summary。

在我们执行完一个sql后，执行summary。(在dbeaver好像不能执行。)

可以看到出来一个表格，简洁直观，我们来分析一下。

1.左侧Operator 就是执行操作 还是熟悉的scan exchange aggregate 不用看假装会

2.第二行 host 看了下 1 和10，1代表的是在一台机器上完成，10代表的是分布式，

   以这个sql为例，广播gb表到10个hosts上，基于内存在于gcc join。

3.instance 感觉和host一样 不看

4. 5就是花费时间，我们看下 主要的花费时间在 00scan kudu 1.64s 和02 hash join 11s

      可以从这方面优化。

6.rows 这个是该阶段处理的条数。 例如

gcc  =11005694  00 scan kudu(gcc)=11.01M

gb   =107250223  01 scan kudu(gb)=107.25M 

count(1)=32973207 02 hash join=32.97M

有没有发现哪里有点相似呢？ 其实就是行数...

由此我们看到 03 aggregate =10 其实就是每台机器最后的聚合结果。

比如 cdp1->300w ,cdp2 ->340w ...cdp9->320w 这十条结果

然后05 exchange 这十条结果交换到一起， 06 在聚合就是300+340+....320=32973207

7. 1 -1 我也看不出是啥

8 9 peak mem 是峰值内存， est是估计峰值内存 est是estimate

注意看impala的summary 这里不一定准，他预估的是2G实际是8.87G 和我在cm里看到基本吻合。

我们再回过头来看explain，这里有个2.02 ≈2G 也吻合，同时说明了这个没啥卵用。

 10 detail 也没啥好说的了。所以至此我们就基本了解了。

开始优化！！！

很明显这个sql存在什么问题？ 内存使用过大，累计峰值内存使用80G。。。

为什么呢？因为广播了一个大表，所以我们改为shuffle

两种方式

1.SET DEFAULT_JOIN_DISTRIBUTION_MODE=SHUFFLE；

2.compute stats A, compute stats B

可以看到峰值内存最高时64MB *10台机器 也就是640M 差不多。

 最后我们再看下查询时间

前者不仅使用了17s还用了85G内存。

后者经过小小的游湖用了2s 和650M内存。就这么一个小小的改动，查询速度提升了10倍，内存使用率减少了99%

good！！

如果这篇文章给你帮助，点赞是对我最大的支持