Impala和Hive之间有什么关系

 

hive是Java写的，由Facebook开源，目的是将特定的SQL语句编译为MapReduce jar包扔给hadoop去执行，本质上是一个代码转换编译的工具，简化mr的开发，因为pig hive出现以前，mr都需要由熟悉Java或Python和hadoop架构熟悉的比较高级的程序员来写，这就限制了hadoop的使用广度。所以擅长语言翻译的facebook搞了一个hive，来把sql语言翻译成java再跑mr。

impala是spark萌芽时期cdh开源的c++编写的sql执行引擎，也用到了有向无环图和RDD的思路，我想当初可能是CDH想跟spark竞争一下内存计算这块的市场，后来发现争不过spark，现在也就处于半开发半维护的状态了，从核心上来说，执行原理跟hive完全不一样，hive是把sql转译成java，编译了jar包提交给hadoop，剩下的事情就是hadoop的mr的事了，hive只需要等着获取结果就好了。而impala则调用C语言层的libhdfs来直接访问HDFS，从NN获取到数据块信息后，直接将数据块读入内存，会使用hadoop的一个配置项叫dfs.client.short.read.circuit。看得出来，这是一个client端配置，作用是直接读取本地的数据块而不是通过HDFS读取整合后的文件。所以impala需要在每个dn节点都安装impalad去完成本地读取的工作。数据块读进内存之后就开始做有向无环图，完成计算之后会将热数据保存在内存里供下次读取。

CDH不开发单独的metastore是因为没有必要，当时hive已经是主流分析工具了，hadoop的使用者经过几年的积累，已经在hive上建立了成千上万个表。你再单独开发一个metastore纯属浪费，难道客户还要再给impala建一个单独的schema吗？再把那成千上万的分析表重建一遍？为什么不直接用以前hive建好的？

在我的认知范围内，impala不能脱离hive的metastore独立存在，而且catalogd有时还需要手工刷新hive的metastore缓存。

 

Hive 体系结构

 

 

Hive

    hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。Hive支持HSQL，是一种类SQL。

也由于这种机制导致Hive最大的缺点是慢。Map/reduce调度本身只适合批量，长周期任务，类似查询这种要求短平快的业务，代价太高。

 

Impala 架构

 

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

 

Impalad: 与DataNode运行在同一节点上，由Impalad进程表示，它接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator通过JNI调用java前端解释SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行），读写数据，并行执行查询，并把结果通过网络流式的传送回给Coordinator，由Coordinator返回给客户端。同时Impalad也与State Store保持连接，用于确定哪个Impalad是健康和可以接受新的工作。在Impalad中启动三个ThriftServer: beeswax_server（连接客户端），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使用接口。

Impala架构类似分布式数据库Greenplum数据库，一个大的查询通过分析为一一个子查询，分布到底层的执行，最后再合并结果，说白了就是通过多线程并发来暴力SCAN来实现高速。

架构是完美的，现实是骨感的，实际使用过程中，Impala性能和稳定性还差得远。尤其是Impala虽然号称支持HDFS和HBASE，但实际使用中发现，运行在HDFS上，性能还差强人意，运行在HBASE上性能很差，另外还经常有内存溢出之类的问题尚待解决。

Impala的查询处理流程

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

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

· 使用LLVM产生运行代码，针对特定查询生成特定代码，同时使用Inline的方式减少函数调用的开销，加快执行效率。

· 充分利用可用的硬件指令（2）。

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

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

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

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主动向前面节点要数据，以此方式数据可以流式的返回给客户端，且只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用。

内存使用

Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。

Impala: 在遇到内存放不下数据时，当前版本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的结果数据集进行实时分析。

Impala的优缺点

优点

· 支持SQL查询，快速查询大数据。

· 可以对已有数据进行查询，减少数据的加载，转换。

· 多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）。

· 可以与Hive配合使用。

缺点

· 不支持用户定义函数UDF。

· 不支持text域的全文搜索。

· 不支持Transforms。

· 不支持查询期的容错。

· 对内存要求高。

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

· Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。

· 省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。

· Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的shuffle、sort等开销。

· 通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销。

· 用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令。

· 使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。

· 虽然Impala是参照Dremel来实现的，但它也有一些自己的特色，例如Impala不仅支持Parquet格式，同时也可以直接处理文本、SequenceFile等Hadoop中常用的文件格式。另外一个更关键的地方在于，Impala是开源的，再加上Cloudera在Hadoop领域的领导地位，其生态圈有很大可能会在将来快速成长。