Impala架构及其原理

一、Impala概述

Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但由于Hive底层执行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性。相比之下，Impala的最大特点也是最大卖点就是它的快速。

1.Impala特性

a.没有使用MapReduce作为底层执行计算框架，虽然MapReduce是非常好的并行计算框架，但它更多地是面向批处理模式，而不是面向交互式的SQL执行模式。
b.与MapReduce相比Impala将整个查询分成一批查询计划树，而不是一连串的MapReduce执行任务，在将查询计划分发之后，Impala采用拉链式的方式拉取计算结果，把结果数据组成执行树并进行流式传递汇集。减少了把中间结果写入磁盘的步骤，最后有从磁盘读取数据的开销。即相比没有了hive中mapreduce的启动时间。Impala的数据执行模式没有像Hive那样map->shuffle->reduce模式来处理数据保证了Impala的并发性和避免了中间过程中不必要的sort和shuffle。

Impala与hive相同点

hive架构原理精讲
MapReudce底层原理精讲

数据储存：使用相同的数据存储池，都可以将数据的储存在HDFS或HBase中。
元数据：两者使用相同的元数据
SQL解释处理：比较相似的就是都是通过词法分析生成执行计划。
查询计划树

不同点

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

二、Impala的作业流程

服务器启动时，Impalad与StateStore保持心跳。首先Impala节点会将自己节点的状态信息汇报给Statestore，Statestore实时监控impalad是否发生故障。然后Catalog与Hive进行通信，将Hive中Metastore中的元数据信息拉取到自己的字节上，然后以广播的形式发送给每个状态良好的Impalad节点上，使各个节点上的元数据保持一致。然后当客户端进行提交sql请求的时候，不会再向那个hive中进行MRjob了，而是直接作用在Impalad上，直接在impalad上生成执行计划数，进行快速查询。Impalad由于作用在HDFS上或者HBase上的，所以不许转换成MR job的sql请求时非常快的了。Query任务的执行直接是作用在HDFS上的。
当clinet执行数据的更新操作，即数据的append追加错误时，将数据当Impalad数据执行完毕后，Impalad会向StateStore进行发送元数据,Satestore将接收到的元数据推给Catelog，Catelog将所有接收到的元数据进行汇总，然后将汇总后的总元数据以广播的形式发送给每个Impala节点然后将数据，使得每台Impalad节点上的元数据都同步了，之后Catalog又将汇总后的元数据发送给MetaStore一份，使得hive中的元数据和Impala中的元数据是一样的。当Impala集群出现故障时，由于hive中还有完整的原数据这样保障了元数据的丢失，当Impala集群开启时，又通过Catalog将元数据同步到Impalad上，这样有可以进行工作了。
Impalad拥有所有元数据的信息时，当客户端提交查询的时候，会在离最近的一台节点上进行查询，由于每台节点都同步了所有节点的元数据，当从原数据进行查询的时候，就可以知道需要的数据位置在哪台Impalad节点上，这样就可以直接作用到指定的数据节点上进行查询。

三、Impala面试

Impala的优缺点

#优点

• 支持JDBC/ODBC远程访问，支持SQL查询，快速查询大数据。
• 无需转换为MR，直接读取HDFS数据
• 支持Data Local，可以对已有数据进行查询，减少数据的加载，转换。
• 支持列式存储，多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）。
• 可以与Hive配合使用,兼容HiveSQL， 可对hive数据直接做数据分析
• 基于内存进行计算，能够对PB级数据进行交互式实时查询、分析

缺点

• 不支持用户定义函数UDF。
• 不支持text域的全文搜索。
• 不支持Transforms。
• 不支持查询期的容错。
• 对内存要求高。
• 完全依赖于hive
• 实践过程中 分区超过1w 性能严重下降

高性能

在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将可能作为一个兼容并包的大平台存在，在其上提供各种各样的数据处理技术，有应对秒量级查询的，有应对大数据批处理的，各种功能应有尽有，满足用户各方面的需求。

MapReduce架构原理详解：https://blog.csdn.net/Mirror_w/article/details/89421705
小二讲堂：https://blog.csdn.net/Mirror_w