impala架构和工作原理

1 Impala概述

1.1 什么是Impala

（1）Cloudera公司推出，提供对HDFS、Hbase数据的高性能、低延迟的交互式SQL查询功能；
（2）基于Hive使用内存计算，兼顾数据仓库、具有实时、批处理、多并发等优点；
（3）是CDH平台首选的PB级大数据实时查询分析引擎。

1.2 Impala优点

（1）基于内存进行计算，能够对PB级数据进行交互式实时查询和分析；
（2）无需转换为MR、直接读取HDFS数据；
（3）C++编写，LLVM统一编译运行【LLVM是构架编译器(compiler)的框架系统，以C++编写而成，用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(run-time)以及空闲时间(idle-time)，对开发者保持开放，并兼容已有脚本】；
（4）兼容Hive SQL；
（5）具有数据仓库的特性，可对Hive数据直接做数据分析；
（6）支持数据的本地化；
（7）支持列式存储；
（8）支持JDBC/ODBC远程访问。

1.3 Impala劣势

（1）对内存依赖性大；
（2）完全依赖于Hive；
（3）实践过程中，分区超过1w，性能严重下降；
（4）稳定性不如Hive；
（5）每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新。

2 Impala架构

      Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具（实时SQL查询引擎Impala），Impala没有再使用缓慢的Hive+MapReduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟。

2.1 Impala核心组件

（1）Impala Daemon（最核心，实例*N - Impalad）
      ① 接收client、hue、jdbc或者odbc请求、Query执行并返回给中心协调节点；
      ② 子节点上的守护进程，负责向statestore保持通信，汇报工作。

（2）StateStore Daemon（实例*1 - statestored）
      ① 负责收集分布在各个Impalad进程的资源信息、各节点健康状况，同步节点信息；
      ② 负责Query的调度。

（3）Catlog Daemon（实例*1 - catalogd）
      ① 分发表的元数据信息到各个Impalad中；
      ② 接收来自StateStore的所有请求。
      首先，由上可知，StateStore和Catalog是需要通信的，所以，搭建时，这两个是放在一台主机上，从而使之通信不需走网络请求。

2.2执行流程

      客户端（SQL APP、ODBC）发送SQL请求至Query Planner，解析后送至Query Coordinator进行负载均衡的一个调度（当前的Query Coordinator将作为整个job的leader），分发到不同的Impala进程，并最终通过各个Query Executor来执行查询，最后将执行结果送回Query Coordinator（leader），返回给客户端。
      Impala的数据是存储在HDFS或者HBase中，所以，Impalad进程与DataNode部署在一台机器上。

2.3 Dremel概述

      Dremel是Google的交互式数据分析系统，它构建于Google的GFS（Google File System）等系统之上，支撑了Google的数据分析服务BigQuery等诸多服务。Dremel的技术亮点主要有两个：一是实现了嵌套型数据的列存储；二是使用了多层查询树，使得任务可以在数千个节点上并行执行和聚合结果。列存储在关系型数据库中并不陌生，它可以减少查询时处理的数据量，有效提升查询效率。Dremel的列存储的不同之处在于它针对的并不是传统的关系数据，而是嵌套结构的数据。Dremel可以将一条条的嵌套结构的记录转换成列存储形式，查询时根据查询条件读取需要的列，然后进行条件过滤，输出时再将列组装成嵌套结构的记录输出，记录的正向和反向转换都通过高效的状态机实现。另外，Dremel的多层查询树则借鉴了分布式搜索引擎的设计，查询树的根节点负责接收查询，并将查询分发到下一层节点，底层节点负责具体的数据读取和查询执行，然后将结果返回上层节点。

3 与Hive的关系

      Impala与Hive都是构建在Hadoop之上的数据查询工具各有不同的侧重适应面，但从客户端使用来看Impala与Hive有很多的共同之处，如数据表元数据、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。Impala与Hive在Hadoop中的关系下图所示。Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询，Impala给数据分析人员提供了快速实验、验证想法的大数据分析工具。可以先使用Hive进行数据转换处理，之后使用Impala在Hive处理后的结果数据集上进行快速的数据分析。

