1、impala的介绍

impala是cloudera提供的一款高效率的sql查询工具，提供实时的查询效果，官方测试性能比hive快10到100倍，其sql查询比sparkSQL还要更加快速，号称是当前大数据领域最快的查询sql工具。

2、impala与hive的关系

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

3、impala架构

1、Client(shell,jdbc,odbc)发送请求到impalad 进程上，发送节点可以是随机的，impalad 之间，也有相互通信
2、Statestore 和catelog 划到同一节点,目的就是这两个进程在协调工作时候，避免因网络问题造成失败
3、Hive metastore 是比较重要的，此时statestore 和catelog 通信，将数据同步到其他节点
4、Impalad 最好与hdfsDataNode 在同一节点，这样能更快速的查询计算，然后返回结果即可（理想状态的就是数据本地化）
Impalad 里面包含三个组件
Query planner（查询解析器）
将我们的字符串sql 语句解释成为执行计划，
Query coordinator（中心协调节点）
由这个组件来指定来查询的主节点（头），指定好之后通知其他节点我的主节点作用，待你们查询完成之后的结果，返回给头节点
Query executor（查询执行器）
而做查询工作的是就是executor

4、impala核心组件
对于impala 来讲，是没有主节点的，而要理解主节点，impala statestore 和catalog server两个角色，就具备集群调节的功能，根据以上的特点，对impala 进行配置优化配置impala 内存，每一个deamon 都需要配置内存，因为真正做查询工作的就是deamon 所在的节点，所以impala 的总内存，就是所有deamon 节点的内存之和；如果要在哪台机器上面汇总，就需要在那一台机器上的内存调大一些；我们了解到的，真正提供查询的是deamon,那么我们连接哪一台呢？Impala,你可以连接其中deamon 任何一个都行，可以根据自己的需求来
（1）当你查询的量相对大的时候，你就连接内存大的机器，
（2）当每台机器都适合查询的情况下也可以随机找一台机器，自己写一个轮询或者权重算法；解决高并发问题

Impalad：主要接收查询请求，接收client、hue、jdbc 或者odbc 请求、query 执行并返回给中心协调节点(对应的服务实例是impalad)子节点上的守护进程，负责向statestore 保持通信，汇报工作。

Imapala-Catalog：把impala表的metadata分发到各个impalad 中，说他是基于hive的，所以就需要metadata数据分到impalad中，以前没有此进程，就是手动来进行同步的。虽然之后加入了，但是也没有那么智能，并不是保证所有的数据都能同步，比如你插入一些数据，他可以把数据发到其他节点，但是比如创建表ddl 语句，建议去手动做一下。接收来自statestore 的所有请求，当impala deamon节点插入或者查询数据时候(数据改变的时候)，他把自己的操作结果汇报给state deamon,然后state store 请求catelog deamon，告知重新更新元数据信息给impalad 中，所以catalog deamon 与statedeamon 放到一台机器上，而且不建议在此机器上再去安装impala deamon 进程，避免造成提供查询造成集群管理出问题
Impala State Store：负责收集分布在集群中各个impalad 进程的资源信息，各节点健康状况、同步节点信息。负责query 的调度.(并非绝对，倘若他存在，那就帮忙，若不存在，那就不用他)对于一个正常运转的集群，并不是一个关键进程。
CLI：提供给用户查询使用的命令行工具（Impala Shell使用python实现），同时Impala还提供了Hue，JDBC， ODBC使用接口。
5、Impala的查询处理过程

1、Impalad分为Java前端与C++处理后端，接受客户端连接的Impalad即作为这次查询的Coordinator，Coordinator通过JNI调用Java前端对用户的查询SQL进行分析生成执行计划树，不同的操作对应不用的PlanNode, 如：SelectNode， ScanNode， SortNode， AggregationNode， HashJoinNode等等。

2、执行计划树的每个原子操作由一个PlanFragment表示，通常一条查询语句由多个Plan Fragment组成， Plan Fragment 0表示执行树的根，汇聚结果返回给用户，执行树的叶子结点一般是Scan操作，分布式并行执行。

3、Java前端产生的执行计划树以Thrift数据格式返回给Impala C++后端（Coordinator）（执行计划分为多个阶段，每一个阶段叫做一个PlanFragment，每一个PlanFragment在执行时可以由多个Impalad实例并行执行(有些PlanFragment只能由一个Impalad实例执行,如聚合操作)，整个执行计划为一执行计划树），由Coordinator根据执行计划，数据存储信息（Impala通过libhdfs与HDFS进行交互。通过hdfsGetHosts方法获得文件数据块所在节点的位置信息），通过调度器（现在只有simple-scheduler, 使用round-robin算法）Coordinator::Exec对生成的执行计划树分配给相应的后端执行器Impalad执行（查询会使用LLVM进行代码生成，编译，执行。对于使用LLVM如何提高性能这里有说明），通过调用GetNext()方法获取计算结果，如果是insert语句，则将计算结果通过libhdfs写回HDFS当所有输入数据被消耗光，执行结束，之后注销此次查询服务。

参考来自：https://www.cnblogs.com/Rainbow-G/articles/4282444.html参考来自：https://blog.csdn.net/wyz0516071128/article/details/81194712

