impala（01）——impala的概述

impala的介绍

impala是cloudera提供的一款高效率的sql查询工具，提供实时的查询效果。
官方测试性能比hive快3到10倍，其sql查询比sparkSQL还要更加快速，号称是当前大数据领域最快的查询sql工具。
impala是参照谷歌的新三篇论文（Caffeine、Pregel、Dremel）当中的Dremel实现而来。
impala是基于hive并使用内存进行计算，兼顾数据仓库，具有实时，批处理，多并发等优点。

impala与hive的关系

impala是基于hive的大数据分析查询引擎，直接使用hive的元数据库metadata，意味着impala元数据都存储在hive的metastore当中，并且impala兼容hive的绝大多数sql语法。
所以需要安装impala的话，必须先安装hive，保证hive安装成功，并且还需要启动hive的metastore服务。

impala的优缺点

impala的优点

1、 基于内存计算，所以impala速度快，
2、 摈弃了MR的计算，改用C++来实现，有针对性的硬件优化
3、 具有数据仓库的特性，可对hive的原有数据做数据分析
4、支持ODBC，jdbc远程访问

impala的缺点：

1、基于内存计算，对内存依赖性较大
2、改用C++编写，维护难度增大
3、基于hive，紧耦合
4、稳定性不如hive，存在数据丢失的情况

impala的架构

Impala的架构模块：
impala-server
启动的守护进程，执行我们的查询计划 从节点，官方建议与所有的datanode装在一起
impala-statestore
状态存储区 主节点
impalas-catalog
元数据管理区 主节点

查询计划

impalad分为frontend和backend两个层次， frondend用java实现（通过JNI嵌入impalad）， 负责查询计划生成， 而backend用C++实现， 负责查询执行。
frontend生成查询计划分为两个阶段：
（1）生成单机查询计划，单机执行计划与关系数据库执行计划相同，所用查询优化方法也类似。
（2）生成分布式查询计划。 根据单机执行计划， 生成真正可执行的分布式执行计划，降低数据移动， 尽量把数据和计算放在一起。

上图是SQL查询例子， 该SQL的目标是在三表join的基础上算聚集， 并按照聚集列排序取topN。
impala的查询优化器支持代价模型： 利用表和分区的cardinality，每列的distinct值个数等统计数据， impala可估算执行计划代价， 并生成较优的执行计划。 上图左边是frontend查询优化器生成的单机查询计划， 与传统关系数据库不同， 单机查询计划不能直接执行， 必须转换成如图右半部分所示的分布式查询计划。 该分布式查询计划共分成6个segment（图中彩色无边框圆角矩形）， 每个segment是可以被单台服务器独立执行的计划子树。

impala支持两种分布式join方式， 表广播和哈希重分布：
表广播方式保持一个表的数据不动， 将另一个表广播到所有相关节点（图中t3）；
哈希重分布的原理是根据join字段哈希值重新分布两张表数据(譬如图中t1和t2）。

分布式计划中的聚集函数分拆为两个阶段执行。第一步针对本地数据进行分组聚合（Pre-AGG）以降低数据量， 并进行数据重分步， 第二步， 进一步汇总之前的聚集结果（mergeAgg）计算出最终结果。

与聚集函数类似， topN也是分为两个阶段执行， （1）本地排序取topN，以降低数据量； （2） merge sort得到最终topN结果。

Backend从frontend接收plan segment并执行， 执行性能非常关键，impala采取的查询性能优化措施有向量执行。 一次getNext处理一批记录， 多个操作符可以做pipeline。LLVM编译执行， CPU密集型查询效率提升5倍以上。IO本地化。 利用HDFS short-circuit local read功能，实现本地文件读取Parquet列存，相比其他格式性能最高提升5倍。

（这段话是复制粘贴的，个人理解还不是很透彻~以后慢慢看吧）