3.1 Impala相对于Hive所使用的优化技术

（1）没有使用MapReduce进行并行计算，虽然MapReduce是非常好的并行计算框架，但它更多的面向批处理模式，而不是面向交互式的SQL执行。与MapReduce相比：Impala把整个查询分成一执行计划树，而不是一连串的MapReduce任务，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce启动时间。
（2）使用LLVM产生运行代码，针对特定查询生成特定代码，同时使用Inline的方式减少函数调用的开销，加快执行效率。
（3）充分利用可用的硬件指令。
（4）更好的IO调度，Impala知道数据块所在的磁盘位置能够更好的利用多磁盘的优势，同时Impala支持直接数据块读取和本地代码计算checksum。
（5）通过选择合适的数据存储格式可以得到最好的性能（Impala支持多种存储格式）。
（6）最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递。

3.2 Impala与Hive的异同

3.2.1 相同点

（1）数据存储：使用相同的存储数据池都支持把数据存储于HDFS, HBase。
（2）元数据：两者使用相同的元数据。
（3）SQL解释处理：比较相似都是通过词法分析生成执行计划。

3.2.2 不同点

（1）执行计划
      ① Hive: 依赖于MapReduce执行框架，执行计划分成map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。
      ② Impala: 把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。
（2）数据流
      ① Hive: 采用推的方式，每一个计算节点计算完成后将数据主动推给后续节点。
      ② Impala: 采用拉的方式，后续节点通过getNext主动向前面节点要数据，以此方式数据可以流式的返回给客户端，且只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用。
（3）内存使用
      ① Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。
      ② Impala: 在遇到内存放不下数据时，版本0.1是直接返回错误，而不会利用外存，以后版本应该会进行改进。这使用得Impala目前处理Query会受到一定的限制，最好还是与Hive配合使用。Impala在多个阶段之间利用网络传输数据，在执行过程不会有写磁盘的操作（insert除外）。
（4）调度
      ① Hive: 任务调度依赖于Hadoop的调度策略。
      ② Impala: 调度由自己完成，目前只有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器目前还比较简单，在SimpleScheduler::GetBackend中可以看到，现在还没有考虑负载，网络IO状况等因素进行调度。但目前Impala已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度吧。
（5）容错
      ① Hive: 依赖于Hadoop的容错能力。
      ② Impala: 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误（这与Impala的设计有关，因为Impala定位于实时查询，一次查询失败，再查一次就好了，再查一次的成本很低）。但从整体来看，Impala是能很好的容错，所有的Impalad是对等的结构，用户可以向任何一个Impalad提交查询，如果一个Impalad失效，其上正在运行的所有Query都将失败，但用户可以重新提交查询由其它Impalad代替执行，不会影响服务。对于State Store目前只有一个，但当State Store失效，也不会影响服务，每个Impalad都缓存了State Store的信息，只是不能再更新集群状态，有可能会把执行任务分配给已经失效的Impalad执行，导致本次Query失败。
（6）适用面
      ① Hive: 复杂的批处理查询任务，数据转换任务。
      ② Impala：实时数据分析，因为不支持UDF，能处理的问题域有一定的限制，与Hive配合使用,对Hive的结果数据集进行实时分析。

3.3 在Cloudera的测试中，Impala的查询效率比Hive有数量级的提升。从技术角度上来看，Impala之所以能有好的性能，主要有以下几方面的原因。

（1）Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。
（2）省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。
（3）Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的shuffle、sort等开销。
（4）通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销。
（5）用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令。
（6）使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。

参考文章：
[1] https://www.biaodianfu.com/Impala.html
[2] https://www.cnblogs.com/Rainbow-G/articles/4282444.html
[3] https://blog.csdn.net/qq_31246691/article/details/79670789