本篇内容主要讲解“Impala的组件和架构有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Impala的组件和架构有哪些”吧!
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类型的作业。
为了避免延迟，impala绕过MapReduce，采用了与商用并行关系数据库类似的分布式查询引擎，可以直接与HDFS和HBase进行交互查询，性能上比Hive要快。
Impala server 是一个分布式的大规模并行处理(MPP)的数据库引擎， 它由运行在集群中特定主机上的不同守护进程组成。其架构图如下图所示：
这个进程是运行在集群每个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), 能够提高大型集群上高并发工作负载的可扩展性。
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服务。
当impala集群中执行的SQL语句会引起元数据变化时，catalog服务会将这些变化推送到其他的impalad进程节点上。catalog服务对应的进程名称为catalogd，一个impala集群只需要一个catalogd进程 。由于所有的请求都是通过statestore进程发送过来的，所以建议让statestore和catalog运行在同一个节点上。
catalog服务大大地减少了对 REFRESH / INVALIDATE METADATA 语句的元数据同步的需求。在创建和删除表的过程中，catalogd进程负责连接元数据库并进行元数据更新操作，从而确保不必执行REFRESH / INVALIDATE METADATA这样的元数据同步语句。但是，如果通过Hive执行了创建表 、加载数据等操作，则在impala中执行查询之前需要先执行 REFRESH或者INVALIDATE METADATA 命令。
第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客户端。
Hive与Impala使用相同的存储数据池，都支持把数据存储于HDFS和HBase中
Hive与Impala使用相同的元数据
Hive与Impala中对SQL的解释处理比较相似，都是通过词法分析生成执行计划
Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询
Hive依赖于MapReduce计算框架，Impala把执行计划表现为一棵完整的执行计划树，直接分发执行计划到各个Impalad执行查询
Hive在执行过程中，如果内存放不下所有数据，则会使用外存，以保证查询能顺序执行完成，而Impala在遇到内存放不下数据时，不会利用外存，所以Impala目前处理查询时会受到一定的限制
到此，相信大家对“Impala的组件和架构有哪些”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
