利用impala query profile解决性能问题（二）高级查询调优和故障排除

本文链接：https://blog.youkuaiyun.com/weixin_44893236/article/details/144847653

前言

第一节中详细介绍了 Impala的查询计划（Plan）和查询概要(Profile)，已经基本掌握了阅读执行计划和概要的技能。
下面详细说一下如何调优，本文会结合大量案例辅助理解。

一、案例

1.1 谓词下推

左侧：没有 Kudu 谓词下推的 Profile
右侧：经过 Kudu 谓词下推的 Profile
在这里插入图片描述

Impala在执行查询时，会尽可能地将谓词下推到数据存储层，以减少需要传输的数据量。谓词下推是指将过滤条件尽早地在数据读取阶段应用，从而减少网络传输和计算资源的使用。
Impala 支持多种类型的谓词，包括：

‌等值谓词‌：如column_name = value ‌

范围谓词‌：如column_name BETWEEN 100 AND 200

模式匹配谓词‌：如column_name LIKE ‘abc%’ ‌

集合谓词‌：如column_name IN (1, 2, 3)

上图左边没有使用谓词，右边使用了范围谓词，并且下推到 Kudu 存储层。在 Profile ExecSummary 中可以很明显地看到，使用谓词下推 Operator 00：SCAN KUDU 的执行时间明显短得多。

1.2 远程读取

左侧：parquet 远程读取
右侧：parquet 本地读取
左右两侧的SQL完全一致。
在这里插入图片描述
根据左右两边 Profile ExecSummary 可以看到，中间结果（红色框）一样，但是执行时间差距比较大。根据opertor id=0 查询具体 Fragment里的详细信息。

左侧 BytesReadLocal 本地读取只有 34.6MB（剩余118.5-34.6全部都是远程读取），而右侧本地读取达到118.5MB。由此可见，远程读取消耗时间远远高于本地读取。

在实际生产环境上，发生此例的原因有：Parquet Block 和 HDFS Block 没有对齐，因为 Parquet
需要读取整个列组，但如果一个列组消耗了多个 HDFS BLOCK，当前 Scanner 就需要从其他机器远程读取数据；还取决于File Format，如果使用了压缩，比如：GZIP、BZIP，读取的时候首先需要读取所有的数据，然后进行解压。