impala查询性能优化

川长思鸟来 2023-07-24 02:45 9阅读 0赞

# **查看表和列的统计信息：(适用于hive表，kudu表，hbase外表)** #

**compute stats tbl\_nm; impala优化器**。执行之后可能会解决impala查询该表爆内存的错误。并且可以执行下面两个指令. compute stats是检查impala中的表数据，因此如果hive数据更新了还是得先refresh table,然后再执行compute stats。此命令计算了表在impala中缓存的数据聚合信息。并且在查询或关联中用到该表，impala会自动根据计算后的结果去优化执行计划。

**show column stats tbl\_nm;** 看表的字段的聚合信息(前提是执行了compute指令，否则不准确)

**show table stats tbl\_nm;**看表的聚合信息 包含文件大小，行数，类型，路径等(前提是执行了compute指令，否则不准确)

分区表通常都是在不断变大的。这时候如果增加或者更新一个新分区也需要执行COMPUTE STATS的话，是非常低效的。因为COMPUTE STATS需要遍历整张表。为了解决这个问题，从impala1.2开始，增加了COMPUTE INCREMENTAL STATS。这个命令只会增量统计信息。

对于通量的数据，执行COMPUTE INCREMENTAL STATS会比执行COMPUTE STATS更耗时。因此更适合要频繁增加具有大量数据的分区的表。对于不分区的表，或者虽然分区，但一次加载，不会再更新新分区的表，使用COMPUTE STATS更好。

如果使用ALTER TABLE来删除一列，存在的统计信息仍然有效，执行COMPUTE INCREMENTAL STATS不会重新扫描任何分区；

如果使用ALTER TABLE来增加一列，执行COMPUTE INCREMENTAL STATS时，impala会重新扫描所有分区，并填充准确的列层级的值；

如果使用ALTER TABLE来改变表的文件格式，存在的统计信息仍然有效，执行COMPUTE INCREMENTAL STATS不会重新扫描任何分区；

如果使用ALTER TABLE来改变某列的数据类型，执行COMPUTE INCREMENTAL STATS时，impala会重新扫描所有分区，并填充准确的列层级的值；

# 执行计划： #

**explain** \[QUERY\] :查询执行计划,检验SQL查询是否合理运用分区，如下partition=3/483，用到了483个分区中的3个

set explain\_level=0/1/2/3; 设置explain的等级。越高越详细；

![20200408221953516.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70][]

在impala-shell中，执行完一条QUERY后，执行**summary**;或**profile**; 可以查看该查询的详细查询分析；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 1][]

# 关联查询优化： #

对于join查询，最简单的方式是通过执行COMPUTE STATS来收集涉及到的所有表的统计信息，并让 Impala 基于每一个表的大小、每一个列不同值的个数、等等信息自动的优化查询。

最大的表放首位。这个表在查询的时候是每个impala节点直接从磁盘读取的，因此它的大小对于内存使用没影响。

**STRAIGHT\_JOIN**

在impala中数据量大的表在前，数据量小的表在后，有助于提升性能。Impala会默认根据compute之后的统计结果对查询进行执行计划的排序，大表在前，小表在后。 但有时compute的统计结果是旧的信息，即表数据已更新，没有再次执行compute或没有refresh之后再compute，导致统计结果为旧版本，这时候在做关联查询的时候，依靠impala自己的优化器去执行关联查询就不准确了，这里推荐使用straight\_join关键词，来覆盖自动的连接顺序优化。这时候，Impala 使用表在查询中出现的顺序来指导连接如何处理。

然后按表大小由大到小依次排序。这些表的内容全部都是要在网络中传递的，所以，表越到后面越小越好。

值得注意的一点是，这里的“大小”是就每个表在查询后生成的中间结果涉及到的行的数量来定的。比如，一次查询，要join两个表：销售表和用户表。查询的结果是100个不同的用户共有5000条消费记录。因为涉及用户表的行比销售表少（100<5000）。所以用户表应该放在后面（右边）。

# 分区优化： #

**动态分区/静态分区**

(动态分区，略)

**设置分区的不同的文件格式**：

分区表的不同分区可以分别设置存储格式(parquet,rcfile,orc,textfile..)但同一个分区内只能存储一种文件格式。alter table tbl\_nm partition (pt=xx) set fileformat parquet/textfile;

例如分区pt=2018本来是text存储且有数据，改变为parquest存储后新增数据或查询数据都会报错。需要重新覆盖该分区的数据。

![20200408222208730.png][]

PARQUET\_FILE\_SIZE: parquet文件大小上限，默认为256MB,最大1GB。需要考虑到磁盘IO和网络带宽的性能影响。

![20200408222231738.png][]

[20200408221953516.png]: /images/20230528/ed92d8ee04424802ab9a50e63b888b0e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70]: /images/20230528/8a05033cfd6342cf8bb586412a57c0a9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 1]: /images/20230528/502ec4634dfb4369b8d398bd0bf2aa2b.png
[20200408222208730.png]: /images/20230528/676b5331390c413ebc9b2fd2fb01b35c.png
[20200408222231738.png]: /images/20230528/0b02ce694d7347c9ba5afa92098c135a.png