Impala：基于内存的MPP查询引擎

1、Impala概述

1.1、Impala简介

Impala是Cloudera公司主导研发的高性能、低延迟的交互式SQL查询引擎，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。Impala主要用于解决Hadoop生态圈无法支持交互式查询数据的痛点，Impala是CDH平台首选的PB级大数据实时交互式查询分析引擎

2015年11月，Cloudera将Impala捐赠给了Apache基金会，2017年11月，Impala从Apache孵化器毕业。以前在文档中称为Cloudera Impala的地方，现在已经正式更名为Apache Impala

Impala是一个基于Hive、分布式、大规模并行处理（Massively Parallel Processing，MPP）的数据库引擎。除了使用相同的统一存储平台外，Impala还使用与Apache Hive相同的元数据、SQL语法（Hive SQL）、ODBC驱动程序和用户界面（Hue）

Impala开源，使用C++和Java编写，号称是性能最高的SQL引擎（提供类似RDBMS的体验），提供了访问存储在Hadoop分布式文件系统中的数据的最快方法。Impala直接针对存储在HDFS、HBase或S3中的Apache Hadoop数据提供快速的交互式SQL查询

MPP是一种基于PostgreSQL的分布式数据库，采用Shared-Nothing架构，主机、操作系统、内存、存储都是自我控制的，不存在共享。在MPP集群中，每个节点都有独⽴的内存和磁盘，每个节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务

简单来说，MPP是将任务并⾏的分散到多个服务器节点上，在每个节点上计算完成后，将各⾃部分的结果汇总在⼀起得到最终的结果

MPP虽然是关系型数据库产品，但它与Hadoop的理论基础是很相似的：都是将任务分布到节点中独立运算后进行结果合并。只不过MPP底层跑的是SQL，而Hadoop底层执行的是MapReduce

Impala是对现有大数据查询工具的补充。Impala不会替代基于MapReduce构建的批处理框架Hive，Hive和基于Spark框架查询的Hive最适合长时间运行的批处理作业。例如，涉及提取、转换和加载（ETL）类型作业的批处理

Impala是参照Google的Dremel系统进行设计的。Dremel是Google的交互式数据分析系统，它构建于Google的GFS（Google File System）等系统之上，支撑了Google的数据分析服务BigQuery等诸多服务

Dremel的技术亮点主要有两个：一是实现了嵌套型数据的列存储；二是使用了多层查询树，使得任务可以在数千个节点上并行执行和聚合结果

列存储可以减少查询时处理的数据量，有效提升查询效率。Dremel的列存储针对的并不是传统的关系数据，而是嵌套结构的数据。Dremel可以将一条条的嵌套结构的记录转换成列存储形式，查询时根据查询条件读取需要的列，然后进行条件过滤，输出时再将列组装成嵌套结构的记录输出，记录的正向和反向转换都通过高效的状态机实现

另外，Dremel的多层查询树则借鉴了分布式搜索引擎的设计。查询树的根节点负责接收查询，并将查询分发到下一层节点，底层节点负责具体的数据读取和查询执行，然后将结果返回上层节点

Impala其实就是Hadoop的Dremel，Impala使用的列存储格式是Parquet，但不仅仅支持Parquet格式，同时也可以直接处理文本、SequenceFile等Hadoop中常用的文件格式

1.2、Impala的特点

使用Impala，用户可以使用传统的SQL知识以极快的速度处理存储在HDFS、HBase和Amazon S3中的数据，而无需了解Java（MapReduce作业）

另外，由于是在数据驻留（在Hadoop集群上）时执行数据处理，因此在使用Impala时，不需要对存储在Hadoop上的数据进行数据转换和数据迁移

Impala优点：

• 基于内存运算，无需把中间结果写入磁盘，节省了大量的I/O开销
• 无需转换为MapReduce，直接访问存储在HDFS、HBase中的数据进行作业调度，速度快
• 使用了支持Data Locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销
• 支持各种文件格式，如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet
• 可以访问Hive的Metastore，对Hive数据直接做数据分析
• 使用LLVM产生运行代码，针对特定查询生成特定代码，同时使用Inline的方式减少函数调用的开销，加快执行效率

Impala缺点：

• 对内存的依赖大，且完全依赖于Hive
• 当分区超过1万时，性能严重下降
• 不提供任何对序列化和反序列化的支持
• 只能读取文本文件，而不能读取自定义二进制文件
• 每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新

1.3、Impala与Hive

MapReduce是非常好的并行计算框架，但它更多的面向批处理模式，而不是面向交互式的SQL执行

与MapReduce相比，Impala把整个查询任务转为⼀棵执⾏计划树，而不是一连串的MapReduce任务。在分发执行计划后，Impala使用拉式（拉取）获取数据的方式获取上个阶段的执⾏结果，把结果数据按执行树流式传递汇集，减少了把中间结果写磁盘、再读磁盘的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce的启动时间

一个关键原因是，Impala为每个查询产生汇编级的代码，当Impala在本地内存中运行的时候，这些汇编代码执行效率比其它任何代码框架都更快，因为代码框架会增加额外的延迟

Impala VS Hive如下：

相同点：

• 数据存储：使用相同的存储数据池，都支持把数据存储于HDFS、HBase
• 元数据：两者使用相同的元数据Hive Metastore
• SQL解释处理：比较相似的都是通过词法分析生成执行计划

不同点：

• 执行原理：Hive依赖于MapReduce，Shuffle阶段默认对Key排序，执行计划分为Map->Shuffle->Reduce...，一个Query会被编译为多轮MapReduce，每个中间结果都存在I/O开销，效率较低；Impala将执行计划转化为一棵完整的执行计划树，在执⾏程序之间使⽤流的⽅式传输中间结果，避免数据落盘，尽可能使⽤内存避免磁盘开销，效率高
• 查询过程：Hive中每个查询都有⼀个“冷启动”（MR每次都要启动关闭，申请资源，释放资源）；Impala避免了任何可能的启动开销，这是⼀种本地查询方式，Impala守护进程总是在集群启动之后就准备就绪。使用Impala的时候，查询任务会马上执行而不是生产MapReduce任务，这会节约大量的初始化时间
• 数据传输：Hive采用推的方式，每一个计算节点计算完成后将数据主动推给后续节点；Impala采用拉的方式，后续节点通过主动向前面节点要数据，以此方式数据可以流式的返回给客户端，只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用
• 内存使用：Hive在执行过程中如果内存放不下所有数据（内存不够时），则会使用磁盘，以保证Query能顺序执行完成。每一轮MapReduce结束，中间结果都会写入HDFS，Shuffle过程也会有写本地磁盘的操作；Impala则最大使用内存，中间结果不写磁盘，及时通过网络以Stream的方式传递数据，当内存放不下数据时，直接返回错误
• 调度过程：Hive任务的调度依赖于Hadoop的调度策略；Impala的调度由自己完成，目前的调度算法会尽量满足数据的局部性，即扫描数据的进程应尽量靠近数据本身所在的物理机器。但目前调度暂时还没有考虑负载均衡的问题。从Cloudera的资料看，Impala程序的瓶颈是网络IO
• 容错能力：Hive任务依赖于Hadoop框架的容错能力；Impala中不存在任何容错逻辑，如果执行过程中发生故障，则直接返回错误。当一个Impalad失败时，在这个Impalad上正在运行的所有Query都将失败