大数据序列十三:交互式查询工具-Impala(下)

        上一章节简单说了下impala的优缺点，并和hive简单做了对比，本章节具体聊聊impala的架构原理(安装请移步度娘)。

     

Imapla的架构原理   

        Impala的组件

        Impala是⼀个分布式，⼤规模并⾏处理(MPP)数据库引擎，它包括多个进程。Impala与Hive类似，不是数据库⽽是数据分析⼯具；

        先说下上图的名词：

        impalad：

        1：⻆⾊名称为Impala Daemon,是在每个节点上运⾏的进程，是Impala的核⼼组件，进程名是Impalad;

        2：作⽤，负责读写数据⽂件，接收来⾃Impala-shell，JDBC,ODBC等的查询请求，与集群其它Impalad分布式并⾏完成查询任务，并将查询结果返回给中⼼协调者。

        3：为了保证Impalad进程了解其它Impalad的健康状况，Impalad进程会⼀直与statestore保持通信。

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

        statestored：

        1：statestore监控集群中Impalad的健康状况，并将集群健康信息同步给Impalad

        2：statestore进程名为statestored

        catalogd：

        1：Impala执⾏的SQL语句引发元数据发⽣变化时，catalog服务负责把这些元数据的变化同步给其它Impalad进程(⽇志验证,监控statestore进程⽇志)

        2：catalog服务对应进程名称是catalogd

        3：由于⼀个集群需要⼀个catalogd以及⼀个statestored进程，⽽且catalogd进程所有请求都是经过statestored进程发送，所以官⽅建议让statestored进程与catalogd进程安排同个节点。

        从上图可看出impala确实比hive要精简很多，舍去很多不需要的执行过程和执行逻辑，比如一个客户端通过jdbc发起一个数据更新请求，首次会先进入所有impala节点的其中一个节点的核心组件impalad，然后由impalad核心组件内部的query planner生成执行计划，其次通过query coordinator进行sql解析和sql转换，最后通过query executor执行引擎从hdfs中更新对应数据。(其实当impala集群启动时就默认启动了多个守护线程在等待着用户的操作)，但是中途可能会发生节点故障，所以需要statestore监控集群中Impalad的健康状况然后汇报给impalad，如果用户的jdbc操作对元数据做了变动，那么需要catalogd服务负责把这些元数据的变化同步给其它Impalad进程。

        以上是impala的更新操作，再来看看查询：

        Impala的查询

        步骤划分：

        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的接⼝，读取查询结果。

        QueryPlanner⽣成单机的执⾏计划

        举例说明：

        sql语句：

        分布式并⾏执⾏计划

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

        

分布式并⾏执⾏计划流程图        

        分布式执⾏计划中涉及到多表的Join,Impala会根据表的⼤⼩来决定Join的⽅式，主要有两种分别是HashJoin与Broadcast Join

        上⾯分布式执⾏计划中可以看出T1,T2表⼤⼀些，⽽T3表⼩⼀些，所以对于T1与T2的Join Impala选择使⽤Hash Join,对于T3表选择使⽤Broadcast ⽅式，直接把T3表传播到需要Join的节点上。

        分布式并⾏计划流程:

        1. T1和T2使⽤Hash join，此时需要按照id的值分别将T1和T2分散到不同的Impalad进程，但是相同的id会散列到相同的Impalad进程，这样每⼀个Join之后是全部数据的⼀部分。

        2. T1与T2Join之后的结果数据再与T3表进⾏Join,此时T3表采⽤Broadcast⽅式把⾃⼰全部数据(id列)传播到需要的Impala节点上。

        3. T1,T2,T3Join之后再根据Group by执⾏本地的预聚合，每⼀个节点的预聚合结果只是最终结果的⼀部分（不同的节点可能存在相同的group by的值），需要再进⾏⼀次全局的聚合。

        4. 全局的聚合同样需要并⾏，则根据聚合列进⾏Hash分散到不同的节点执⾏Merge运算（其实仍然是⼀次聚合运算），⼀般情况下为了较少数据的⽹络传输， Impala会选择之前本地聚合节点做全局聚合⼯作。

        5. 通过全局聚合之后，相同的key只存在于⼀个节点，然后对于每⼀个节点进⾏排序和TopN计算，最终将每⼀个全局聚合节点的结果返回给Coordinator进⾏合并、排序、limit计算，返回结果给⽤户。   

                                      ╭─  ─  ─  ─  ─  ─  ─  ─  ─  ─╮

                                      ┃      Flying  Young   ┃

                              ╰ ─  ─  ─  ─  ─  ─  ─  ─  ─  ─  ─  ─  ─╯