共计 4074 个字符，预计需要花费 11 分钟才能阅读完成。
这篇文章给大家介绍如何分析 Impala，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
Impala 介绍
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 查询选项定义)，它将释放当前查询不需要的所有内存。
关于如何分析 Impala 就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
