交互式查询工具Impala

最新推荐文章于 2023-07-26 16:54:10 发布

猿大山

最新推荐文章于 2023-07-26 16:54:10 发布

阅读量806

点赞数 1

分类专栏： Hadoop 文章标签： impala

本文链接：https://blog.csdn.net/betterkunpeng/article/details/114482611

版权

Hadoop 专栏收录该内容

10 篇文章 3 订阅

订阅专栏

第 1 部分 Impala概述

1.1 Impala是什什么

Impala是Cloudera提供的⼀一款开源的针对HDFS和HBASE中的PB级别数据进⾏行行交互式实时查询(Impala速度快)，Impala是参照⾕谷歌的新三篇论⽂文当中的Dremel实现⽽而来，其中旧三篇论⽂文分别是（BigTable，GFS，MapReduce）分别对应我们即将学的HBase和已经学过的HDFS以及MapReduce。Impala最⼤大卖点和最⼤大特点就是快速，Impala中⽂文翻译是⾼高⻆角羚⽺羊。

1.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++编写的编译器器)产生运行行代码，针对特定查询⽣生成特定代码。
优秀的IO调度，Impala⽀支持直接数据块读取和本地代码计算。
选择适合的数据存储格式可以得到最好的性能（Impala⽀支持多种存储格式）。
尽可能使⽤用内存，中间结果不不写磁盘，及时通过⽹网络以stream的⽅方式传递。
Impala与Hive对⽐比分析
查询过程
Hive：在Hive中，每个查询都有⼀一个“冷启动”的常⻅见问题。（map,reduce每次都要启动关闭，申请资源，释放资源。。。）
Impala：Impala避免了了任何可能的启动开销，这是⼀一种本地查询语⾔言。因为要始终处理理查询，则Impala守护程序进程总是在集群启动之后就准备就绪。守护进程在集群启动之后可以接收查询任务并执⾏行行查询任务。
中间结果
Hive：Hive通过MR引擎实现所有中间结果，中间结果需要落盘，这对降低数据处理理速度有不不利利影响。
Impala：在执⾏行行程序之间使⽤用流的⽅方式传输中间结果，避免数据落盘。尽可能使⽤用内存避免磁盘开销
交互查询
Hive：对于交互式计算，Hive不不是理理想的选择。
Impala：对于交互式计算，Impala⾮非常适合。(数据量量级PB级)
计算引擎
Hive：是基于批处理理的Hadoop MapReduce
Impala：更更像是MPP数据库容错
Hive：Hive是容错的（通过MR&Yarn实现）
Impala：Impala没有容错，由于良好的查询性能，Impala遇到错误会重新执行一次查询
查询速度
Impala：Impala⽐比Hive快3-90倍。
Impala优势总结
1. Impala最⼤大优点就是查询速度快，在⼀一定数据量量下；
2. 速度快的原因：避免了了MR引擎的弊端，采⽤用了MPP数据库技术

1.3 Impala的缺点

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

1.4 适⽤用场景

Hive: 复杂的批处理理查询任务，数据转换任务，对实时性要求不不⾼高同时数据量量⼜又很⼤大的场景。
Impala：实时数据分析，与Hive配合使⽤用,对Hive的结果数据集进⾏行行实时分析。impala不不能完全取代hive，impala可以直接处理理hive表中的数据。

第 2 部分 Impala 安装与入门案例例

2.1 集群准备

2.1.1 安装Hadoop,Hive
Impala的安装需要提前装好Hadoop，Hive这两个框架，
hive需要在所有的Impala安装的节点上⾯面都要有，因为Impala需要引⽤用Hive的依赖包，
hadoop的框架需要⽀支持C程序访问接⼝口，查看下图，如果有该路路径有.so结尾⽂文件，就证明支持C接口。

