Impala源码解析（1）——概念与架构

写在前面：

Impala作为基于内存的MPP数据库，底层是HDFS，能够快速响应SQL查询。接下来一系列文章是综合网上其他blog和自己看源码整理，旨在的解析Impala内核，为自己开发借鉴经验。有错误之处，还望指正！

资料：

Impala官网：http://impala.io/index.html

cloudera Impala：http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/impala.html

概念与架构

原网站：http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/impala_concepts.html

Impala守护进程

Impala核心成员是一个运行在集群中每一个节点上的守护进程，物理表示为impalad进程。

负责数据文件的读写；

从impala-shell命令行、Hue、JDBC或者ODBC接收并转化查询；

并行查询和给集群中其他节点分配任务；

把查询中间结果传输到中心协调节点。

你可以给运行在任何一个结点上的守护进程提交查询，那个节点就作为所提交查询的协调节点。

其他节点把中间部分查询结果传输到协调者节点，然后协调者节点为所提交的查询构造最后完整的结果。当通过impala-shell命令行运行功能性实验，为了方便，你可能一直都是连接到相同的impala守护进程。对于运行生产线上的工作，你可能需要在不同节点间做负载均衡，通过JDBC、ODBC按照round-robin的形式向不同的impala进程提交查询。

impalad守护进程频繁的跟statestore进程通信，确保哪些节点健康以及能够接受新的任务。

他们也接收来自catalogd守护进程的广播信息，一旦任何集群中的impala节点create，alter或者drop任何类型的对象，或者当INSERT或者LOADDATA语句在impala中运行。这个后台通信减少REFRESH或者INVALIDATEMETADATA语句，后者优先在Impala必须用于在节点中同步元数据。

Statestore

impala中statestore进程检测集群中每一个节点上Impala守护进程的健康程度，并且不断的把它的发现转发给这里的每一个进程。物理表示为statestored进程；你只需要在集群中的一个节点上运行这样的进程。如果一个impala节点由于硬件故障、网络错误、软件事故、或者其他原因造成离线，这个statestore通知所有其他节点，所以后来的查询避免发送到这些不能到达的节点。

因为statestore进程的目的是当出错的时候起作用，对impalajiqun中平常的操作不重要。如果statestore不运行或者变得不可达，其他节点照常继续运行并且在他们之间分配任务；如果有些节点在statestore离线的情况下出错，这个集群的鲁棒性下降。当这个statestore恢复到在线，它从新跟其他节点建立通信并且恢复它的监视功能。

catalog服务

catalog服务将来自Impalasql语句修改元数据的信息转发给集群中的所有其他节点。物理表示为catalogd守护进程；你只需要在集群中的一个节点上运行这个进程。因为这个请求是通过statestore守护进程，有意义将statestored和catalogd服务运行在同一个节点。

这个在Impala1.2引入的新成员减少REFRESH和INVALIDATEMETADATA语句的必要。正式来说，如果你在一个Impala节点上发起CREATEDATABASE,DROPDATABASE, CREATETABLE, ALTERTABLE,or DROPTABLE语句，需要REFRESH和INVALIDATEMETADATA语句。但是如果在Hive上ddl，那么还是需要REFRESH和INVALIDATEMETADATA语句。（有改动）

以下是sql执行流程图：

注：

关于statestore和catalog只需要运行在集群中的一个结点，并且转发信息，应该可以理解为这两个进程是信息中心，通过它1：N的形式广播信息。通过statestore的订阅发布模式转发给其他节点。statestore只是搜集心跳信息，那么心跳应该是impalad进程发送的。