Impala与Hive的比較

大家好，又见面了，我是全栈君，祝每个程序员都可以多学几门语言。

1. Impala架构

Impala是Cloudera在受到Google的Dremel启示下开发的实时交互SQL大数据查询工具，Impala没有再使用缓慢的Hive+MapReduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），能够直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大减少了延迟。其架构如图 1所看到的，Impala主要由Impalad， State Store和CLI组成。

图 1

Impalad: 与DataNode运行在同一节点上，由Impalad进程表示，它接收client的查询请求（接收查询请求的Impalad为Coordinator，Coordinator通过JNI调用java前端解释SQL查询语句，生成查询计划树，再通过调度器把运行计划分发给具有对应数据的其他Impalad进行运行），读写数据，并行运行查询，并把结果通过网络流式的传送回给Coordinator，由Coordinator返回给client。同一时候Impalad也与State Store保持连接，用于确定哪个Impalad是健康和能够接受新的工作。在Impalad中启动三个ThriftServer: beeswax_server（连接client），hs2_server（借用Hive元数据）， be_server（Impalad内部使用）和一个ImpalaServer服务。

Impala State Store: 跟踪集群中的Impalad的健康状态及位置信息，由statestored进程表示，它通过创建多个线程来处理Impalad的注冊订阅和与各Impalad保持心跳连接，各Impalad都会缓存一份State Store中的信息，当State Store离线后（Impalad发现State Store处于离线时，会进入recovery模式，重复注冊，当State Store又一次添�集群后，自己主动恢复正常，更新缓存数据）由于Impalad有State Store的缓存仍然能够工作，但会由于有些Impalad失效了，而已缓存数据无法更新，导致把运行计划分配给了失效的Impalad，导致查询失败。

CLI: 提供给用户查询使用的命令行工具（Impala Shell使用python实现），同一时候Impala还提供了Hue，JDBC， ODBC使用接口。

2. 与Hive的关系

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

图 2

3. Impala的查询处理过程

Impalad分为Java前端与C++处理后端，接受client连接的Impalad即作为这次查询的Coordinator，Coordinator通过JNI调用Java前端对用户的查询SQL进行分析生成运行计划树，不同的操作相应不用的PlanNode, 如：SelectNode， ScanNode， SortNode， AggregationNode， HashJoinNode等等。

运行计划树的每一个原子操作由一个PlanFragment表示，通常一条查询语句由多个Plan Fragment组成， Plan Fragment 0表示运行树的根，汇聚结果返回给用户，运行树的叶子结点通常是Scan操作，分布式并行运行。

Java前端产生的运行计划树以Thrift数据格式返回给Impala C++后端（Coordinator）（运行计划分为多个阶段，每个阶段叫做一个PlanFragment，每个PlanFragment在运行时能够由多个Impalad实例并行运行(有些PlanFragment仅仅能由一个Impalad实例运行,如聚合操作)，整个运行计划为一运行计划树），由Coordinator依据运行计划，数据存储信息（Impala通过libhdfs与HDFS进行交互。通过hdfsGetHosts方法获得文件数据块所在节点的位置信息），通过调度器（如今仅仅有simple-scheduler, 使用round-robin算法）Coordinator::Exec对生成的运行计划树分配给对应的后端运行器Impalad运行（查询会使用LLVM进行代码生成，编译，运行。对于使用LLVM怎样提高性能这里有说明），通过调用GetNext()方法获取计算结果，假设是insert语句，则将计算结果通过libhdfs写回HDFS当全部输入数据被消耗光，运行结束，之后注销此次查询服务。

Impala的查询处理流程大概如图3所看到的：

图 3

以下以一个SQL查询语句为例分析Impala的查询处理流程。如select sum(id), count(id), avg(id) from customer_small group by id；以此语句生成的计划为：

PLAN FRAGMENT 0
PARTITION: UNPARTITIONED

4:EXCHANGE
     tuple ids: 1

PLAN FRAGMENT 1
PARTITION: HASH_PARTITIONED: <slot 1>

STREAM DATA SINK
    EXCHANGE ID: 4
    UNPARTITIONED

3:AGGREGATE
| output: SUM(<slot 2>), SUM(<slot 3>)
| group by: <slot 1>
| tuple ids: 1
|
2:EXCHANGE
     tuple ids: 1

PLAN FRAGMENT 2
PARTITION: RANDOM

STREAM DATA SINK
    EXCHANGE ID: 2
    HASH_PARTITIONED: <slot 1>

