不生产博客,只是汉化别人的成果
pdf链接
目录
封面大概是这样式的
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别的没啥用呀
噗