impala基础原理分析

       通过impala，可以实现大数据的实时查询和统计分析，效率比hive高30倍左右,当然impala不适合批量计算，因为非常消耗内存，而hive是非常适合长时间大批量离线批量计算。是clouder的顶级项目，impala查询快的原因，比hive快：

       1、它的查询计划，会被分布式查询引擎拿到数据节点上直接查询，将结果返回。

       2、查询连接是直接连接到管理数据的impalaD节点，就近连接，就近读取数据，就近选择其他impalaD帮忙查询，所以比较快。

 

impala体系结构：

       1、state store：并周期性检查impala进程状态，并同步发给各个impalaD。这个state store是个健康检查服务，主要是避免某个impalaD出故障后，可以通知其他impalaD,无需把查询任务发给这个故障impalaD。除此之外，state store与hive metastore关联，把元数据交给calalog server，然后同步给impalaD 做查询。

       2、catalog server：负责impala元数据管理，并把元数据同步到各个impala deamon。所以impala D上有metadata cache节点用作元数据的缓存。

       3、impala deamon：impala D和hdfs dataNode进程协同服务，执行用户提交的查询。

impala查询过程：

      客户端（impala-shell）会连接到一个impala Deamon,这个impalaD就是此次查询的协调者，会将查询任务分发给各个impalaD,帮忙查询，所有查询结果都会返回给这个impalaD协调者，然后整理返回给客户端。因为impalaD有calalog server 从state store同步过来的元数据，所以可以直接执行查询，无需与catalog server协调通讯。

查询接口：

     查询客户端 impala shell，api可以通过JDBC、ODBC等协议接口，与impala 进行交互查询。

元数据缓存：

     impala 的元数据是保存在hive的metastore里面。在impala启动的时候，catalog server 会将元数据同步给各个impala D。当impala 元数据变更后，catalog server也会将元数据变更同步到各个impala D中。

      上述是impala内部的改变，比如更新表，修改表结构了，都可以让impala d在catalog server同步下更新自己的缓存。当外部，比如hive的操作Hive、Hcatalog或HueMetadata Manager改变了元数据，或者外部直接添加数据到hdfs 目录，impala 无法更新自己的元数据，这个时候，可以手动refresh 表，进行主动更新。