==========================
理解 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 的算法
==========================
对于等值join, impala支持nested loop join和hash join两种算法, 对于hash join又可以分是 broadcast/Shuffle 两种. 针对等值join 走hash join, 非等值join走nested loop join. on子句中, 即使对字段施加某种操作如果仍是等值join, 仍属于hash join.
broadcast join 非常适合右表是小表的情形, impala 先将右表复制到各个节点和左表做join.
shuffle join, 也叫做partitioned join, 适合大表和大表关联. 注意 partitioned join 和右表的 partition 没有直接关系, impala 会将右表打散成N份, 发送到左表所在的节点, 然后作join.
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)
==========================
最佳实践
==========================
1. Impala执行引擎还不是那么智能, 多表join 的SQL最好还是按照下面的推荐的写法,
2. 最大的表应该放在表清单的最左边.
3. 多个join的查询语句, 应该将选择性最强的join放在最前面.
4. 定期对表收集统计信息, 或者在大量DML操作后主动收集统计信息.