Impala的组件和架构有哪些

一、概述

1.1简介

Impala是由Cloudera公司开发的新型查询系统，能够对存储在HDFS、HBase以及S3上的数据进行快速的交互式SQL查询。另外，impala与Hive使用了统一的存储系统、同样的元数据库、SQL语法(Hive SQL)、ODBC驱动和用户交互接口(Hue)，Impala对实时的或者面向批处理的查询提供了一个统一的平台，Impala在性能上比Hive高出3~30倍。

Impala是用于查询大数据的工具的补充，Impala不是取代构建在MapReduce之上的批处理框架，比如Hive。Hive和其他的基于MapReduce的框架适合处理长时间运行的批处理作业，比如涉及到批处理的ETL类型的作业。

1.2优势

• 使用的是数据科学家和分析师熟悉的SQL接口
• 能查询大数据集
• 是集群环境中的分布式查询，便于扩展和使用廉价商用硬件
• 能够在不同的分析引擎之前共享数据，比如可以通过pig写数据，使用Hive转换数据，再使用impala查询数据。impala能够读写hive中的表，使用impala对Hive生成的数据进行分析，实现简单的数据交换
• 单一系统用于大数据处理和分析，因此可以避免成本高昂的建模和ETL.

1.3主要特点

• 支持Hive查询语言（HiveQL）最常见的SQL-92功能，包括 SELECT, JOIN和聚合函数
• 支持HDFS, HBase和S3存储, 包括:
• HDFS 文件格式: delimited text files, Parquet, Avro, SequenceFile,和 RCFile.
• 压缩: Snappy, GZIP, Deflate, BZIP.
• 常见的数据访问接口，包括JDBC driver、ODBC driver
• 支持impala-shell命令行接口
• Kerberos授权

二、Impala架构

为了避免延迟，impala绕过MapReduce，采用了与商用并行关系数据库类似的分布式查询引擎，可以直接与HDFS和HBase进行交互查询，性能上比Hive要快。

Impala server 是一个分布式的大规模并行处理(MPP)的数据库引擎， 它由运行在集群中特定主机上的不同守护进程组成。其架构图如下图所示：

2.1Impala Daemon

这个进程是运行在集群每个DataNode节点上的守护进程，是impala的核心组件。在每个节点上这个进程的名字称为impalad。主要负责读写数据，接受 impala-shell，Hue, JDBC或者ODBC的查询请求，与集群中的其他节点分布式并行工作，并将本节点的查询结果返回给中心协调者节点(central coordinator)。

我们可以向运行在DataNode上的任何impalad进程提交一个查询，提交查询的这个节点将作为这个查询的"协调者节点"(coordinator)为这个查询提供服务。其他节点的运算结果会被传输到协调者节点，协调者节点将最终的运算结果返回。当使用 mpala-shell命令进行功能性测试的时候,为了方便起见，我们总是会连接到同一个节点上的impalad。但是对于生产环境中的impala集群而言，必须要考虑到各个节点的负载均衡，建议使用JDBC/ODBC接口以轮询(round-robin)的方式提交到不同的impalad进程上。

为了了解其他节点的健康状况和负载，Impalad进程会一直与 statestore保持通信，用以确保哪个节点是健康的并且可以接受任务的。

当impala集群中创建，修改或者删除了对象，或者进行了INSERT/LOAD DATAT操作，catalogd进程会向所有的节点广播消息，以保证每个impalad节点都能够及时地了解整个集群中对象元数据的最新状态。后台进程间的通信最大限度的降低了对 REFRESH/INVALIDATE METADATA命令的依赖。(但是对于和impala1.2版本之前的节点通信，还是需要显示指定)

对impala 2.9或者更高版本，可以控制哪一个节点为查询协调器( query coordinators ),也可以控制哪一个节点为查询协调器(query executors), 能够提高大型集群上高并发工作负载的可扩展性。

2.2Impala Statestore

