Impala介绍文档

Impala介绍文档

Impala介绍文档

目录 [隐藏] 

1 1、Impal架构（v1.2+）

2 2、Impala适用场景

3 3、Impala与Hive关系

4 4、Impala 为什么会比MapReduce更高效

5 5、内存依赖

6 6、Impala、Hive性能对比

[编辑] 1、Impal架构（v1.2+）

   Impala 是分布式、大规模并行处理（MPP）的数据库引擎，主要有CLI、Statestore、Catalog、Impala组件构成如下图。

Impala架构图.jpg

各组件功能介绍：

Impala：运行在DataNode节点上，由Impalad进程表示，它接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator解析SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行），读写数据，并行执行查询，并把结果通过网络流式的传送回给Coordinator，由Coordinator返回给客户端。同时Impalad也与State Store保持连接，用于确定哪个Impalad是健康和可以接受新的工作，并从catalogd服务接收广播消息

Statestore：跟踪集群中impalaed健康状态及位置。impalaed启动时进行订阅注册并保持心跳连接。并且每个impalaed都缓存一份state store信息。所以即便是state store挂掉，impala还是能够提供服务，只是无法更新每个impalaed的状态。

Catalog：用于同步impala语句产生的metadata的变化到集群里所有结点。解决1.2版本之前的问题：1）在使用CREATE DATABASE, DROP DATABASE, CREATE TABLE, ALTER TABLE, or DROP TABLE语句后，在其它结点执行查询前需要先执行INVALIDATE METADATA来更新结构对象；

2）在一个节点上执行INSERT 语句后要在其它节点执行REFRESH，以便识别出新增的数据。 但是当通过hive操作后，在impala节点执行查询时仍然需要执行 REFRESH 或INVALIDATE METADATA。

CLI：提供给用户查询的命令行工具，shell（Impala使用python实现）、JDBC、ODBC接口

[编辑] 2、Impala适用场景

     1）Impala 非常适合在大的数据集上，为交互式探索分析执行 SQL。

     2）业务逻辑相对简单，类似于关系型数据库。

     3）即席查询(Ad-hoc)是 Impala 的主要应用场景，比hive更高效。

     4）查询结果集不大，必须小于内存，否则不会执行成功。

[编辑] 3、Impala与Hive关系

    Impala与Hive都是构建在Hadoop之上的数据查询工具各有不同的侧重适应面，但从客户端使用来看Impala与Hive有很多的共同之处，如数据表元数据、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。Impala与Hive在Hadoop中的关系如下图所示。

    Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询，Impala给数据分析人员提供了快速实验、验证想法的大数据分析工具。可以先使用hive进行数据转换处理，之后使用Impala在Hive处理后的结果数据集上进行快速的数据分析。

   

多数HiveQL 语句都可以直接在Impala下运行，不支持HiveQL中可用的SQL特性如下：

Impala只支持简单数据类型不支持maps, arrays, structs。

可扩展机制(Extensibility mechanisms)例如 TRANSFORM, 自定义文件格式, 或自定义 SerDes; zImpala 1.2

Impala 在 string 和 numeric 或 Boolean 之间不进行隐式转换，Impala 在 numeric 或 string 到 timestamp 之间不进行隐式转换

XML和JSON函数

HiveQL 中的某些聚合函数: variance, var_pop, var_samp, stddev_pop, stddev_samp, covar_pop, covar_samp, corr, percentile, percentile_approx, histogram_numeric,collect_set; Impala 支持这些聚合函数: MAX(), MIN(), SUM(), AVG(), COUNT()

等等

Impala&hive.jpg

[编辑] 4、Impala 为什么会比MapReduce更高效

Impala 与 Hive 和 Pig 不同，因为它使用自己的守护进程，跨集群分布式进行查询。因为 Impala 不依赖于 MapReduce，它避免了 MapReduce 作业的启动开销，让 Impala 能实时返回结果。

Impala 不会把中间结果存放到硬盘上，最大限度的使用内存及时通过网络以strem的方式传递。

Impala 避免了 MapReduce 启动时间的耗费。对于交互式查询，MapReduce 启动时间变得非常醒目。Impala 以服务方式运行，实际上没有启动时间

Impala 可以更自然的分散查询计划，而不是不得不纳入 map 和 reduce 作业管道中。这使得 Impala 可以并行处理查询的多个步骤，并避免不必要的负载如排序和混洗(This enables Impala to parallelize multiple stages of a query and avoid overheads such as sort and shuffle when unnecessary)