2.1.2 准备Impala的所有依赖包
Cloudera公司对于Impala的安装只提供了了rpm包没有提供tar包；所以我们选择使⽤用Cloudera的rpm包进行行Impala的安装，但是另外⼀一个问题，Impala的rpm包依赖⾮非常多的其他的rpm包，我们可以⼀个个的将依赖找出来，但是这种⽅方式实在是浪费时间。
Linux系统中对于rpm包的依赖管理理提供了了⼀一个⾮非常好的管理理⼯工具叫做Yum,类似于Java工程中的包管理工具Maven,Maven可以⾃自动搜寻指定Jar所需的其它依赖并自动下载来。Yum同理理可以非常方便便的让我们进行rpm包的安装无需关系当前rpm所需的依赖。但是与Maven下载其它依赖需要到中央仓库一样
Yum下载依赖所需的源也是在放置在国外服务器器并且其中没有安装Impala所需要的rpm包，所以默认的这种Yum源可能下载依赖失败。所以我们可以⾃自⼰己指定Yum去哪里下载所需依赖。
rpm⽅方式安装:需要自己管理理rpm包的依赖关系；非常麻烦；解决依赖关系使用yum；默认Yum源是没有Impala的rpm安装包，所以我们自己准备好所有的Impala安装所需的rpm包，制作Yum本地源，配置Yum命令去到我们准备的Yun源中下载Impala的rpm包进行行安装。
Yum命令默认源

本地Yum源方式

第 3 部分 Imapla的架构原理

第 1 节 Impala的组件

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

#在linux123执⾏ps -ef | grep impala
#结果
impala 29212 1 0 Jul02 ? 00:01:06/usr/lib/impala/sbin/statestored -log_dir=/var/log/impala-state_store_port=24000
impala 29249 1 0 Jul02 ? 00:00:49/usr/lib/impala/sbin/catalogd -log_dir=/var/log/impala
impala 29341 1 0 Jul02 ? 00:00:49 /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

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的查询

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例例子来展示查询计划
SQL语句句
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的节点上。
分布式并行计划流程
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计算，返回结果给用户.

第 4 部分 Impala的使用

Impala的核心开发语言是sql语句句，Impala有shell命令行窗口，以及JDBC等方式来接收sql语句执行，对于复杂类型分析可以使用C++或者Java来编写UDF函数。
Impala的sql语法是高度集成了Apache Hive的sql语法，Impala支持Hive支持的数据类型以及部分Hive的内置函数。
需要注意的几点：
1. Impala与Hive类似它们的重点都是在与查询，所以像Update,delete等具有更新性质的操作最好不不要使用这种工具，对于删除数据的操作可以通过Drop Table,Alter Table Drop Partition来实现，更新可以尝试使用Insert overwrite式
2. 通常使用Impala的方式是数据文件存储在Hdfs文件系统，借助于Impala的表定义来查询和管理理Hdfs上的数据文件；
3. Impala的使用大多数与Hive相同，比如Impala同样支持内外部表，以及分区等，可以借鉴参考Hive的使用。

第 1 节 Impala-shell命令参数

1.1 impala-shell外部命令
所谓的外部命令指的是不需要进入到impala-shell交互命令行当中即可执行的命令参数。impala-shell后面执行的时候可以带很多参数。你可以在启动 impala-shell 时设置，用于修改命令执行环境。
impala-shell –h可以帮助我们查看帮助手册。也可以参考课程附件资料料。
比如几个常见的：
impala-shell –r刷新impala元数据，与建立连接后执行 REFRESH 语句句效果相同(元数据发生变化的时候)
impala-shell –f 文件路路径执行指的的sql查询⽂文件。
impala-shell –i指定连接运行 impalad 守护进程的主机。默认端⼝口是 21000。你可以连接到集群中运行impalad 的任意主机。
impala-shell –o保存执行结果到文件当中去。

展示Impala默认支持的内置函数需要进入Impala默认系统数据库中执行，在其它数据库下无法查看！！

show functions;

1.2 impala-shell内部命令
所谓内部命令是指，进入impala-shell命令行之后可以执行的语法。
connect hostname 连接到指定的机器器impalad上去执行。

