老生常谈的问题了。
为什么要优化?
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,所以默认这样,会广播右边的小表。
- 使用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个 更加充分得利用了资源,发挥了分布式得特点。
----------------未完待续