Impala基础调优

分享一些Impala调优的心得

Posted by bluesky blog on August 14, 2015

目录



对于查询优化,有以下范围:

  1. SQL查询语句优化

  2. 软件各项参数优化

  3. 硬件层面优化

前面两点是用的最多,也是最基础的优化手段。在实际工作中,由于数据量巨大,开始涉及Impala查询优化,一些心得,分享给大家。

一、使用官方文档调优建议

在官方文档中,针对Impala的查询优化,写得比较详细的。

链接如下:

http://www.cloudera.com/content/cloudera/zh-CN/documentation/core/v5-3-x/topics/impala_performance.html

文档是中文,针对的版本是Impala 2.1.0

主要涉及如下几个方面:

  1. 收集表信息,以生成准确的执行计划

  2. 多表关联查询时,注意表的和条件的连接顺序

  3. 使用表分区

  4. 使用缓存、合理分配资源

  5. 检测并纠正HDFS块歪斜情况

二、实际调优过程

除了借鉴了官方提供的一些优化建议,还做了以下一些优化:

文件格式

我们使用了parquet文件格式作为存储,对于Impala使用Parquet的说明,可见:http://www.cloudera.com/content/cloudera/zh-CN/documentation/core/v5-3-x/topics/impala_parquet.html

表合并

查询的数据源是Spark Streaming加工出来的,存储时生成了较多的小文件,查询众多小文件,是很耗费系统性能的。因此,我们每小时合并一次文件,并将合并后的数据存入到一张新表之中。

用户调用查询接口时,根据条件中的时间,判断Impala查询当前表还是合并之后的表。

文件blocksize

我们的hadoop集群默认的blocksize是128M的,但由于表文件太大,即使是128M依然会被切分成很多文件存储。于是我们单独设置,合并后的表文件的blocksize为1G,具体方法如下:

使用Impala合并新表的过程类似于,

 Insert into xx_merge select .. from xx; 

在前面加上:set PARQUET_FILE_SIZE=1g

set PARQUET_FILE_SIZE=1g;insert into table xx_merge select .. from xx;

三、结束语

使用了上面的一些调优方法后,可以看看实际的查询效果了,表按天分区,一天的数据量是400亿条以上,文件大小约1.8T

select查询

Query: select c1,c2 from xx where   month_ = '201508' and day_ = '08' and term1 = 'xxxxx' and term2 = '404'  limit  10
+--------+-----+
| c1 | c2  |
+--------+-----+
| 404    | 557 |
| 404    | 551 |
| 404    | 551 |
| 404    | 298 |
| 404    | 551 |
| 404    | 472 |
| 404    | 553 |
| 404    | 553 |
| 404    | 469 |
| 404    | 512 |
+--------+-----+
Fetched 10 row(s) in 1.16s

count统计

Query: select count(*) from xx where month_='201508' and day_='12'
+-------------+
| count(*)    |
+-------------+
| 40299949397 |
+-------------+
Fetched 1 row(s) in 45.41s

group by .. order by分组排行

select count(c1) as c1,sum(c2) as c2 from xx where  month_ = '201508' and day_ = '08' and term1 = 'xxx' and term2 = '404'   limit  10
+--------+---------+
| c1 | c2      |
+--------+---------+
| 18759  | 9717406 |
+--------+---------+
Fetched 1 row(s) in 43.55s

做分析统计时,速度仍然不是很理想。不过对于这个级别的数据量,还算不错,优化的路,依然很长。