statestore检查集群中impalad进程节点的健康状况，并不断地将健康状况结果转发给所有的impalad进程节点。statestore进程的名称为statestored。一个impala集群只需要一个statestored进程，如果impala节点由于硬件故障、网络错误、软件问题或者其他的原因导致节点不可用，statestore将确保这条信息及时地传达到所有的impalad进程节点上，当有新的查询请求时 ,impalad进程节点将不会把查询请求放松到不可用的节点上。

由于statestore的目的是在集群故障时对impalad进程节点同步信息，所以对于一个正常运行的impala集群来说，它并不是一个关键进程。如果statestore不可用，impalad进程节点之间仍然可以相互协调正常对外提供分布式查询。在statestore不可用的情况下，impalad进程节点失败，只是会让集群不再那么强健。当statestore恢复正常时，它重新与impalad进程节点建立通信，恢复对集群的监控功能。

对于负载平衡和高可用性都适用于impalad守护进程。statestore和catalog进程对高可用性没有特殊要求，因为即便这些守护进程存在问题，也不会导致数据丢失。如果这些守护进程因中断而变得不可用，则可以停止impala服务，删除impala StateStore和impala Catalog角色，将角色添加到不同的主机上，并重新启动impala服务。

2.3Impala Catalog Service

当impala集群中执行的SQL语句会引起元数据变化时，catalog服务会将这些变化推送到其他的impalad进程节点上。catalog服务对应的进程名称为catalogd，一个impala集群只需要一个catalogd进程 。由于所有的请求都是通过statestore进程发送过来的，所以建议让statestore和catalog运行在同一个节点上。

catalog服务大大地减少了对 REFRESH / INVALIDATE METADATA 语句的元数据同步的需求。在创建和删除表的过程中，catalogd进程负责连接元数据库并进行元数据更新操作，从而确保不必执行REFRESH / INVALIDATE METADATA这样的元数据同步语句。但是，如果通过Hive执行了创建表 、加载数据等操作，则在impala中执行查询之前需要先执行 REFRESH或者INVALIDATE METADATA 命令。

三、Impala查询的执行过程

3.1Impala查询过程图

3.2Impala执行查询的具体过程

第0步，当用户提交查询前，Impala先创建一个负责协调客户端提交的查询的Impalad进程，该进程会向Impala State Store提交注册订阅信息，State Store会创建一个statestored进程，statestored进程通过创建多个线程来处理Impalad的注册订阅信息。

第1步，用户通过CLI客户端提交一个查询到impalad进程，Impalad的Query Planner对SQL语句进行解析，生成解析树；然后，Planner把这个查询的解析树变成若干PlanFragment，发送到Query Coordinator

第2步，Coordinator通过从MySQL元数据库中获取元数据，从HDFS的名称节点中获取数据地址，以得到存储这个查询相关数据的所有数据节点。

第3步，Coordinator初始化相应impalad上的任务执行，即把查询任务分配给所有存储这个查询相关数据的数据节点。

第4步，Query Executor通过流式交换中间输出，并由Query Coordinator汇聚来自各个impalad的结果。

第5步，Coordinator把汇总后的结果返回给CLI客户端。

四、Impala与Hive的比较

4.1Impala与Hive对比图

4.2Hive与Impala的相同点

• Hive与Impala使用相同的存储数据池，都支持把数据存储于HDFS和HBase中

• Hive与Impala使用相同的元数据

• Hive与Impala中对SQL的解释处理比较相似，都是通过词法分析生成执行计划

4.3Hive与Impala的不同点

• Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询

• Hive依赖于MapReduce计算框架，Impala把执行计划表现为一棵完整的执行计划树，直接分发执行计划到各个Impalad执行查询

• Hive在执行过程中，如果内存放不下所有数据，则会使用外存，以保证查询能顺序执行完成，而Impala在遇到内存放不下数据时，不会利用外存，所以Impala目前处理查询时会受到一定的限制