Impala 基本架构

Impala 最初是由 Cloudera 公司开发的，其最初设计动机是充分结合传统数据库与大数据系统 Hadoop 的优势，构造一个全新的、支持 SQL 与多租户、并具备良好的灵活性和扩展性的高性能查询引擎。

Impala 采用了对等式架构，所有角色之间是对等的，没有主从之分。Impala 主要由三类服务组件构成，分别为 Catalogd、Statestored 和 Impalad。

• Catalogd：元信息管理服务。它从 hive metastore 中同步表信息，并将任何元信息的改变通过 catalogd 广播给各个 Impalad 服务。需要注意的是，在一个大数据数据仓库中，元数据一般很大，不同数据表的访问频度不同，为此，Catalogd 仅仅载入每张表的概略信息，更为详细的信息将由后台进程从第三方存储中延迟载入。

• Statestored：状态管理服务器。元数据订阅-发布服务，它是单一实例（存在单点故障问题），将集群元数据传播到所有的 Impalad 进程。MPP 数据库设计的一大挑战是实现节点间协调和元数据同步，Impala 对称的节点架构要求所有的节点必须都能够接收并执行查询，因此所有节点必须有系统目录结构的最新版本和集群成员关系的当前视图，而 Statestored 正是负责以上这些功能，即将所有元信息及其修改同步到各个 Impalad。

• Impalad，同时承担协调者和执行者双重角色。首先，对于某一查询，作为协调者，接收客户端查询请求并对其进行词法分析、语法分析、生成逻辑查询计划以及物理查询计划，之后将各个执行片段（segement）调度到 Impalad 上执行；其次，接收从其他 Impalad 发过来的单个执行片段，利用本地资源（CPU、内存等）处理这些片段，并进一步将查询结果返回给协调者。Impalad 一般部署在集群中运行 Datanode 进程的所有机器上，进而利用数据本地化的特点而不必通过网络传输即可在文件系统中读取数据块。

Impala 前端负责将 SQL 编译为可执行的查询计划，它由 SQL 解析器、基于成本（cost-based）的优化器组成。它的查询编译阶段遵循经典的实现方式：分为查询解析、语义分析、查询计划/优化等几个模块。最大挑战来自查询计划器，它将执行计划为两个阶段：单点计划；计划并行和分割。

第一阶段，将解析树转换为单点计划树，这包括如下内容：HDFS/HBase 扫描、hashjoin、crossjoin、union、hash 聚集、sort、top-n 和分析评估等。它基于分析评估结果，进行谓词下推、相关列投影、分区剪枝、设置限制（limit）/偏移并完成一些基于成本的优化比如排序、合并分析窗口函数和 join 重排序等。

第二阶段，将单个节点的计划转换为分布式的执行计划，基本目标在于最小化数据移动和最大化本地数据扫描，它通过在计划节点间增加必要的交换节点实现分布式，通过增加额外的非交换节点最小化网络间的数据移动，在此阶段，生成物理的 join 策略。Impala 支持两种分布式 join 方式，表广播（broadcast）和哈希重分布（parittioned）：表广播方式保持一个表的数据不动，将另一个表广播到所有相关节点；哈希重分布的原理是根据 join 字段哈希值重新分布两张表数据。

在 Impala 中，分布式计划中的聚集函数会被分拆为两个阶段执行。第一阶段：针对本地数据进行本地分组聚合以降低数据量，并进行数据重分布；第二阶段：进一步汇总之前的局部聚集结果计算出最终结果。