1:AGGREGATE
| output: SUM(id), COUNT(id)
| group by: id
| tuple ids: 1
|
0:SCAN HDFS
     table=default.customer_small #partitions=1 size=193B
     tuple ids: 0

运行行计划树如图 4所看到的，绿色的部分为能够分布式并行运行：

图 4

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

1、没有使用MapReduce进行并行计算，尽管MapReduce是很好的并行计算框架，但它很多其它的面向批处理模式，而不是面向交互式的SQL运行。与MapReduce相比：Impala把整个查询分成一运行计划树，而不是一连串的MapReduce任务，在分发运行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按运行树流式传递汇集，降低的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次运行查询都须要启动的开销，即相比Hive没了MapReduce启动时间。

2、使用LLVM产生执行代码，针对特定查询生成特定代码，同一时候使用Inline的方式降低函数调用的开销，加快执行效率。

3、充分利用可用的硬件指令（SSE4.2）。

4、更好的IO调度，Impala知道数据块所在的磁盘位置可以更好的利用多磁盘的优势，同一时候Impala支持直接数据块读取和本地代码计算checksum。

5、通过选择合适的数据存储格式能够得到最好的性能（Impala支持多种存储格式）。

6、最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递。

5. Impala与Hive的异同

数据存储：使用同样的存储数据池都支持把数据存储于HDFS, HBase。

元数据：两者使用同样的元数据。

SQL解释处理：比較相似都是通过词法分析生成运行计划。

运行计划：
Hive: 依赖于MapReduce运行框架，运行计划分成map->shuffle->reduce->map->shuffle->reduce…的模型。假设一个Query会被编译成多轮MapReduce，则会有很多其它的写中间结果。因为MapReduce运行框架本身的特点，过多的中间过程会添加�整个Query的运行时间。
Impala: 把运行计划表现为一棵完整的运行计划树，能够更自然地分发运行计划到各个Impalad运行查询，而不用像Hive那样把它组合成管道型的map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。

数据流：
Hive: 採用推的方式，每个计算节点计算完毕后将数据主动推给兴许节点。
Impala: 採用拉的方式，兴许节点通过getNext主动向前面节点要数据，以此方式数据能够流式的返回给client，且仅仅要有1条数据被处理完，就能够马上展现出来，而不用等到所有处理完毕，更符合SQL交互式查询使用。

内存使用：
Hive: 在运行过程中假设内存放不下全部数据，则会使用外存，以保证Query能顺序运行完。每一轮MapReduce结束，中间结果也会写入HDFS中，相同因为MapReduce运行架构的特性，shuffle过程也会有写本地磁盘的操作。
Impala: 在遇到内存放不下数据时，当前版本号1.0.1是直接返回错误，而不会利用外存，以后版本号应该会进行改进。这使用得Impala眼下处理Query会受到一定的限制，不妨与Hive配合使用。Impala在多个阶段之间利用网络数据传输，在运行过程不会有写磁盘的操作（insert除外）。

调度：
Hive: 任务调度依赖于Hadoop的调度策略。
Impala: 调度由自己完毕，眼下仅仅有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器眼下还比較简单，在SimpleScheduler::GetBackend中能够看到，如今还没有考虑负载，网络IO状况等因素进行调度。但眼下Impala已经有对运行过程的性能统计分析，应该以后版本号会利用这些统计信息进行调度吧。

容错：
Hive: 依赖于Hadoop的容错能力。
Impala: 在查询过程中，没有容错逻辑，假设在运行过程中发生问题，则直接返回错误（这与Impala的设计有关，由于Impala定位于实时查询，一次查询失败，再查一次就好了，再查一次的成本非常低）。但从总体来看，Impala是能非常好的容错，全部的Impalad是对等的结构，用户能够向不论什么一个Impalad提交查询，假设一个Impalad失效，其上正在运行的全部Query都将失败，但用户能够又一次提交查询由其他Impalad取代运行，不会影响服务。对于State Store眼下仅仅有一个，但当State Store失效，也不会影响服务，每一个Impalad都缓存了State Store的信息，仅仅是不能再更新集群状态，有可能会把运行任务分配给已经失效的Impalad运行，导致本次Query失败。

适用面：
Hive: 复杂的批处理查询任务，数据转换任务。
Impala：实时数据分析，由于不支持UDF，能处理的问题域有一定的限制，与Hive配合使用,对Hive的结果数据集进行实时分析。