本文档主要描述在日常业务业务查询过程中,元数据以及统计信息一切正常的情况下,发现同一SQL,在impala中查询kudu表,有时跑3~5秒,有时跑13多秒的情况分析过程和解决方式。
发现同一句SQL,在impala中查询,有时跑3~5秒,有时跑13多秒,具体情况如下所示:
具体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` = '**')));
首先找到两段执行时间相差很大的sql查询的profile 文件,查看其执行计划:
通过查看执行计划,发现其耗时相差较大的阶段在于kudu scan这一步。
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秒,部分结果未能按时到达,而查询时间短的查询,过滤器的结果全部到达。
查询耗时久: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服务内存设置情况,发现都是使用默认配置,内存过小。
一、针对kudu server内存使用紧张的问题,进行参数调整:
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这一步还有一个报错:
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; 命令去确认参数配置是否已生效,如下: