impala 核心组成部分之一 impalad ,它是impala的一个启动进程.impalad 运行在集群中的每一个独立节点机器上。应用impala必须启动impalad进程。
impalad 负责读写数据文件，接受来自impala-shell发送的sql 、command 、Hue、JDBC、ODBC请求，并行执行查询和分布式工作在集群节点上,也负责传输汇总查询的结果返回 协调器节点上。用户可以在任何集群节点上提交查询请求。
用户在impala集群上的 某个节点提交数据处理请求 则该节点称为 coordinator node （协调器 节点）,其他的集群节点传输其中的部分处理数据到该coordinator node，coordinator node 负责构建最终的结果数据返回给用户。当用户通过impala-shell 提交函数的时候，也可以很方便的连接到同样的impalad 进程。
impala 支持在提交任务的时候(采用JDBC ,ODBC 方式) 采用round-robin 算法来实现负载均衡,将任务提交到不同的 节点上,构建不同的 coordinator node
impalad 进程通过持续的和statestore 通信来确认自己所在的节点是否健康 和是否可以接受新的任务请求
Statestore
impala 的另一个核心组件statestore 负责检测整个集群中所有节点上的进程的健康度,statstore 通过连续不断的分发findings 到每一个节点上的进程。statstore 的物理进程名称为 statestored,
一个impala 集群上 仅需要一个这样的进程,如果impala 集群中有一个节点因为 硬件故障或是网络错误、软件问题、或是其他 的原因导致该节点不可用,则statestore通知所有集群中其他的节点，以便在新任务提交的时候可以避免将新任务分发到该故障节点。
由于statestore 的应用场景是在集群发生故障的时候通知集群中其他的正常的节点 在新的任务到来时 可避免任务发送到故障 的不可达的节点上,因此statestore 不是关键的操作。如果statestore 没有运行或是连接不上，其他的节点则仍可以继续运行和分布式的分发和处理任务,尽是集群的鲁棒性 上收到一些影响。当statestore 恢复的时候 则会继续和其他的节电通信然后恢复其监控函数
impala sql
impala sql 和hive sql 是相似的，基本可以通用
1.impala sql 没有update和delete 语句。脏数据或是过期的数据可以通过drop table 或是alter table 、drop partition 或是replaced 去操作
2.数据采用insert 的方式被导入。有两种insert 方式 其中insert into 是往已经存在的数据上 append .insert overwrite 则是覆盖原有的数据
3.元数据可以和hadoop 生态系统中其他的数据仓库软件共享.如 Hive 。impala 于Hive 共享元数据
4.impala 数据类型 没有字段长度的定制 String ,这点和Hive是一样的
impala 的接口
1.impala-shell 2.hue web interface 3.JDBC 4.ODBC
运行在集群独立节点上的impala 进程 监听几个常用的处理请求的端口。其中impala-shell 和Hue 被路由到impalad 的时候是通过同一个端口,impalad 处理JDBC 和ODBC 是采用不同的端口。
impala 的端口应用 详见：
http://www.cloudera.com/content/cloudera-content/cloudera-docs/Impala/latest/Installing-and-Using-Impala/ciiu_ports.html?scroll=topic_ports
impala 元数据
impala 的每一个节点都cache 有元数据,避免每次请求都直接去公共的元数据存储库中查询。如果每次都去元数据的存储库中
查询 则当表的体积特别大,含有的分区和列特别多的时候 会耗费大量的时间。
如果表的schema 或是数据被更改了,则所有的impalad 都需要重新更新metastore 去替换老的metastore
应用REFRESH 命令去更新元数据。默认为自动的执行REFRESH ，如果我们知道某一个表被改变了 则我们也可以手动的执行
REFRESH table_name
来主动做这件事情。