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中常用的文件格式

Impala官网：https://impala.apache.org/index.html

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都将失败

1.4、Impala与关系型数据库

比较项	Impala	关系型数据库
SQL语言	使用类似于HiveSQL的查询语言	使用标准SQL语言
数据更新	Impala不支持更新或删除单个记录	可以更新或删除单个记录
事务	不支持事务	支持事务
索引	不支持索引	支持索引
处理数据量	存储和管理大量数据（PB）	存储和管理数据量较少（TB）

2、Impala架构

2.1、Impala架构与组成

Impala的架构如下：

Impala主要由5部分组成：

1）Client

Impala客户端包括Hue、ODBC客户端、JDBC客户端和Impala Shell（使用Python实现）在内的实体都可以与Impala交互。这些接口通常用于发出查询或完成管理任务，例如连接到Impala

2）Impalad

Impala的核心组件是Impala守护进程impalad，impalad与HDFS的DataNode运行在同一个节点上，impalad的核心功能是：处理Client请求；读写数据文件；并行查询并在集群中分配工作；将中间查询结果传回中央协调器；与Statestore保持通信，汇报工作

值得注意的是，Impala与HDFS是共存的，每个Impala守护进程和DataNode运行在同一个主机上。Impala单独部署在计算集群中，可以远程从HDFS、S3等读取数据

Impalad服务有三种角色。Impala的核心进程Impalad部署在所有的数据节点上，接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator通过JNI调用Java前端解释SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行），读写数据，并行执行来自集群中其他节点的查询请求，将中间结果以网络流式的方式返回给调度节点Coordinator，由调度节点Coordinator将结果返回给客户端。Impalad进程通过持续与StateStore通信来确认其它Impalad节点是否健康以及是否可以接受新的任务请求

• Query Planner：使用Java编写，解析SQL生成执行计划树（QueryPlanTree）
• Query Coordinator：用户在Impala集群上的某个节点提交数据处理请求（例如Impala-Shell提交SQL），则该Impalad节点称为Coordinator（协调节点），负责定位数据，拆分请求（Fragment），将任务分解为多个可并行执行的小请求，发送这些请求到多个Query Executor，接收Query Executor处理后返回的数据并构建最终结果返回给用户
• Query Executor：执行数据计算，例如Scan，Aggregation，Merge等，返回数据

3）StateStore

StateStore服务（名为stateststored的守护进程）主要负责MetaData的广播，检查集群中所有Impala守护进程的健康状况，同步节点信息，以及Query的协调调度。StateStore通过创建多个线程来处理Impalad的注册订阅和与各Impalad保持心跳连接，各Impalad都会缓存一份StateStore中的MetaData信息。如果一个Impala守护进程由于硬件故障、网络错误、软件问题或其他原因而离线，StateStore会通知所有其他的Impala守护进程，这样以后的查询就可以避免向这个不可达的Impala守护进程发出请求

4）Catalog

Catalog将Hive元数据信息的变更通过StateStore广播给Impalad。Catalog服务（名为catalogd的守护进程）主要负责MetaData的获取、DDL的执行和接收来自StateStore的所有请求。由于请求是通过StateStore守护进程传递的，所以在同一主机上运行StateStore和Catalog服务是更好的

由于Impala没有直接存储元数据信息，而是靠从Hive Metastore定期同步，因为Impalad任何一个节点都有可能充当协调者和执行者的角色，所以元数据信息需要所有节点存储最新的数据，这是为了兼容Hive而导致的一些遗留问题。StateStore组件的作用是实现一个业务无关的订阅发布系统，元数据的更改需要它去通知各个节点，这解决了一个MPP无法大规模扩展的问题，大大增加了系统的可扩展性，降低了Catalog的实现和运维复杂度

当通过Impala发出的语句执行元数据更改时，Catalog服务避免发出REFRESH和INVALIDATE METADATA语句。当你通过Hive创建表、加载数据时，在执行查询之前，你需要在Impala守护进程上发出REFRESH或INVALIDATE元数据

由于Impalad可以直接提供JDBC服务，如果连接的任意Impalad创建表，那么其他节点短期内是不知道这个表已经存在并且提供服务的，这个时候，我们需要在每次执行SQL时都先去执行INVALIDATE METADATA，否则无法及时查询到最新的数据

如果出现底层HDFS抽取大量分区数据入库，不执行INVALIDATE METADATA则无法查询到最新的数据，这个时候，我们可能通过ETL Server每隔30秒就执行全局的MetaData更新，导致Impalad底层疯狂的去Scan HDFS上的数据，日志在后台一直疯狂刷新Block信息，导致Impala性能急剧下降，甚至一个SQL很久都无法返回结果，只有简单查询才能有结果。所以一定要慎用、合理的使用INVALIDATE METADATA

5）数据存储服务

数据存储服务使用HBase或HDFS，用于存储元数据与具体数据

2.2、Impala运行原理

Impala的运行执行流程如下图所示：

其中，启动Impala服务时执行的操作包括：Catalog向Hive MetaData和HDFS NameNode获取元数据信息并返回给Statestore；Statestore监测所有Impalad的健康状态并将元数据信息广播到Impalad；Impalad与Statestore保持通信，并向Statestore汇报自己的健康状态，同时接收Hive元数据变更

查询SQL的运行流程及数据计算流程如下：

3、Impala安装部署

Impala有两种安装部署方式：手动安装和CDH安装

由于Cloudera公司对于Impala的安装只提供了rpm包而没有提供tar包，所以如果我们选择手动安装Impala的rpm包时，由于Impala的rpm包依赖于众多的其他rpm包，因此我们需要将这些依赖寻找出来一个个安装，这会比较浪费时间，且如果缺少任意一个依赖都有可能导致环境问题

Linux系统对于rpm包的依赖管理提供了⼀个很好的管理⼯具Yum，类似于Java⼯程中的包管理⼯具Maven，Maven可以⾃动搜寻指定Jar所需的其它依赖并⾃动下载。Yum同理可以⽅便我们进⾏rpm包的安装而⽆需关心当前rpm所需的依赖。但是与Maven下载其它依赖（到中央仓库）⼀样，Yum下载依赖所需的源也是在国外服务器且其中没有安装Impala所需要的rpm包。所以Yum这种方式会下载依赖失败

综上所述，Impala的安装部署一般与CDH集成，这种方式比较便捷，方便管理

详细安装过程参考：https://www.w3cschool.cn/impala/impala_environment.html

参考文章：
https://blog.csdn.net/qq_20042935/article/details/125079575
https://blog.csdn.net/chengh1993/article/details/112062379
https://liugp.blog.csdn.net/article/details/123934438
https://blog.csdn.net/qq_22473611/article/details/113757085