Impala 整体架构了解 一 Impala官网

PB级大数据实时查询分析引擎，具有实时、批处理、多并发等优点，提供对HDFS、Hbase数据的低延迟 SQL 查询；Impala 不使用 MapReduce，通过分布式查询引擎访问数据，比 Hive 快一个数量级的性能；Hive 适合于长时间批处理分析，Impala 适合于实时 SQL 查询

用途

Impala 提高了基于 Hadoop 的 SQL 查询性能。实时查询HDFS 或 HBase 数据。Impala 与 Hive 有相同元数据、SQL 语法 、ODBC ，为面向批处理或实时查询提供统一平台

二 IMPALA & HIVE

1.1 Impala相对于Hive所使用的优化技术

1、不使用 MapReduce 因为其实面向批处理模式，而不是交互式的SQL执行

2、使用LLVM产生运行代码，针对特定查询生成特定代码，加快执行效率

3、更好的 IO 调度，Impala 知道数据块所在的磁盘位置，且支持直接数据块读取和本地代码计算 checksum

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

5、最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递

1.2 Impala 与 Hive 的不同

1、执行计划

Hive: 依赖 MapReduce 执行框架，执行计划分成 map->shuffle->reduce->map->shuffle->reduce… 模型。一个 Query 被编译成多轮 MapReduce，会有更多的写中间结果。由于 MapReduce 执行框架本身的特点，过多的中间过程会增加整个 Query 的执行时间

Impala: 把执行计划为一棵执行树，分发执行计划到各个 Impalad 执行查询，不像 Hive 把它组合成管道型的map->reduce 模式，保证 Impala 更好的并发性和避免不必要的中间 sort 与 shuffle

2、数据流

Hive: 推的方式，下层节点完成后将数据主动推给上层节点

Impala: 拉的方式，上层节点主动向下层节点要数据，数据流式返回客户端，只要有数据被处理完，即返回而不用等全部处理完，更符合 SQL 交互式查询

3、调度 Hive: 任务调度依赖于Hadoop的调度策略

Impala: 调度由自己完成，目前只有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器目前还比较简单，在 SimpleScheduler::GetBackend 中可以看到，现在还没有考虑负载，网络IO状况等因素进行调度。但目前 Impala 已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度

5、容错 Hive: 依赖于Hadoop的容错能力

Impala: 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误

三 Apache Impala概念和架构

Impala 是一个分布式并行处理(MPP)数据库引擎。由不同守护进程组成，运行在CDH集群中

impalad

impalad 是 impala 的核心组件，它是一个守护进程，运行在集群每个数据节点（DataNode）上，负责读取和写入数据文件；并行化查询请求并在整个集群中分配工作；将中间查询结果传输回中央协调器节点；接受从 impala-shell 传递的命令，Hue、JDBC 或 ODBC传输的查询。

Impala 守护进程与 statestore 一直保持通信，以确认哪些节点是健康的，可以接受新任务

在CDH 5.12 / Impala 2.9和更高版本中，可以控制哪些主机充当查询协调器，哪些主机充当查询执行器，以提高大型集群中高并发负载的可伸缩性

当集群中的任何 Impala 节点创建、修改或删除任何类型的对象时，或者当 Impala 处理插入（INSERT ）或加载（LOAD DATA）操作时，它们也会接收来自 catalogd 守护进程 (在Impala 1.2中引入) 的广播消息。这种后台通信使得在Impala 1.2之前，跨节点协调元数据所需的刷新（REFRESH ）或设置元数据失效（INVALIDATE METADATA ）功能的操作次数降到最低

??名称为Impala Daemon,是在每个节点上运?的进程，是Impala的核?组件，进程名是Impalad

Impalad服务由三个模块组成：Query Planner、Query Coordinator和Query Executor，前两个模块组成前端，负责接收SQL查询请求，解析SQL并转换成执?计划，交由后端执?

状态存储进程 Statestored

statestore 只需在集群的某一个主机上运行，负责检查集群中所有 DataNode 上的 impalad 状态，并不断地将其结果转发给每个守护进程

statestore 是当群集状态出错时提供帮助，对 Impala 集群运行不重要。若 statestore 不运行了 impalad 将继续运行，但如果这时其它的 impalad 脱机，集群就变得不健壮了。当 statestore重新上线时，它会重新建立与 impalad 的通信，并恢复其监控功能

负载平衡和高可用性的大多数考虑都适用于impalad守护进程。statestored 和catalogd 守护进程对高可用性没有特殊要求，因为这些守护进程的问题不会导致数据丢失。如果这些守护进程由于某个主机的中断而不可用，您可以停止Impala服务，删除Impala StateStore和Impala目录服务器角色，然后在另一个主机上添加这些角色，并重新启动Impala服务

目录服务进程catalogd

作为metadata访问网关，从Hive Metastore等外部catalog中获取元数据信息，放到impala自己的catalog结构中。impalad执行ddl命令时通过catalogd由其代为执行，该更新则由statestored广播

目录服务避免了执行更改元数据语句时要执行 REFRESH（刷新） 和 INVALIDATE METADATA（使元数据无效） 操作（HIVE创建一个表、加载数据等操作时，需要在这个节点上 REFRESH 再执行查询）

当数据更改操作通过 Impala执行，不需要 REFRESH ，若这些操作通过 Hive 或直接在 HDFS 中操作数据文件，那么只需要在一个 Impala 节点上执行更新即可，不需要在所有节点上执行一回

