一、Impala概述

1、Impala基本概念

  • Impala是Cloudera提供的一款开源的针对HDFS和HBASE中的PB级别数据进行交互式实时查询(Impala速度快)，Impala是参照谷歌的新三篇论文当中的Dremel 实现而来，其中旧三篇论文分别是（BigTable，GFS，MapReduce）分别对应我们即将学的HBase和已经学过的HDFS以及MapReduce

  • Impala最大卖点和最大特点就是快速，Impala中文翻译是高角羚羊

    2、Impala优缺点

  • 回顾前面大数据课程路线其实就是一个大数据从业者面对的大数据相关技术发展的过程：

    • 技术发展以及更新换代的原因就是老的技术架构遇到新的问题，有些问题可以通过不断优化代码优化设计得以解决，有一些问题就不再是简简单单修改代码就能解决，需要从框架本身架构设计上改变，以至于需要推到重建
    • 在大数据领域主要解决的问题是数据的存储和分析，但是其实一个完整的大数据分析任务如果细分会有非常多具体的场景，非常多的环节；并没有一个类似Java Web的Spring框架实现大一统的局面

  • 比如我们按照阶段划分一个大数据开发任务，会有：数据采集(日志文件，关系型数据库中)，数据清洗(数据格式整理，脏数据过滤等)，数据预处理(为了后续分析所做的工作)，数据分析：离线处理(T+1分析)，实时处理(数据到来即分析)，数据可视化，机器学习，深度学习等

  • 面对如此众多的阶段再加上大数据天生的大数据量问题没有任何一个框架可以完美cover以上每个阶段。所以大数据领域有非常多框架，每个框架都有最适合自己的具体场景！！！比如：HDFS负责大数据量存储，MapReduce（Hive）负责大数据量的分析计算

Impala的诞生

  • 之前学习的Hive以及MR适合离线批处理，但是对交互式查询的场景无能为力(要求快速响应)，所以为了解决查询速度的问题，Cloudera公司依据Google的Dremel 开发了 Impala，Impala抛弃了MapReduce，使用了类似于传统的MPP数据库技术，大大提高了查询的速度

MPP是什么？

  • MPP (Massively Parallel Processing)，就是大规模并行处理，在MPP集群中，每个节点资源都是独立享有也就是有独立的磁盘和内存，每个节点通过网络互相连接，彼此协同计算，作为整体提供数据服务。

  • 简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果

  • 对于MPP架构的软件来说聚合操作比如计算某张表的总条数，则先进行局部聚合(每个节点并行计算)，然后把局部汇总结果进行全局聚合(与Hadoop相似)。

Impala与Hive对比
Impala的技术优势

  • Impala没有采取MapReduce作为计算引擎，MR是非常好的分布式并行计算框架，但MR引擎更多的是面向批处理模式，而不是面向交互式的SQL执行。与 Hive相比：Impala把整个查询任务转为一棵执行计划树，而不是一连串的MR任务，在分发执行计划后，Impala使用拉取的方式获取上个阶段的执行结果，把结果数据、按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MR启动时间。
  • 使用 LLVM (C++编写的编译器)产生运行代码，针对特定查询生成特定代码
  • 优秀的 I/O 调度，Impala支持直接数据块读取和本地代码计算
  • 选择适合的数据存储格式可以得到最好的性能（Impala支持多种存储格式）

  • 尽可能使用内存，中间结果不写磁盘，及时通过网络以 stream 的方式传递

  • mr 慢的原因**：**

    • 1、shuffle阶段，I/O
    • 2、shuffle阶段默认对key进行分区排

  • impala 的优势：

    • 1、避免数据落磁盘的I/O过程
    • 2、处理进程无需每次启动
    • 3、Impala默认不会对数据排序

Impala与Hive对比分析
查询过程**

  • Hive：在Hive中，每个查询都有一个“冷启动”的常见问题。（map，reduce每次都要启动关闭，申请资源，释放资源。。。）
  • Impala：Impala避免了任何可能的启动开销，这是一种本地查询语言。 因为要始终处理查询，则 Impala 守护程序进程（Impalad）总是在集群启动之后就准备就绪。守护进程在集群启动之后可以接收查询任务并执行查询任务

