Impala重要组件介绍

Impala重要组件

1.Impala Daemon

The core Impala component is a daemon process that runs on each DataNode of the cluster, physically represented by the impalad process.

Impala的核心组件是运行在各个节点上面的impalad这个守护进程（Impala daemon），它负责读写数据文件，接收从impala-shell、Hue、JDBC、ODBC等接口发送的查询语句，并行化查询语句和分发工做任务到Impala集群的各个节点上，同时负责将本地计算好的查询结果发送给协调器节点（coordinator node）。

你能够向运行在任意节点的Impala daemon提交查询，这个节点将会做为这个查询的协调器（coordinator node），其余节点将会传输部分结果集给这个协调器节点。由这个协调器节点构建最终的结果集。在作实验或者测试的时候为了方便，咱们每每链接到同一个Impala daemon来执行查询，可是在生产环境运行产品级的应用时，咱们应该循环（按顺序）的在不一样节点上面提交查询，这样才能使得集群的负载达到均衡。

Impala daemon不间断的跟statestore进行通讯交流，从而确认哪一个节点是健康的能接收新的工做任务。它同时接收catalogd daemon（从Impala 1.2以后支持）传来的广播消息来更新元数据信息，当集群中的任意节点create、alter、drop任意对象、或者执行INSERT、LOAD DATA的时候触发广播消息。

2.Impala Statestore

Impala Statestore检查集群各个节点上Impala daemon的健康状态，同时不间断地将结果反馈给各个Impala daemon。这个服务的物理进程名称是statestored，在整个集群中咱们仅须要一个这样的进程便可。若是某个Impala节点因为硬件错误、软件错误或者其余缘由致使离线，statestore就会通知其余的节点，避免其余节点再向这个离线的节点发送请求。

因为statestore是当集群节点有问题的时候起通知做用，因此它对Impala集群并非有关键影响的。若是statestore没有运行或者运行失败，其余节点和分布式任务会照常运行，只是说当节点掉线的时候集群会变得没那么健壮。当statestore恢复正常运行时，它就又开始与其余节点通讯并进行监控。

3.Impala Catalog

Imppalla catalog服务将SQL语句作出的元数据变化通知给集群的各个节点，catalog服务的物理进程名称是catalogd，在整个集群中仅须要一个这样的进程。因为它的请求会跟statestore daemon交互，因此最好让statestored和catalogd这两个进程在同一节点上。

catalog服务减小了REFRESH和INVALIDATE METADATA语句的使用。在以前的版本中，当在某个节点上执行了CREATE DATABASE、DROP DATABASE、CREATE TABLE、ALTER TABLE、或者DROP TABLE语句以后，须要在其它的各个节点上执行命令INVALIDATE METADATA来确保元数据信息的更新。一样的，当你在某个节点上执行了INSERT语句，在其它节点上执行查询时就得先执行REFRESH table_name这个操做，这样才能识别到新增的数据文件。

2、Impala的查询处理过程

如图是impala的查询处理过程。

3、查询计划

举个栗子

select count(*) from trace.apptalkselect count(*) from trace.apptalk

生成的执行计划

---------------- Estimated Per-Host Requirements: Memory=1.13GB VCores=1 WARNING: The following tables are missing relevant table and/or column statistics. trace.apptalk F01:PLAN FRAGMENT [UNPARTITIONED] 03:AGGREGATE [FINALIZE] | output: count:merge(*) | hosts=8 per-host-mem=unavailable | tuple-ids=1 row-size=8B cardinality=1 | 02:EXCHANGE [UNPARTITIONED] hosts=8 per-host-mem=unavailable tuple-ids=1 row-size=8B cardinality=1 F00:PLAN FRAGMENT [RANDOM] DATASTREAM SINK [FRAGMENT=F01, EXCHANGE=02, UNPARTITIONED] 01:AGGREGATE | output: count(*) | hosts=8 per-host-mem=10.00MB | tuple-ids=1 row-size=8B cardinality=1 | 00:SCAN HDFS [trace.apptalk, RANDOM] partitions=88/88 files=17578 size=67.11MB table stats: unavailable column stats: all hosts=8 per-host-mem=1.13GB tuple-ids=0 row-size=0B cardinality=unavailable---------------- Estimated Per-Host Requirements: Memory=1.13GB VCores=1 WARNING: The following tables are missing relevant table and/or column statistics. trace.apptalk F01:PLAN FRAGMENT [UNPARTITIONED] 03:AGGREGATE [FINALIZE] | output: count:merge(*) | hosts=8 per-host-mem=unavailable | tuple-ids=1 row-size=8B cardinality=1 | 02:EXCHANGE [UNPARTITIONED] hosts=8 per-host-mem=unavailable tuple-ids=1 row-size=8B cardinality=1 F00:PLAN FRAGMENT [RANDOM] DATASTREAM SINK [FRAGMENT=F01, EXCHANGE=02, UNPARTITIONED] 01:AGGREGATE | output: count(*) | hosts=8 per-host-mem=10.00MB | tuple-ids=1 row-size=8B cardinality=1 | 00:SCAN HDFS [trace.apptalk, RANDOM] partitions=88/88 files=17578 size=67.11MB table stats: unavailable column stats: all hosts=8 per-host-mem=1.13GB tuple-ids=0 row-size=0B cardinality=unavailable