1、impala的介绍

impala是cloudera提供的一款高效率的sql查询工具，提供实时的查询效果，官方测试性能比hive快10到100倍，其sql查询比sparkSQL还要更加快速，号称是当前大数据领域最快的查询sql工具。

2、impala与hive的关系

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

3、impala架构

1、Client(shell,jdbc,odbc)发送请求到impalad 进程上，发送节点可以是随机的，impalad 之间，也有相互通信
2、Statestore 和catelog 划到同一节点,目的就是这两个进程在协调工作时候，避免因网络问题造成失败
3、Hive metastore 是比较重要的，此时statestore 和catelog 通信，将数据同步到其他节点
4、Impalad 最好与hdfsDataNode 在同一节点，这样能更快速的查询计算，然后返回结果即可（理想状态的就是数据本地化）
Impalad 里面包含三个组件
Query planner（查询解析器）
将我们的字符串sql 语句解释成为执行计划，
Query coordinator（中心协调节点）
由这个组件来指定来查询的主节点（头），指定好之后通知其他节点我的主节点作用，待你们查询完成之后的结果，返回给头节点
Query executor（查询执行器）
而做查询工作的是就是executor

4、impala核心组件
对于impala 来讲，是没有主节点的，而要理解主节点，impala statestore 和catalog server两个角色，就具备集群调节的功能，根据以上的特点，对impala 进行配置优化配置impala 内存，每一个deamon 都需要配置内存，因为真正做查询工作的就是deamon 所在的节点，所以impala 的总内存，就是所有deamon 节点的内存之和；如果要在哪台机器上面汇总，就需要在那一台机器上的内存调大一些；我们了解到的，真正提供查询的是deamon,那么我们连接哪一台呢？Impala,你可以连接其中deamon 任何一个都行，可以根据自己的需求来
（1）当你查询的量相对大的时候，你就连接内存大的机器，
（2）当每台机器都适合查询的情况下也可以随机找一台机器，自己写一个轮询或者权重算法；解决高并发问题

Impalad：主要接收查询请求，接收client、hue、jdbc 或者odbc 请求、query 执行并返回给中心协调节点(对应的服务实例是impalad)子节点上的守护进程，负责向statestore 保持通信，汇报工作。

Imapala-Catalog：把impala表的metadata分发到各个impalad 中，说他是基于hive的，所以就需要metadata数据分到impalad中，以前没有此进程，就是手动来进行同步的。虽然之后加入了，但是也没有那么智能，并不是保证所有的数据都能同步，比如你插入一些数据，他可以把数据发到其他节点，但是比如创建表ddl 语句，建议去手动做一下。接收来自statestore 的所有请求，当impala deamon节点插入或者查询数据时候(数据改变的时候)，他把自己的操作结果汇报给state deamon,然后state store 请求catelog deamon，告知重新更新元数据信息给impalad 中，所以catalog deamon 与statedeamon 放到一台机器上，而且不建议在此机器上再去安装impala deamon 进程，避免造成提供查询造成集群管理出问题
Impala State Store：负责收集分布在集群中各个impalad 进程的资源信息，各节点健康状况、同步节点信息。负责query 的调度.(并非绝对，倘若他存在，那就帮忙，若不存在，那就不用他)对于一个正常运转的集群，并不是一个关键进程。
CLI：提供给用户查询使用的命令行工具（Impala Shell使用python实现），同时Impala还提供了Hue，JDBC， ODBC使用接口。
5、Impala的查询处理过程

1、Impalad分为Java前端与C++处理后端，接受客户端连接的Impalad即作为这次查询的Coordinator，Coordinator通过JNI调用Java前端对用户的查询SQL进行分析生成执行计划树，不同的操作对应不用的PlanNode, 如：SelectNode， ScanNode， SortNode， AggregationNode， HashJoinNode等等。

2、执行计划树的每个原子操作由一个PlanFragment表示，通常一条查询语句由多个Plan Fragment组成， Plan Fragment 0表示执行树的根，汇聚结果返回给用户，执行树的叶子结点一般是Scan操作，分布式并行执行。

3、Java前端产生的执行计划树以Thrift数据格式返回给Impala C++后端（Coordinator）（执行计划分为多个阶段，每一个阶段叫做一个PlanFragment，每一个PlanFragment在执行时可以由多个Impalad实例并行执行(有些PlanFragment只能由一个Impalad实例执行,如聚合操作)，整个执行计划为一执行计划树），由Coordinator根据执行计划，数据存储信息（Impala通过libhdfs与HDFS进行交互。通过hdfsGetHosts方法获得文件数据块所在节点的位置信息），通过调度器（现在只有simple-scheduler, 使用round-robin算法）Coordinator::Exec对生成的执行计划树分配给相应的后端执行器Impalad执行（查询会使用LLVM进行代码生成，编译，执行。对于使用LLVM如何提高性能这里有说明），通过调用GetNext()方法获取计算结果，如果是insert语句，则将计算结果通过libhdfs写回HDFS当所有输入数据被消耗光，执行结束，之后注销此次查询服务。

参考来自：https://www.cnblogs.com/Rainbow-G/articles/4282444.html参考来自：https://blog.csdn.net/wyz0516071128/article/details/81194712