概述
-
Thanks to local processing on data nodes, network bottlenecks are avoided.由于对数据节点进行了本地处理，因此避免了网络瓶颈。
-
A single, open, and unified metadata store can be utilized. 可以利用单个，开放和统一的元数据存储。
-
Costly data format conversion is unnecessary and thus no overhead is incurred. 无需进行昂贵的数据格式转换，因此不会产生任何开销。
-
All data is immediately query-able, with no delays for ETL. 所有数据均可立即查询，而ETL没有延迟。
-
All hardware is utilized for Impala queries as well as for MapReduce. 所有硬件均用于Impala查询以及MapReduce。
-
Only a single machine pool is needed to scale. 仅需单个计算机池即可扩展。
组件
从上图可以看出，Impala 自身包含三个模块：Impalad、Statestore 和 Catalog，除此之外 它还依赖 Hive Metastore 和 HDFS/Hbase/。
Impalad
- 接收 client 的请求、Query 执行并返回给中心协调节点；
- 子节点上的守护进程，负责向 statestore 保持通信，汇报工作。
Catalog
-
分发表的元数据信息到各个 impalad 中；
-
接收来自 statestore 的所有请求。
Statestore
- 负责收集分布在集群中各个 impalad 进程的资源信息、各节点健康状况，同步节点 信息；
- 负责 query 的协调调度
实例
Front实现
Impala前端负责编译SQL文本添加到Impala后端可执行的查询计划中。
它是用Java编写的，由功能齐全的SQL组成解析器和基于成本的查询优化器，全部从scratch。 除了基本的SQL功能（select, project,join, group by, order by, limit），Impala支持内联视图，不相关和相关的子查询（被重写为joins），外部联接的所有变体以及显式的左/右半联接和反联接，以及分析窗口函数(analytic window functions)。
第一阶段，将分析树转换为不可执行的单节点计划树，该计划树由以下计划节点组成：HDFS/HBase scan, hash join, cross join, union, hash aggregation, sort, top-n, and analytic evaluation.
第二计划阶段将单节点计划作为输入，并生成分布式执行计划。 的总体目标是最大程度地减少数据移动并最大化扫描。局部性：在HDFS中，远程读取的速度比本地读取慢得多。
当前所有聚合都作为本地预聚合执行。然后进行合并聚合操作。
最后，分布式计划树在交换边界处拆分。 计划的每个此类部分都放在计划片段中，该片段是Impala的后端执行单位。
上述步骤演示：
The left side of the figure shows the single-node plan of a query joining two HDFS tables (t1, t2) and one HBase table (t3) followed by an aggregation and order by with limit (top-n). The right-hand side shows the distributed, fragmented plan.
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VR5UA64Y-1589099431577)(D:\08note\大数据\impala\03architecture.assets\image-20200510155622000.png)]
BackEnd 实现
Impala的后端从前端接收查询片段，并负责其快速执行。 它旨在利用现代硬件。 后端用C ++编写，并且在运行时使用代码生成来产生有效的代码路径（相对于指令数）和较小的内存开销，尤其是与Java中实现的其他引擎相比。
设计了兼容使用大量内存的算子，以便能够在需要时将部分数据溢出到磁盘上。 可能发生的运算符是 hash join, (hash-based) aggregation, sorting, and analytic function evaluation。
Runtime Code Generation 运行时代码生成
使用LLVM [8]生成运行时代码是其中之一Impala后端广泛采用的技术缩短执行时间。 性能提升达5倍或更多是典型的代表性工作负载。
LLVM是一个编译器库和相关工具的集合。与作为独立应用程序实现的传统编译器不同，LLVM设计为模块化和可重用的。 它允许Impala之类的应用程序在运行的进程中执行即时（JIT）编译，现代优化器的全部优点以及生成功能，通过公开一些体系结构的机器代码用于编译过程所有步骤的单独API。
开启和不开启的性能比较。
I/O 管理
- HDFS short-cricuit local reads 。Short-circuit read意味着会从datanode的本地文件系统直接读取数据，而不用首先与datanode进行通信，这肯定会提高性能。
- 客户端异步读取，机械硬盘1个线程，SSD硬盘8个线程
Storage Formats
支持Avro、RC、Sequence、plain text、parquet。最广泛使用的parquet（TODO）
存储资源占用大小
资源调配
- 底层实现了一个Llama 的公平资源调度器。
- 也可以使用Yarn，这时Llama会把相关资源请求转发到Yarn。
总结
1、没有使用MapReduce进行并行计算，虽然MapReduce是非常好的并行计算框架，但它更多的面向批处理模式，而不是面向交互式的SQL执行。与MapReduce相比：Impala把整个查询分成一执行计划树，而不是一连串的MapReduce任务，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce启动时间。
2、使用LLVM产生运行代码，针对特定查询生成特定代码，同时使用Inline的方式减少函数调用的开销，加快执行效率。
3、充分利用可用的硬件指令（SSE4.2）。
4、更好的IO调度，Impala知道数据块所在的磁盘位置能够更好的利用多磁盘的优势，同时Impala支持直接数据块读取和本地代码计算checksum。
5、通过选择合适的数据存储格式可以得到最好的性能（Impala支持多种存储格式）。
6、最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递。
优缺点
优点
- 基于内存运算，不需要把中间结果写入磁盘，省掉了大量的 I/O 开销。
- 无需转换为 Mapreduce，直接访问存储在 HDFS，HBase 中的数据进行作业调度，
速度快。 - 使用了支持 Data locality 的 I/O 调度机制，尽可能地将数据和计算分配在同一台机
器上进行，减少了网络开销。 - 支持各种文件格式，如 TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet。
- 可以访问 hive 的 metastore，对 hive 数据直接做数据分析
缺点
- 对内存的依赖大，且完全依赖于 hive。
- 实践中，分区超过 1 万，性能严重下降。
- 只能读取文本文件，而不能直接读取自定义二进制文件。
- 每当新的记录/文件被添加到 HDFS 中的数据目录时，该表需要被刷新、
- Hive语法非完全支持
性能比较
单用户
多用户、集群
可以看到impala完全碾压其它的工具。
传统数据库比较
TPC-DS标准