系统启动时，元数据加载和缓存是异步的，因此 Impala 可以立即开始接受请求。如果需要 Impala 等待所有元数据在接受任何请求之前加载好，可以设置 catalogd 配置选项 —— load_catalog_in_background=false

负载均衡和高可用适用于 impalad，statestored 和 catalogd 无高可用性，因为不会导致数据丢失。若某个主机的中断而不可用，可以停止 Impala 服务，删除 Impala StateStore 和 Impala 目录服务器角色，在另一个主机上添加这些角色，并重新启动Impala服务

catalogd 会在 Impala 集群启动的时候加载 hive 元数据信息到 Impala，其他时候不会主动加载，需要使用invalidate metadata，refresh命令；由于?个集群需要?个 catalogd 以及?个 statestored 进程，?且 catalogd 进程所有请求都是经过 statestored 进程发送，所以官?建议让 statestored 进程与 catalogd 进程安排同个节点

四 查询过程

具体流程

1.Client提交任务 Client发送?个SQL查询请求到任意?个Impalad节点，会返回?个 queryId ?于之后的客户端操作

2.生成查询计划（单机计划、分布式执行计划） SQL提交到Impalad节点之后，Analyser 依次执? SQL 的词法分析、语法分析、语义分析等操作；从MySQL元数据库中获取元数据，从HDFS的名称节点中获取数据地址，以得到存储这个查询相关数据的所有数据节点

单机执行计划：根据上?步对SQL语句的分析，由Planner先?成单机的执?计划，该执?计划是有PlanNode组成的?棵树，这个过程中也会执??些SQL化，例如Join顺序改变、谓词下推等

分布式并?物理计划：将单机执?计划转换成分布式并?物理执?计划，物理执?计划由?个个的Fragment组成，Fragment之间有数据依赖关系，处理过程中要在原有的执?计划之上加??些ExchangeNode和DataStreamSink信息等。

Fragment ： sql?成的分布式执?计划的?个?任务

DataStreamSink：传输当前的Fragment输出数据到不同的节点

3.任务调度和分发 Coordinator将Fragment(?任务)根据数据分区信息发配到不同的Impalad节点上执?，Impalad节点接收到执?Fragment请求交由Executor执?

4. Fragment之间的数据依赖 每?个Fragment的执?输出通过DataStreamSink发送到下?个Fragment，Fragment运?过程中不断向coordinator节点汇报当前运?状态

5. 结果汇总 查询的SQL通常情况下需要有?个单独的Fragment?于结果的汇总，它只在Coordinator节点运?，将多个节点的最终执?结果汇总，转换成ResultSet信息

6. 获取结果 客户端调?获取ResultSet的接?，读取查询结果

单机执行计划

以?个SQL例?来展示查询计划

select t1.n1, t2.n2, count(1) as c from t1 join t2 on t1.id = t2.id join t3 on t1.id = t3.id where t3.n3 between ‘a’ and ‘f’ group by t1.n1, t2.n2 order by c desc limit 100;

分析上图流程：

第一步去扫描t1表中的需要的数据 n1、id 列，再扫描 t2 表需要的数据 n2、id 列，然后这部分数据进行Join操作

t1 表和 t2 表关联后，同样的操作，将中间结果表和 t3 进行关联 Join，此处 Impala 会使用谓词下推优化，只读取需要的数据进行表 Join

将最后的结果数据进行聚合操作

分布式执行计划

分布式执?计划中涉及到多表的 Join,Impala 会根据表的??来决定 Join 的?式，主要有两种分别是 HashJoin 与Broadcast Join，上?分布式执?计划中可以看出 T1,T2 表??些，? T3 表??些，所以对于 T1 与T2的 Join Impala 选择使? Hash Join，对于T3表选择使? Broadcast ?式，直接把 T3 表?播到需要Join的节点上

分布式并行计划流程

T1 和 T2 使? Hash join，此时需要按照 id 的值分别将 T1 和 T2 分散到不同的 Impalad 进程，但是相同的 id会散列到相同的Impalad进程，这样每?个Join之后是全部数据的?部分T1 与 T2 Join 之后的结果数据再与 T3 表进?Join，此时 T3 表采? Broadcast ?式把??全部数据(id列)?播到需要的 Impala 节点上T1，T2，T3 Join 之后再根据 Group by 执?本地的预聚合，每?个节点的预聚合结果只是最终结果的?部分（不同的节点可能存在相同的group by的值），需要再进??次全局的聚合全局的聚合同样需要并?，则根据聚合列进? Hash 分散到不同的节点执? Merge 运算（其实仍然是?次聚合运算），?般情况下为了较少数据的?络传输， Impala会选择之前本地聚合节点做全局聚合?作 T1，T2，T3 Join 之后再根据 Group by 执?本地的预聚合，每?个节点的预聚合结果只是最终结果的?部分（不同的节点可能存在相同的group by的值），需要再进??次全局的聚合全局的聚合同样需要并?，则根据聚合列进? Hash 分散到不同的节点执? Merge 运算（其实仍然是?次聚合运算），?般情况下为了较少数据的?络传输， Impala会选择之前本地聚合节点做全局聚合?作通过全局聚合之后，相同的 key 只存在于?个节点，然后对于每?个节点进?排序和 TopN 计算，最终将每?个全局聚合节点的结果返回给 Coordinator 进?合并、排序、limit计算，返回结果给?户

---

1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。