前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >0912-7.1.7-Impala同一查询耗时差距过大问题分析

0912-7.1.7-Impala同一查询耗时差距过大问题分析

作者头像
Fayson
发布2023-12-11 18:49:19
2020
发布2023-12-11 18:49:19
举报
文章被收录于专栏:Hadoop实操Hadoop实操

1 文档编写目的

本文档主要描述在日常业务业务查询过程中,元数据以及统计信息一切正常的情况下,发现同一SQL,在impala中查询kudu表,有时跑3~5秒,有时跑13多秒的情况分析过程和解决方式。

  • • 测试环境
    1. 1. 集群版本:CDP 7.1.7 SP1 1071
    2. 2. 对应Impala 3.4.0 ,Kudu 1.15.0

2 问题描述

发现同一句SQL,在impala中查询,有时跑3~5秒,有时跑13多秒,具体情况如下所示:

代码语言:javascript
复制
具体SQL脱敏后为:
SELECT `b`.`col1`, `b`.`cola`, `b`.`colb`, `b`.`colc` as `colc`, '-' as `cold`, `a`.`col2`, `a`.`cole`, `a`.`colf`, `a`.`col3`, `a`.`colg`, `a`.`colh`, `b`.`coli`, `b`.`colj`,  `b`.`colk` 
 FROM `db1`.` tablename1` `a` INNER JOIN `db1`.` tablename2` `b` 
 ON ((`a`.`colm` = '**') AND ((`a`.`col2` = `b`.`col2`) AND (`a`.`col3` = `b`.`col3`))) 
 WHERE (( `a`.`col2` IN ('**', '**', '**') ) AND ((`b`.`colq` = '2023-**-**') AND (`b`.`coln` = '**')));

3 问题分析

首先找到两段执行时间相差很大的sql查询的profile 文件,查看其执行计划:

通过查看执行计划,发现其耗时相差较大的阶段在于kudu scan这一步。

代码语言:javascript
复制
01:SCAN KUDU                  1      1  13s531ms  13s531ms  8.46K      33.15K    1.26 MB       24.00 MB  p_aalp.data a
01:SCAN KUDU                  1      1   3s017ms   3s017ms      4      33.15K  649.00 KB       24.00 MB  p_aalp.data a

再查找有关kudu scan的信息,这个信息显示了这个过滤器的等待时间超过了1秒,部分结果未能按时到达,而查询时间短的查询,过滤器的结果全部到达。

代码语言:javascript
复制
查询耗时久:Runtime filters: Not all filters arrived (arrived: [], missing [0, 1, 2, 3, 4, 5]), waited for 0. Arrival delay: 1s035ms.
查询耗时短:Runtime filters: All filters arrived. Waited 1ms. Maximum arrival delay: 974ms.

向上查找到该信息发生的kudu主机,根据该主机信息,再登录到后台查询kudu的Tablet Server角色日志:

发现有很多kudu内存压力的警告,服务节点内存使用紧张。

查看kudu服务内存设置情况,发现都是使用默认配置,内存过小。

3 处理方法

一、针对kudu server内存使用紧张的问题,进行参数调整:

代码语言:javascript
复制
1) CM > kudu > configuration > Tablet Server Advanced Configuration Snippet (Safety Valve) for gflagfile > --rpc_service_queue_length=200 
2) Kudu Tablet Server Hard Memory Limit 从4G改到8G 
3) Kudu Tablet Server Block Cache Capacity 增加到1GB

二、除了之前提到过的相关性能参数调整之外, 慢的profile里发现在KUDU_SCAN_NODE这一步还有一个报错:

代码语言:javascript
复制
Runtime filters: Not all filters arrived (arrived: [], missing [0, 1, 2, 3, 4, 5]), waited for 0. Arrival delay: 1s080ms. 

这段报错代表查询在扫描数据时,没有等到过滤条件,所以扫描的行数就比快的查询多了很多: - RowsRead: 835,795 (835795), 时间花的也更多。

RUNTIME_FILTER_WAIT_TIME_MS是用来控制等待过滤条件的时间的,默认是1000也就是1秒,将这个参数上调一些, 调到2000,即让查询等待过滤条件的时间延长,从而确认更能够匹配到过滤条件,减少扫描的行数,从而来提升查询性能。

这个参数加在Impala配置的default_query_options里面,配置参考如下:

可以通过set; 命令去确认参数配置是否已生效,如下:

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2023-12-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Hadoop实操 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1 文档编写目的
  • 2 问题描述
  • 3 问题分析
  • 3 处理方法
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档