Impala系列:Impala查询优化

==========================
理解 mem_limit 参数
==========================
set mem_limit=-1b #取消内存限制
set mem_limit=1gb #设置单机内存上限为1GB, 注意是单机
set mem_limit=1mb #设置单机内存上限为1MB, 注意是单机
如果设置了 mem_limit, impala 将跳过Query内存评估环节, 直接检查Pool中剩余内存是否够用, 如果够用的话, 将直接执行. 如果不够用的话, 将按照pool设定的策略, 将Query放到queue队列中, 如果在timeout设定时间内仍得不到足量的内存资源, 该Query将被取消. 如果用户不设置mem_limit, 默认使用Pool的 default_pool_mem_limit 值, 如果default_pool_mem_limit没有设置,Impala会自己来估计这个值. 如果没有设置mem_limit, 否则Impala根据统计信息和执行计划预估内存消耗.

当然, 在运行期间, 如果Query占用的内存超过 mem_limit, impala 将终止该 query,

假设单机设置了10GB的内存上线, 集群有10个节点, 在查询之前, Impala检查Pool 中剩余内存是否够300GB.

Impala pool 级别几个设置参数有:
default_pool_max_queued, 进入等待队列中查询的缺省个数
default_pool_max_requests, 正在执行中的查询个数
default_pool_mem_limit, 为查询设置的默认内存占用上限, 通常通过 disable_pool_mem_limits 参数禁用了该设置.
queue_wait_timeout_ms, 缺省 60000 毫秒, 即1分钟, 查询在队列中最大等待时长, 超过该设定值, 查询就被reject.

手工设置 MEM_LIMIT 参数的必要性
1. 避免Impala的 over-estimation 的不良后果
Impala 在查询执行之前会预测SQL执行会消耗多大内存, 预测主要是依据表的统计信息, 但在很多时候, Impala的预估是很粗放式的, 即使表的统计信息很及时, impala也会over estimate内存消耗. over-estimation 的后果有: (1)预估值如果大于impala pool中的剩余内存, impala 就会reject该查询. (2)降低并发度.
2. 有可能会提升执行速度
手工设定 MEM_LIMIT 参数后, Impala将会跳过内存预测过程, 有可能会加快执行速度.

如何设置 MEM_LIMIT 参数?
先试运行一下SQL, 然后在 profile 中, 查看其 memory_per_node_peak 值, 该值即为实际上的内存消耗, 或者在 impala WebUI该query详细页面的 Summary 页签的 Peak Mem 栏位.

==========================
impala 资源的软隔离
==========================
摘自国双公司的说明: https://blog.csdn.net/qq_18882219/article/details/78447558

由于Impala的每个Impalad节点都可以接受查询，对于每个Pool现在有多少查询，占了多少内存，Queue了多少，这些信息也是每个Impalad更新，通过Statestored来广播到其他Impalad，所以这个信息可能在每个节点上可能是不一致的。当一个Impalad收到查询需要做一些决策例如是否拒绝，是否Queue住，本地的这个决策信息可能是旧的，所以Impala基于Pool的资源隔离本身来说是一种软隔离，也就是说对于任何一个Pool来说，其用到的内存有可能会超过最大内存，运行的查询数量有可能会超过Pool设置的最大查询数量。这个我们在实际的使用中也证明了。软隔离问题会带来两个风险：
1.单个节点申请的内存在某个时刻超过了分配给Impalad进程的内存，这个会导致Impalad OOM退出
2.某个Pool在某一个时刻使用了远远超过这个Pool的资源，这个对于不同业务用Pool来做资源隔离是不利的。
这个问题我们也跟Impala社区的开发者做过讨论，最后使用的方案是：单个Pool指定唯一的Coordinator，这个Pool的所有查询都发送给同一个Impalad。于是这个Coordinator时刻都有这个资源池最新的信息，就从软隔离进化成了硬隔离，缺点是会带来单点问题，可采取了主备的方式来避免这一问题.

