解析Impala架构



1. Impala综述

Impala是架构于Hadoop之上的开源、高并发的MPP查询引擎，被广泛应用于各种行业。Impala是完全集成的，用以平衡Hadoop的灵活性和可扩展性，为BI／数据分析师提供低延迟、高并发的以读为主的查询。

它将传统分析数据库的SQL支持和多用户性能与Hadoop的灵活性和可扩展性结合起来，它通过利用HDFS、HBase、Metastore、YARN、Sentry等标准组件能够读取大多数广泛使用的文件格式比如Parquet、Avro、RCFile来维护Hadoop的灵活性；为了降低延迟，避免利用MR或者读远程数据，基于负责查询执行所有方面、作为Hadoop基础设施一部分运行于各台服务器上的Deamon进程实现了一个分布式架构，在相同负载的情形下其性能相当或超过了商用MPP分析数据库。

 

2. 用户视图

Impala意图与标准的BI环境集成，因此支持几乎所有的工业标准：客户端通过ODBC或JDBC连接服务器、通过Kerberos或LDAP实现认证、遵循标准的SQL角色和权限实现权限管理。

有用例证实，Impala的性能可以达到80Query／S，在秒级内可以同时支持1000+仪表盘终端用户。

 

3. 架构

Impala是海量并发的查询执行引擎，运行在现存Hadoop集群的上百台机器上。他与传统数据库不同，它与底层存储引擎解耦。它由三种服务构成：

Impalad，ImpalaDaemon Service承担双重责任，接收客户端查询请求并精心安排在集群上执行他们，同时执行从其他Daemon发来的单个执行片段。对于某一查询，作为第一角色管理的Daemon称为协调者，Impala是对称的，他们均承担所有角色，这些特点有助于容错和负载均衡。它部署在集群中运行datanode进程的所有机器上，可允许impala利用数据本地化的特点而不必通过网络传输即可在文件系统中读取数据块。

Statestored是impala的元数据订阅－发布服务，他是单一实例，将集群元数据传播到所有的Impala进程。

Catalogd，Impala的目录资源库和元数据访问网关，通过它，Impalad可执行DDL命令且与外部元数据存储如HiveMetastore同步，系统目录的改变将由Statestored广播。

3.1 Statestored

MPP数据库设计的一大挑战是在集群上的节点间实现协调和元数据同步，impala对称的节点架构要求所有的节点必须都能够接收并执行查询，因此所有节点必须有系统目录的当前版本和集群成员关系的当前视图以使得查询能够得到正确调度。

Statestore维护一组topic，他们是一个三元数组<key,value,version>，每一元素称为entry，其中key、value是字节数组，version是64位整数。一个topic为其中一应用所定义，因此Statestore无须理解任何topicentry的内容，topic通过Statestore的生命期持久化。

接收topic更新的进程称为订阅者，他们到Statestore注册并在其提供的一系列topic中选择自己需要的，Statestore通过发送给订阅者所订阅topic的当前更新作为响应。

注册之后，Statestore定期为每个订阅者发送两种消息，一是topic的更新，包含自上次成功发送给订阅者之后的所有更新，包括entry的增、删、改，每个订阅者维护每一topic最新版本的标识从而使得Statestore仅仅发送更新之间的增量数据。同时，每个订阅者为响应topic的更新，将发送其订阅topic的一系列更改，这些更改将在接收下一次更新时被应用。

另一种消息是keepalive，Statestore利用这一消息维护和每一订阅者的连接，如果超时则将重新注册。

上述Statestore利用topic更新信息与订阅者通讯，但是随着更新的信息变得越来越大，使得及时将更新传递给每个订阅者变得困难，将导致在订阅者失败检测进程中存在误报。一旦Statestore检测到失败的订阅者将终止发送更新，一些topic的entry将被标识为‘临时的’（transient），它们将被移除。

Statestore提供很弱的语义，订阅者以不同的速率被更新，则导致同一topic具有不同的视图，不过Impala仅仅利用本地的topic元数据做决策并不在整个集群中进行协同。

Statestore并不持久化任何元数据到磁盘上，所有当前元数据通过活跃的订阅者**给Statestore，一旦重启，它的内容将在订阅者初始化注册阶段被恢复。如果运行Statestore的机器挂掉了，一个新的Statestore进行将被启动起来，Impala没有内置的故障转移机制，它利用DNS可重定向性迫使所有订阅者自动转移到新的Statestore进程实例。

3.2 Catalogd

Catalogd，从第三方元数据存储中拉数据并汇总为impala兼容的目录结构，这种架构使得Impala对它所依赖的存储引擎的元数据相对的不可知，这允许我们相对快的增加新的元数据存储。系统元数据目录的任何改变均通过Statestore广播。Catalogd也允许我们在系统元数据目录中增加Impala自定制的信息，比如UDF。

既然元数据目录一般很大，则对表的访问很少统一，Catalogd仅仅载入每张表的概略信息，更为详细的信息将由后台进程在第三方存储中延迟载入，在一张表未被完全载入时请求该表则被优先处理直到被完全载入。