refresh dbname.tablename增量刷新，刷新某一张表的元数据，主要用于刷新hive当中数据表里面的数据改变的情况。

invalidate metadata全量刷新，性能消耗较大，主要⽤用于hive当中新建数据库或者数据库表的时候来进行刷新。
quit/exit命令从Impala shell中退出
explain 命令用于查看sql语句句的执行计划。

explain的值可以设置成0,1,2,3等几个值，其中3级别是最⾼高的，可以打印出最全的信息

set explain_level=3;

profile命令执行sql语句句之后执行，可以打印出更加详细的执行步骤，主要用于查询结果的查看，集群的调优等

第 6 部分 Impala进阶
第 1 节 Impala的负载均衡
Impala主要有三个组件，分别是statestore，catalog和impalad，对于Impalad节点，每一个节点都可以接收客户端的查询请求，并且对于连接到该Impalad的查询还要作为Coordinator节点（需要消耗一定的内存和CPU）存在，为了了保证每一个节点的资源开销的平衡需要对于集群中的Impalad节点做一下负载均衡.

Cloudera官⽅方推荐的代理理方案:HAProxy
DNS做负载均衡

DNS做负载均衡⽅方案是最简单的，但是性能一般，所以这⾥里里我们按照官⽅方的建议使用HAProxy实现负载均衡
生产中应该选择一个非Impalad节点作为HAProxy的安装节点
1.1 HAProxy方案
安装haproxy

yum install haproxy -y

配置文件

vim /etc/haproxy/haproxy.cfg

第 2 节 Impala优化
cloudera官网上的Impala文档，原名为《Impala Performance Guidelines and Best Practices》。主要介绍了为了提升impala性能应该考虑一些事情，结合实际考虑：
1. 基本优化策略
文件格式

对于大数据量量来说，Parquet⽂文件格式是最佳的

避免小文件

insert ... values 会产生大量量小文件，避免使用

合理理分区粒度

利用分区可以在查询的时候忽略掉无用数据，提高查询效率，通常建议分区数量在3万以下(太多的分区也会造成元数据管理理的性能下降)

分区列列数据类型最好是整数类型

分区列可以使用string类型，因为分区列列的值最后都是作为HDFS⽬目录使⽤用，如果分区列列使用整数类型可以降低内存消耗

获取表的统计指标：在追求性能或者大数据量查询的时候，要先获取所需要的表的统计指标(如:执行compute stats )

减少传输客户端数据量
聚合(如 count、sum、max 等)
过滤(如WHERE )
limit限制返回条数
返回结果不要使用美化格式进行展示(在通过impala-shell展示结果时，添加这些可选参数: -B、 --output_delimiter )

在执行之前使⽤用EXPLAIN来查看逻辑规划，分析执行逻辑
Impala join自动的优化手段就是通过使用COMPUTE STATS来收集参与Join的每张表的统计信息，然后由Impala根据表的大小、列列的唯一值数目等来自动优化查询。为了了更更加精确地获取每张表的统计信息，每次表的数据变更时(如执⾏行行Insert,add partition,drop partition等)最好
都要执行一遍COMPUTE STATS获取到准确的表统计信息。

猿大山

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
2
评论
交互式查询工具Impala

第 1 部分 Impala概述1.1 Impala是什什么Impala是Cloudera提供的⼀一款开源的针对HDFS和HBASE中的PB级别数据进⾏行行交互式实时查询(Impala速度快)，Impala是参照⾕谷歌的新三篇论⽂文当中的Dremel实现⽽而来，其中旧三篇论⽂文分别是（BigTable，GFS，MapReduce）分别对应我们即将学的HBase和已经学过的HDFS以及MapReduce。Impala最⼤大卖点和最⼤大特点就是快速，Impala中⽂文翻译是⾼高⻆角羚⽺羊。1.2
复制链接

扫一扫

专栏目录