impala与hive的比较以及impala的有缺点

     最近读的几篇关于impala的文章，这篇良心不错：https://www.biaodianfu.com/impala.html（本文截取部分内容）

        Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但由于Hive底层执行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性。相比之下，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领域的领导地位，其生态圈有很大可能会在将来快速成长。

Impala与Shark，Drill等的比较

开源组织Apache也发起了名为Drill的项目来实现Hadoop上的Dremel，目前该项目正在开发当中，相关的文档和代码还不多，可以说暂时还未对Impala构成足够的威胁。从Quora上的问答来看，Cloudera有7-8名工程师全职在Impala项目上，而相比之下Drill目前的动作稍显迟钝。具体来说，截止到2012年10月底，Drill的代码库里实现了query parser, plan parser，及能对JSON格式的数据进行扫描的plan evaluator；而Impala同期已经有了一个比较完毕的分布式query execution引擎，并对HDFS和HBase上的数据读入，错误检测，INSERT的数据修改，LLVM动态翻译等都提供了支持。当然，Drill作为Apache的项目，从一开始就避免了某个vendor的一家独大，而且对所有Hadoop流行的发行版都会做相应的支持，不像Impala只支持Cloudera自己的发行版CDH。从长远来看，谁会占据上风还真不一定。

除此之外，加州伯克利大学AMPLab也开发了名为Shark的大数据分析系统。从长远目标来看，Shark想成为一个既支持大数据SQL查询，又能支持高级数据分析任务的一体化数据处理系统。从技术实现的角度上来看，Shark基于Scala语言的算子推导实现了良好的容错机制，因此对失败了的长任务和短任务都能从上一个“快照点”进行快速恢复。相比之下，Impala由于缺失足够强大的容错机制，其上运行的任务一旦失败就必须“从头来过”，这样的设计必然会在性能上有所缺失。而且Shark是把内存当作第一类的存储介质来做的系统设计，所以在处理速度上也会有一些优势。实际上，AMPLab最近对Hive，Impala，Shark及Amazon采用的商业MPP数据库Redshift进行了一次对比试验，在Scan Query，Aggregation Query和Join Query三种类型的任务中对它们进行了比较。图2就是AMPLab报告中Aggregation Query的性能对比。在图中我们可以看到，商业版本的Redshift的性能是最好的， Impala和Shark则各有胜负，且两者都比Hive的性能高出了一大截。

其实对大数据分析的项目来说，技术往往不是最关键的。例如Hadoop中的MapReduce和HDFS都是源于Google，原创性较少。事实上，开源项目的生态圈，社区，发展速度等，往往在很大程度上会影响Impala和Shark等开源大数据分析系统的发展。就像Cloudera一开始就决定会把Impala开源，以期望利用开源社区的力量来推广这个产品；Shark也是一开始就开源了出来，更不用说Apache的Drill更是如此。说到底还是谁的生态系统更强的问题。技术上一时的领先并不足以保证项目的最终成功。虽然最后那一款产品会成为事实上的标准还很难说，但是，我们唯一可以确定并坚信的一点是，大数据分析将随着新技术的不断推陈出新而不断普及开来，这对用户永远都是一件幸事。举个例子，如果读者注意过下一代Hadoop（YARN）的发展的话就会发现，其实YARN已经支持MapReduce之外的计算范式（例如Shark，Impala等），因此将来Hadoop将可能作为一个兼容并包的大平台存在，在其上提供各种各样的数据处理技术，有应对秒量级查询的，有应对大数据批处理的，各种功能应有尽有，满足用户各方面的需求。