Impala架构概述

概述

Imala是基于Hive并使用内存进行计算，兼顾数据仓库，具有实时，批处理，多并发等优点。因为直接使用的Hive的metadata，也就是impala的元数据都存储在Hive中的metadata之中，并且Impala兼容大部分Hive语法。

优点

1、Impala特别快，因为所有的计算都可以放入内存当中进行完成，只要你内存足够大
2、摈弃了MR的计算，改用C++来实现，有针对性的硬件优化
3、具有数据仓库的特性，对hive的原有数据做数据分析
4、支持ODBC，jdbc远程访问

缺点

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

---

架构

impala-server ==>启动的守护进程，执行我们的查询计划 从节点，官方建议与所有的datanode装在一起，可以通过hadoop的短路读取特性实现数据的快速查询
impala-statestore ==》 状态存储区 主节点
impalas-catalog ==》元数据管理区 主节点
查询执行
impalad分为frontend和backend两个层次， frondend用java实现（通过JNI嵌入impalad）， 负责查询计划生成， 而backend用C++实现， 负责查询执行。

---

frontend生成查询计划分为两个阶段：

（1）生成单机查询计划，单机执行计划与关系数据库执行计划相同，所用查询优化方法也类似。
（2）生成分布式查询计划。 根据单机执行计划， 生成真正可执行的分布式执行计划，降低数据移动， 尽量把数据和计算放在一起。

该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倍。