调优impala:5个顶级的性能优化对于最牛b的mpp

不生产博客，只是汉化别人的成果

pdf链接

https://cdn.oreillystatic.com/en/assets/1/event/193/Tuning%20Impala_%20The%20top%20five%20performance%20optimizations%20for%20the%20best%20BI%20and%20SQL%20analytics%20on%20Hadoop%20Presentation.pdf

目录

概述

分区

Sorting

运行时过滤和动态分区裁剪

字段类型选择

统计信息

​

---

 

封面大概是这样式的

tuning impala:the top five performance optimizations for best bi and sql analytics on hadoop

the leader for analytic sql on hadoop

 hadoop上sql分析的领导者，哈哈哈

下面是单用户下TPC-DS基准测试的对比，吊打所有sql on hadoop

 

下面就是要优化的几个点

概述

 物理数据模型和schema设计:

选择最好的物理表示对于你的逻辑数据模型

1.分区

2.排序

3.运行时过滤和动态分区修剪

4.字段类型

5.嵌套类型(是个什么鬼)

操作上的优化

1.统计信息

2.内存管理

分区

物理上隔离你的数据以便查询的时候访问一部分数据，是scan最小的单位

 

选择合适的分区粒度

太少，影响并行度，太多，小文件太多，降低scan效率，并对hive metadate，hdfs namenode，impala的catalog造成较大的压力

原则：定期的compact表文件，控制每个分区的文件数量，提高scan的效率

Sorting

对数据文件进行排序提高file统计信息的效率和压缩(排序是个什么骚操作呀)

排序可以用到一些字段上，比如有太多值导致不能分区

生成排序数据文件通过添加sort by在表创建的时候，只在impala2.9+可用

parquet社区正在努力的扩展来提升lookup(随机读，hbase就是干这事的)性能

排序:augment 分区(加强分区?)

需求:找出给定窗口内在平安夜消费最多的顾客

sql挺简单的

下面是sort与不sort的对比，这个还得自己测下 ，排序后scan hdfs也少了

 

排序：Complementlement分区(补充分区)

 lookup性能对比

以顾客id排序，在想如果是string排序的话效果会不会也这样，string测了下没提升，可能我数据量太小

运行时过滤和动态分区裁剪

 

两个表关联，关联字段是大表的分区字段，执行计划就是广播小表

 即使有统计信息，计划器也不知道那两字段能关联需要scan哪些数据，但是很显然我们可以尝试下优化，为什么会scan出28亿去关联呢?仅仅得到一个1.3亿的结果

第一步，计划器告知join生成一个布隆过滤器来得到符合条件去重的d_date_sk

第二部，读取右表所有的字段填充布隆过滤器包含所有不同的值

第三步，查询协调器发送过滤器到左表，在scan之前

 

scan预估所有的分区没有在布隆过滤器匹配到的，仅仅1824个分区中读了150个

第5步，仅仅scan出1.3亿即可

卧槽，啥意思，impala本身有运行时过滤和动态分区修剪吗，在sql级别我们不需要干啥就行了

这个得后面测测 

字段类型选择

字段类型选择影响性能

计算:数值类型允许直接计算，string类型必须强转

磁盘存储大小：数值类型更compact,压的更紧，哈哈哈

更紧凑的compact,只需要更少的网络

运行时代码生成，一些类型不支持(char、timestamp、tinyint)

通用的规则

选择数值类型对于数字而不是字符类型

尽量使用占磁盘更小的类型，只要能够容纳所有的值

官网的测试，TPCH，差别还是挺大

 后面还有个复杂的schema，一般用不到就不粘了

统计信息

应该是执行计划吧，不懂为啥叫统计信息

首先第一个图，根据sql和成本 scan预估(就是谓词下推，能少scan点数据)

可以看到右边根据where条件只scan部分数据

第二张图，根据条件scan和join，不知道啥意思，为啥我试了下explain没这玩意 

 第三章图，统计信息能够决定以何种方式关联，下面就是广播，把一张28gG的广播了

第四张图，统计信息可以选择一种合适的join类型

第五张图，join前的谓词下推

 我去，原来说的是有统计信息的好处，好吧，说的几种除了sort别的没啥用呀

噗