==========================
其他几个重要的session 变量
==========================
除了 MEM_LIMIT, 还有如下常用的session 变量
EXPLAIN_LEVEL :设置explain和profile的输出详略
DISABLE_UNSAFE_SPILLS : 是否禁用 disk spill, 目前对disk spill限制还很多, 比如非等值join不能使用 disk spill.
REQUEST_POOL : 设置所在的队列

EXPLAIN_LEVEL 参数可以控制 explain语句的输出, 也可以控制 profile 命令输出. 需要说明的是, explain 可以在SQL客户端中执行, 而profile 命令只能在impala shell中执行, 另外只能展现已经最近执行完毕的那个SQL的profile.
set EXPLAIN_LEVEL = 0 -- 0 or MINIMAL, 因为输出信息较少, 更容易发现主要的信息 比如join的order
set EXPLAIN_LEVEL = 1 -- 1 or STANDARD, 标准的输出
set EXPLAIN_LEVEL = 2 -- 2 or EXTENDED, 详细的输出
set EXPLAIN_LEVEL = 3 # 3 or VERBOSE, 更详细的输出

如果查询速度较差, 可以通过下面命令看看是否缺少统计信息.
set explain_level=3 --verbose 级, 包含更多的细节信息. 在explain输出中, 如果有如下信息, 则对应表没有统计信息.
cardinality: unavailable
table stats: unavailable
column stats: unavailable

==========================
Join reordering
==========================
对于多表Join 查询, 老版的impala总是按照表出现的顺序依次查询, 但新版Impala执行引擎已经可以自动按照的表/列的统计信息, 做Join reordering. 规则是:
大表(表 size和distinct value多的表)先被查询, 小表后被查询
无统计信息的表(impala认为表的size为0)将最后被查询.

==========================
使用 STRAIGHT_JOIN Hint
==========================
当统计信息过期或没有统计信息或者表有很诡异的数据分布, Impala执行计划的查询表顺序很可能不是最优, 这时候, 最好加上 STRAIGHT_JOIN Hint, 强制impala按照SQL中表出现的次序做查询, 当然我们SQL表出现次序应该是精心调整过的.

另外, STRAIGHT_JOIN 仅仅对于当前Select 语句有效, 如果子查询和view也需要严格按照表次序做查询, 需要在子查询和视图中显式地加上 STRAIGHT_JOIN hint, 另外 STRAIGHT_JOIN hint 是impala 的关键词, 不能放在/*+*/中.

select STRAIGHT_JOIN t1.* from t1
join t2 on t1.id=t2.id

select distinct STRAIGHT_JOIN t2.id,t1.name from t1
join t2 on t1.id=t2.id
;

==========================
join 的算法
==========================
1. hash join: 对于等值join, impala将采用hash的方式处理, 具体又分两种策略, broadcast 和 Shuffle.
broadcast join 非常适合右表是小表的情形, impala 先将右表复制到各个节点, 再和左表做join.
shuffle join, 也叫做partitioned join, 适合大表和大表关联. 注意 partitioned join 和右表的 partition 没有直接关系, impala 会将右表打散成N份, 发送到左表所在的节点, 然后作join.
2. nested loop join: 针对非等值join, impala将使用 nested loop join, 这时我们不能设置 SHUFFLE/BROADCAST hint, 也不能使用 spill disk 功能. impala的非等值join的效率较低, Vertica的效率非常高, Hive直接不支持.

SELECT STRAIGHT_JOIN select_list FROM
join_left_hand_table
JOIN [{ /* +BROADCAST */ | /* +SHUFFLE */ }]
join_right_hand_table
remainder_of_query;

/* +SHUFFLE */ 即 partitioned join, 是将要关联的两个表按照
/* +BROADCAST */ 即
Exchange : the intermediate results are transmitted back to the coordinator node (labelled here as the EXCHANGE node)

==========================
最佳实践
==========================
Impala执行引擎还不是那么智能, 多表join 的SQL最好还是按照下面的推荐的写法:
1. 最大的表应该放在表清单的最左边.
2. 多个join的查询语句, 应该将选择性最强的join放在最前面.
3. 定期对表收集统计信息, 或者在大量DML操作后主动收集统计信息.
4. 在一个单一的查询里面, 参加join的表个数尽量不要超过4个, 不然效率比较低下.