Impala架构

 Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具，Impala没有再使用缓慢的Hive+MapReduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟。

 

 

Impala由三个服务组成：impalad, statestored, catalogd。       

 

　　　Impalad: 与DataNode运行在同一节点上，由Impalad进程表示，一个datanode对应一个impalad，它接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator通过JNI调用java前端解释SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行），读写数据，并行执行查询，并把结果通过网络流式的传送回给Coordinator，由Coordinator返回给客户端。同时Impalad也与State Store保持连接，用于确定哪个Impalad是健康和可以接受新的工作。在Impalad中启动三个ThriftServer: beeswax_server（连接客户端），hs2_server（借用Hive元数据）， be_server（Impalad内部使用）和一个ImpalaServer服务。

        Impala State Store: 跟踪集群中的Impalad的健康状态及位置信息，由statestored进程表示，它通过创建多个线程来处理Impalad的注册订阅和与各Impalad保持心跳连接，各Impalad都会缓存一份State Store中的信息，当State Store离线后（Impalad发现State Store处于离线时，会进入recovery模式，反复注册，当State Store重新加入集群后，自动恢复正常，更新缓存数据）因为Impalad有State Store的缓存仍然可以工作，但会因为有些Impalad失效了，而已缓存数据无法更新，导致把执行计划分配给了失效的Impalad，导致查询失败。

 

　　   Catalogd作为metadata访问网关，从Hive Metastore等外部catalog中获取元数据信息，放到impala自己的catalog结构中。impalad执行ddl命令时通过catalogd由其代为执行，该更新则由statestored广播。

        CLI: 提供给用户查询使用的命令行工具（Impala Shell使用python实现），同时Impala还提供了Hue，JDBC， ODBC使用接口。

执行计划：

Impala: 通过词法分析生成执行计划，执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。

impala的前端负责将sql转化成执行计划（java），包含两个阶段：单节点计划生成、并行化和分段。第一阶段对sql进行解析、分析、优化（RBO和CBO，统计信息目前只有表大小和列的NDV，无histogram），第二阶段生成分布式的执行计划，确定是否要加exchange节点（是否存在partitioned join或hash aggregation），选择join strategy（partitioned join or broadcast join）等，最后以exchange为边界将计划分段（fragment），作为impala的基本运行单元。

 

优点：

1. 支持SQL查询，快速查询大数据。
2. 可以对已有数据进行查询，减少数据的加载，转换。
3. 多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）。
4. 可以与Hive配合使用。

缺点：

1. 不支持用户定义函数UDF。
2. 不支持text域的全文搜索。
3. 不支持Transforms。
4.  不支持查询期的容错。
5. 对内存要求高。

 

转载于:https://www.cnblogs.com/changbosha/p/5712532.html