CC00006.hadoop——|Hadoop&Impala.V06|——|Impala.v06|架构原理|

yanqi_vip

已于 2022-04-10 16:56:41 修改

阅读量56

点赞数

分类专栏： bigdatav008——hadoop.v003 文章标签：分布式数据库大数据 python java

于 2022-04-08 15:03:00 首次发布

不予转载

本文链接：https://blog.csdn.net/yanqi_vip/article/details/124054940

版权

bigdatav008——hadoop.v003 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

一、Imapla的架构原理

### --- [交互查询工具Impala]   

~~~     [Impala架构原理]                                                                                                  
~~~     [Impala单机执行计划]
~~~     [Impala分布式执行计划]
~~~     [Impala查询流程分析]

### --- Impala的组件

~~~     Impala是一个分布式，大规模并行处理(MPP)数据库引擎，它包括多个进程。
~~~     Impala与Hive类似不是数据库而是数据分析工具；

### --- 在linux123执行ps -ef | grep impala

[root@linux123 ~]# ps -ef | grep impala
impala    18419      1  0 17:49 ?        00:00:07 /usr/lib/impala/sbin/statestored -log_dir=/var/log/impala -state_store_port=24000
impala    18453      1  0 17:49 ?        00:00:22 /usr/lib/impala/sbin/catalogd -log_dir=/var/log/impala
impala    18488      1  0 17:49 ?        00:00:27 /usr/lib/impala/sbin/impalad -log_dir=/var/log/impala -catalog_service_host=linux123 -state_store_port=24000 -use_statestore -state_store_host=linux123 -be_port=22000
root      19722  10928  0 18:05 pts/2    00:00:00 python /usr/lib/impala-shell/impala_shell.py

### --- impalad

~~~     ⻆色名称为Impala Daemon,是在每个节点上运行的进程，是Impala的核⼼组件，进程名是Impalad;
~~~     作用，负责读写数据文件，接收来自Impala-shell，JDBC,ODBC等的查询请求，
~~~     与集群其它Impalad分布式并行完成查询任务，并将查询结果返回给中心协调者。
~~~     为了保证Impalad进程了解其它Impalad的健康状况，Impalad进程会一直与statestore保持通信。
~~~     # Impalad服务由三个模块组成：Query Planner、Query Coordinator和Query Executor，
~~~     前两个模块组成前端，负责接收SQL查询请求，解析SQL并转换成执行计划，交由后端执行，

### --- statestored

~~~     statestore监控集群中Impalad的健康状况，并将集群健康信息同步给Impalad,
~~~     statestore进程名为statestored

### --- catalogd

~~~     Impala执行的SQL语句引发元数据发生变化时，
~~~     catalog服务负责把这些元数据的变化同步给其它Impalad进程(日志验证,监控statestore进程日志)
~~~     catalog服务对应进程名称是catalogd
~~~     由于一个集群需要一个catalogd以及一个statestored进程，
~~~     而且catalogd进程所有请求都是经过statestored进程发送，
~~~     所以官方建议让statestored进程与catalogd进程安排同个节点。

二、Impala的查询

### --- Client提交任务

~~~     Client发送一个SQL查询请求到任意一个Impalad节点，
~~~     会返回一个queryId用于之后的客户端操作。

### --- 生成单机和分布式执行计划

~~~     SQL提交到Impalad节点之后，Analyser依次执行SQL的词法分析语法分析语义分析等操作；
~~~     从MySQL元数据库中获取元数据，从HDFS的名称节点中获取数据地址，
~~~     以得到存储这个查询相关数据的所有数据节点

~~~     # 单机执行计划： 
~~~     根据上一步对SQL语句的分析，由Planner先生成单机的执行计划，
~~~     该执行计划是有PlanNode组成的一棵树，这个过程中也会执行一些SQL优化，
~~~     例如Join顺序改变、谓词下推等。
~~~     # 分布式并行物理计划：
~~~     将单机执行计划转换成分布式并行物理执行计划，物理执行计划由一个的Fragment组成，
~~~     Fragment之间有数据依赖关系，
~~~     处理过程中需要在原有的执行计划之上加入一些ExchangeNode和DataStreamSink信息等。

~~~     # Fragment ： 
~~~     sql生成的分布式执行计划的一个子任务；
~~~     # DataStreamSink：
~~~     传输当前的Fragment输出数据到不同的节点

### --- 任务调度和分发

~~~     Coordinator将Fragment(子任务)根据数据分区信息发配到不同的Impalad节点上执行。
~~      Impalad节点接收到执行Fragment请求交由Executor执行。

### --- Fragment之间的数据依赖

~~~     每一个Fragment的执行输出通过DataStreamSink发送到下一个Fragment，
~~~     Fragment运行过程中不断向coordinator节点汇报当前运行状态。

### --- 结果汇总

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

### --- 获取结果

~~~     客户端调用获取ResultSet的接口，读取查询结果。

### --- 查询计划示例

~~~     以一个SQL例子来展示查询计划

### --- 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;

### --- QueryPlanner生成单机的执行计划

~~~     分析上面的单机执行计划，第一步先去扫描t1表中需要的数据，
~~~     如果数据文件存储是列式存储我们可以便利的扫描到所需的列id,n1;
~~~     接着需要与t2表进行Join操作，扫描t2表与t1表类似获取到所需数据列id,n2;
~~~     t1与t2表进行关联，关联之后再与t3表进行关联，
~~~     这里Impala会使用谓词下推扫描t3表只取join所需数据；
~~~     对group by进行相应的aggregation操作，最终是排序取出指定数量的数据返回。

### --- 分布式并⾏执⾏计划

~~~     所谓的分布式并行执⾏计划就是在单机执⾏计划基础之上结合数据分布式存储的特点，
~~~     按照任务的计算要求把单机执⾏计划拆分为多段⼦任务，每个⼦任务都是可以并行执行的。
~~~     上⾯面的单机执行计划转为分布式并行执行计划如下图所示：

### --- 分布式并行执行计划流程图

~~~     分布式执行计划中涉及到多表的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与T2Join之后的结果数据再与T3表进行Join,
~~~     此时T3表采用Broadcast方式把自己全部数据(id列)广播到需要的Impala节点上
~~~     T1,T2,T3Join之后再根据Group by执行本地的预聚合，
~~~     # 每一个节点的预聚合结果只是最终结果的一部分(不同的节点可能存在相同的group by的值)，
~~~     需要再进行一次全局的聚合。

~~~     # 全局的聚合同样需要并行，则根据聚合列进行Hash分散到不同的节点执行Merge运算
~~~     (其实仍然是一次聚合运算)，一般情况下为了较少数据的网络传输， 
~~~     Impala会选择之前本地聚合节点做全局聚合工作。
~~~     # 通过全局聚合之后，相同的key只存在于一个节点，然后对于每一个节点进行排序和TopN计算，
~~~     最终将每一个全局聚合节点的结果返回给Coordinator进行合并、排序、limit计算，
~~~     返回结果给用户.