Impala 技术点梳理

1.优点

1.1 快！

主节点生成执行计划树并分发执行计划至各节点并行执行的拉式获取数据（MR：推式获取数据）

计算的中间结果不写入磁盘

1.2 便利

提供SQL语义，可以方便的进行复杂的数据分析任务

2.缺点

2.1 啃内存

对于内存的依赖过于严重，内存溢出直接导致技术任务的失败

2.2 SQL支持度低

不支持UDF，不支持UPDATE/DELTE操作，不支持同一SELECT中多个DISTINCT

3.内存优化

3.1 SQLOperations that Spill to Disk

即在内存不足时将数据存入磁盘进行计算。这是在Impala 1.4 for CDH4、CDH5.1开始支持的功能，以增加了磁盘IO，延长了运算时间为代价，避免了内存溢出的问题。

开启方式：

impalashell中执行

setDISABLE_UNSAFE_SPILLS=0

或

setDISABLE_UNSAFE_SPILLS=FALSE

赋值为1或TRUE则是关闭

注意：该功能也是有限制的：

不是所有的SQL语句都能触发，例如union关键字还是会触发内存溢出错误；
各个节点的内存峰值限制不能过低，低于运算所需分配给各个节点的最小内存；
运算explain输出的各个节点预估内存不能过分高于各个节点的实际物理内存；
当触发“Spill to Disk”功能时有其他并发查询，仍会触发内存溢出错误；
对磁盘的空间有一定的要求，磁盘运算的数据会写入到impala各个节点的临时目录下，增加了磁盘I/O，并且会引发不可控制的磁盘占用。

所以，这个功能不是内存优化的首选方案

3.2 SQL优化

1.Compute Stats

COMPUTE STATS 是统计表的结构以及数据信息（表、分区、列的数据量和数据分布信息）并存储在到数据库中，集群根据统计信息优化数据分析操作。

看似只是Impala中一条获取表的统计信息的简单语句，但在整个分析任务调度过程中却起着相当重要的作用。该语句获取的统计信息不仅在Impala对JOIN、GROUP BY、ORDER BY、UNION、DISTINCT等资源高消耗的查询进行优化时会使用到，而且对HBase的表也同样起作用。

使用：

compute STATS [table_name]

查看统计结果

SHOW TABLE STATS [table_name]

2.执行计划（Explain）

通过在SQL语句前面加上 explain 执行，并就可以查看到该SQL的具体执行计划情况（实际上并未真正执行）

执行计划是从底层显示Impala如何读取数据，如何在各节点之间协调工作，组合并传输中间结果，并获得最终结果集的全过程。

执行计划可以提供给我们的帮助：

（1）通过读取的数据量，我们可以判断分区策略是否有效，并结合集群大小预估读取这些数据需要的实际等。

（2）可以看到执行过程中聚合、排序、统计函数、交互的顺序及具体执行细节，可以从更高级别看到中间结果在不同节点间的流向。

（3）我们可以看到操作是否被Impala不同的节点并行执行，以及各节点所需内存预估值。

（4）通过配置EXPLAIN_LEVEL参数，可以了解到更详细的输出信息。取值从0~3，对应的执行计划信息越来越详细。