Impala 生成运行时代码。Impala 使用 LLVM 为要执行的查询生成汇编码(assembly code)。个别查询不需要为运行在可以支持各种查询的系统而支付代价(Individual queries do not have to pay the overhead of running on a system that needs to be able to execute arbitrary queries)

Impala 尽可能采用最新的硬件指令。Impala 使用最新的 SSE (SSE4.2) 指令集，某些情况下可以提供巨大的加速效果

Impala 采用更好的 I/O 调度。Impala 了解块在硬盘上的位置，并可以调度块处理的顺序，以便保证所有硬盘都繁忙，Impala支持直接数据块读取和本地代码计算checksum。

Impala 专为性能设计。Impala 采取以性能为导向的设计原则，为此花费了大量的时间，例如紧密内部循环、内联函数调用、最小分支、更好的缓存使用、以及最小内存使用等(A lot of time has been spent in designing Impala with sound performance-oriented fundamentals, such as tight inner loops, inlined function calls, minimal branching, better use of cache, and minimal memory usage)

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

[编辑] 5、内存依赖

   尽管 Impala 不是内存数据库，当处理大的表和大的结果集时， impalad 守护进程会分配大量的物理内存，假如在某一节点上处理中间结果集所需的内存超出了这一节点上 Impala 可用的内存，查询会被取消。

Impala 操作所需的内存依赖于几个因素：

表的文件格式。相同的数据，采用不同的文件格式，数据文件个数也不同。为了分析数据，根据每个文件所采用的压缩和编码格式的不同，可能需要不同数据量的临时内存来进行解压

是否为 SELECT 或 INSERT 操作。例如，查询 Parquet 表时需要相对较少的内存，因为 Impala 以 8MB /块来进行读取和解压缩数据。而向 Parquet 表插入数据则是内存密集型操作，因为每一个数据文件(最大大小为 1GB)的数据被放在内存中，直到编码、压缩并写入硬盘

表是否为分区表，并且针对分区表的查询是否可以从分区修剪(partition pruning)中受益

Impala 要求所有包含的 ORDER BY 子句的查询同时包含 LIMIT 子句，协调节点需要足够的内存进行排序，实际需要内存为LIMIT数量 *集群节点数所站的空间。

结果集的大小。当中间结果集在节点之间传输时，传输数据的数量依赖于查询返回列的数量。select 查询时避免用*，只查询所需要的字段。

使用内存的大小并不是跟输入数据集的大小直接相关。对于聚合来说，使用的内存跟分组后的行数有关。对于表连接来说，使用的内存与除了最大的表之外其他所有表的大小相关，并且 Impala 可以采用在每个节点之间拆分大的连接表而不是把整个表都传输到每个节点的连接策略

使用内存的大小并不是跟输入数据集的大小直接相关。对于聚合来说，使用的内存跟分组后的行数有关。对于连接来说，使用的内存与除了最大的表之外其他所有表的大小相关，并且 Impala 可以采用在每个节点之间拆分大的连接表而不是把整个表都传输到每个节点的连接策略

在唯一或高基数(high-cardinality)列上的 GROUP BY 操作。Impala 为 GROUP BY 查询中每一个不同的值分配一些处理结构(handler structures)。成千上万不同的 GROUP BY 值可能超出内存限制

查询涉及到非常宽、包含上千个列的表，特别是包含许多 STRING 列的表。因为 Impala 允许 STRING 值最大不超过 32 KB，这些查询的中间结果集可能需要大量的内存分配

Impala 使用 tcmalloc 分配内存，一款专为高并发优化的内存分频器。一当 Impala 分配了内存，它保留这些内存用于将来的查询。因此，空闲时显示 Impala 有很高的内存使用是很正常的。假如 Impala 检测到它将超过内存限制(通过 -mem_limit 启动选项或 MEM_LIMIT 查询选项定义)，它将释放当前查询不需要的所有内存。

</br>

[编辑] 6、Impala、Hive性能对比

Impala versus Hive 0.12/Stinger

(Lower bars are better)

Impalavshive1.png

In summary, Impala outperformed Hive by 6x to 69x (and by an average of 24x) depending on the category involved:

Impalavshive2.png

参考：

http://www.cloudera.com/content/cloudera-content/cloudera-docs/Impala/latest/Cloudera-Impala-Release-Notes/Cloudera-Impala-Release-Notes.html

http://blog.cloudera.com/blog/2014/01/impala-performance-dbms-class-speed/

http://blog.cloudera.com/blog/2014/05/new-sql-choices-in-the-apache-hadoop-ecosystem-why-impala-continues-to-lead/