4. 前端

Impala前端负责将SQL编译为可执行的查询计划，由Java开发，它由SQL解析器、基于成本的优化器组成。除去基本的SQL操作，它还支持内联视图、关联或非关联子查询、各种外连接、semi-/anti-连接、窗口分析函数。查询编译遵循传统的划分：查询解析、语义分析、查询计划／优化。最大挑战来自计划器，它将执行计划组织为两个阶段，（1）单点计划（2）计划并行和分割。

第一阶段，将解析树转换为不能执行的单点计划树，包括如下计划内容：HDFS／HBase扫描、hashjoin、crossjoin、union、hashaggregation、sort、top-n和分析评估。它负责基于评估推断断言，将断言赋予最低层可能的节点，根据分区剪枝、设置限制／偏移、实施列的投影并完成一些基于成本的优化比如排序、合并分析窗口函数和join重排序以最小化总成本。成本评估基于表／分区的基加上每列的非重复值的总计，Impala用简单的启发式算法避免枚举和在join-order空间的成本。

第二阶段，将单个节点的计划转换为一个分布式的执行计划，基本的目标在于最小化数据移动和最大化本地数据扫描，此计划通过在计划节点间增加必要的交换节点实现分布式，通过增加额外的非交换节点最小化网络间的数据移动，在此阶段，为每个join决定join策略，被支持的join策略被广播和分区，前者复制join的整个build端至整个集群执行probe，后者则通过hash重分布join的build和probe端。Impala选择哪种策略基于对最小化网络间数据交换的评估并发掘join输入的数据分区。

5. 后端

从前端接收查询片段并充分利用现在硬件快速执行，由C++实现并利用执行时生成代码产生有效的codepath并相较于用java实现的其他引擎占用很少的内存。

执行引擎是传统的Volcano-style加上交换运算符。处理以每次一批的方式实现，GetNext()获取一批行记录，元组以行式格式在内存处理。

需要消耗大量内存的操作比如hashjoin、aggregation、排序和分析函数评估被设计可以分片且将工作集进行spill在必要时写到磁盘。Impala为hashjoin 和聚合操作采用分区方法，每一元组hash值的部分bit决定分区，其他bit为hash表 probe。当有内存压力时，作为牺牲者，一些分区将被spill到磁盘，为其他分区空出内存以完成处理。当为hashjoin构建hash表则带来build端关联基数的减少，构建一个Bloom过滤器并转给probe端扫描器来实现semi-join的简单版本。

6. IO管理

有效检索HDFS上的数据是所有SQL-On-Hadoop的一大挑战，为了实现以接近硬件的速度从磁盘、内存扫描数据，Impala利用称为short-circuitlocal reads 的HDFS特性在读取本地磁盘时忽视DataNode协议，Impala以近磁盘带宽的速度读取数据并使得所有可用磁盘以一般状态达到饱和点，12块磁盘，则可达到1.2GB／S，IO管理者在每块物理磁盘上设置固定数量的工作线程，为Client端提供非同步接口。

7. 资源／工作负载管理

集群框架的一大主要挑战是资源消耗的周到控制，Impala经常运行于繁忙集群的上下文中，MR、导入数据任务、其他类型的任务等竞争使用固定的内存、磁盘和网络带宽。困难在于在查询间或者不同任务间协调资源调度而无须在延迟和吞吐间折中。

Yarn是Hadoop集群资源协调的当前标准，允许在不同任务间共享诸如内存、CPU等资源而无须划分集群，Yarn有一个集中式架构，由RM来响应CPU和内存资源的请求，这种架构在了解集群所有资源状态的前提下做出分配决定，但存在显著的延迟，而Impala的目标在于每秒响应成千上万的查询，需要解决资源请求和响应之间存在的过长延迟。

解决这个问题综合两个方面，首先，实现1个互补的、独立的准允控制机制来允许用户不需集中式的做出决定而控制自己的负载，再次，在Impala和Yarn之间设计一个调节服务，称之为Llama，即Low-LatencyApplication Master，实现资源缓存、调度和递增式的改变分配，同时未能hit中Llama缓存的资源则延迟等待Yarn的调度决定。

Llama是一个独立的Daemon进程，每一查询先将资源需求发送给它，如资源在其cache中则立即分配，否则转给Yarn，Impala管道执行模式须所有资源同时到位，执行计划对资源估计慢慢校准，Yarn不支持资源需求更改，Llama汇总后提交给Yarn。

准允控制

除去将YARN作为集群资源管理，Impala还有一个内置的准允控制机制来限制不断到来的请求。资源请求被分配给一个资源池并基于每个资源池的最大并行请求数和最大内存请求限制被允许、拒绝或等待。准允控制器被设置为快速、非集中化，以至于每个Impalad可以接受到来的请求而非**服务器的异步请求。

资源池是层次化定义的，新请求基于分配策略和ACL控制对资源池的访问被分配到一资源池。