impala sql优化

老生常谈的问题了。

为什么要优化?

1.内存溢出导致执行报错

2.sql执行时间过长比如30min 1h

3.占用内存太大影响其他sql。

其他的原因我是想不出来了，比如一个sql跑出结果只要1s ，即使有优化空间，你还优化他么。。

以下都是个人见解如有不对欢迎评论。

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

1.compute stats

通过该语法统计表中各字段的信息，在join的时候会有帮助

2. join

join肯定是影响sql查询慢的主要因素。如何正确的join？

大表 join小表，采用广播join

大表join大表，采用shuffle 

上面的文章有写到。再说一遍也是给自己增加印象。

如果你没有 compute stats

select 1 from A,B where A.id=B.id 广播右边的B

select 1 from B,A where A.id=B.id 广播右边的A

select 1 from B,A where A.id=B.id + compute stats A 广播B(因为B没有统计信息)

一般来说我没见过其他人compute，所以查询的时候注意了大表放前面，小表放后面。
 

3.大表放左边，小表放右边 

这个是因为大多数人都不compute stats，所以默认这样，会广播右边的小表。

1. 使用not in，not exists 默认将右表广播，而且没法指定partitioned join ，使用left anti join

4. distinct 和group by有区别吗？

按照我的测试 我觉得是没有问题的。。

hive 的explain (我的engine是tez 不是spark)

以前mr和spark的时候，别人都说distinct容易数据倾斜。。我也没看到过具体的分析，反正都是这么一句话。

 impala的summary

5. 充分利用资源。

在测试4 用hive表时我看到summary的host只有3个。还记得我用kudu表得时候都是10个host 。

这说明了啥。因为kudu分区较多得原因，所以kudu会分散到各台机器，所以有10个。

而hive表一般只有几个block，所以机器得数量不会太多。

我们来看下hive表。

该表有个两个文件269M和190M， 然后根据256M有3个block 

 

 

备注 这个block只有2个，可能时有个hdfs节点有问题。。。 

block0 node09,node03,node13

block1 node03,node11,node12

block0 node05,node08

三个block对应得是3个host？我们在仔细看下，发现确实只用到了这么三个节点。

测试下我们把这两个block打散后是不是host数量就会改变了呢？

文件打散成10份。可以看到hosts直接就成了11个 更加充分得利用了资源，发挥了分布式得特点。

 

 ----------------未完待续