中间结果

  • Hive：Hive通过MR引擎实现所有中间结果，中间结果需要落盘，这对数据处理速度有不利影响
  • Impala：在执行程序之间使用流的方式传输中间结果，避免数据落盘，尽可能使用内存避免磁盘开销

交互查询

  • Hive：对于交互式计算，Hive不是理想的选择
  • Impala：对于数据量级为 PB 级的**交互式计算**，Impala非常适合

计算引擎

  • Hive：是基于批处理的Hadoop MapReduce
  • Impala：更像是MPP数据库

容错

  • Hive：Hive是容错的（通过MR&Yarn实现）
  • Impala：Impala没有容错（也不需要），因为具有良好的查询性能，Impala遇到错误会重新执行一次查询

查询速度

  • Impala：Impala比Hive快3-90倍

Impala优势总结

  1. Impala最大优点就是查询速度快，在一定数据量下；
  2. 速度快的原因：避免了MR引擎的弊端，采用了MPP数据库技术

Impala缺点总结

  1. Impala属于MPP架构，只能做到百节点级，⼀般并发查询个数达到20左右时，整个系统的吞吐已经达到满负荷状态，在扩容节点也提升不了吞吐量，处理数据量在PB级别最佳。
  2. 资源不能通过YARN统⼀资源管理调度，所以Hadoop集群⽆法实现Impala、Spark、Hive等组件的动态资源共享。

    3、使用场景（Hive vs Impala）

  • Hive: 复杂的批处理查询任务，数据转换任务，对实时性要求不高同时数据量又很大的场景

  • Impala：实时数据分析，与Hive配合使用，对Hive的结果数据集进行实时分析。impala不能完全取代hive，impala可以直接处理hive表中的数据

    三、Impala架构原理

    1、Impala的组件

  • Impala是一个分布式，大规模并行处理(MPP)数据库引擎，它包括多个进程。

  • Impala与Hive类似，是数据分析工具，而不是数据库

    • image.png

      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进程安排同个节点

    2、Impala的查询

    image.png
  1. Client提交任务
  • Client发送一个SQL查询请求到任意一个Impalad节点，会返回一个queryId用于之后的客户端操作
  1. 生成 单机执行计划 和 分布式执行计划
  • SQL提交到Impalad节点之后，Analyser依次执行SQL的词法分析、语法分析、语义分析等操作；从MySQL元数据库中获取元数据，从HDFS的名称节点中获取数据地址，以得到存储这个查询相关数据的所有数据节点
    • 单机执行计划： 根据上一步对SQL语句的分析，由Planner先生成单机的执行计划，该执行计划是有PlanNode组成的一棵树，这个过程中也会执行一些SQL优化，例如Join顺序改变、谓词下推等。
    • 分布式并行物理计划：将单机执行计划转换成分布式并行物理执行计划，物理执行计划由一个个的Fragment组成，Fragment之间有数据依赖关系，处理过程中需要在原有的执行计划之上加入一些ExchangeNode和DataStreamSink信息等。
      • Fragment：sql生成的分布式执行计划的一个子任务；
      • DataStreamSink：传输当前的Fragment输出数据到不同的节点
  1. 任务调度和分发
  • Coordinator将Fragment(子任务)根据数据分区信息发配到不同的Impalad节点上执行。Impalad节点接收到执行Fragment请求交由Executor执行。
  1. Fragment之间的数据依赖
  • 每一个Fragment的执行输出通过DataStreamSink发送到下一个Fragment，Fragment运行过程中不断向coordinator节点汇报当前运行状态。
  1. 结果汇总
  • 查询的SQL通常情况下需要有一个单独的Fragment用于结果的汇总，它只在Coordinator节点运行，将多个节点的最终执行结果汇总，转换成ResultSet信息。
  1. 获取结果

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

    查询计划示例

  • 以一个SQL例子来展示查询计划，其SQL语句为：

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

  • QueryPlanner生成单机的执行计划

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

      image.png

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

image.png

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

image.png

  • 分布式并行计划流程
    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计算，返回结果给用户