首页 > 其他分享 >客快物流大数据项目(七十):Impala入门介绍 一般有用 看1

客快物流大数据项目(七十):Impala入门介绍 一般有用 看1

时间:2024-03-29 17:58:15浏览次数:22  
标签:Impala 七十 Impalad Hive 查询 hive 客快 数据

Impala入门介绍

一、impala基本介绍

impala是cloudera提供的一款高效率的sql查询工具,提供实时的查询效果,官方测试性能比hive快10到100倍,其sql查询比sparkSQL还要更加快速,号称是当前大数据领域最快的查询sql工具,

impala是参照谷歌的新三篇论文(Caffeine--网络搜索引擎、Pregel--分布式图计算、Dremel--交互式分析工具)当中的Dremel实现而来,其中旧三篇论文分别是(BigTable,GFS,MapReduce)分别对应我们即将学的HBase和已经学过的HDFS以及MapReduce。

impala是基于hive并使用内存进行计算,兼顾数据仓库,具有实时,批处理,多并发等优点

Kudu与Apache Impala (孵化)紧密集成,impala天然就支持兼容kudu,允许开发人员使用Impala的SQL语法从Kudu的tablets 插入,查询,更新和删除数据;

二、Impala与hive的关系

impala是基于hive的大数据分析查询引擎,直接使用hive的元数据库metadata,意味着impala元数据都存储在hive的metastore当中,并且impala兼容hive的绝大多数sql语法。所以需要安装impala的话,必须先安装hive,保证hive安装成功,并且还需要启动hive的metastore服务。

Hive元数据包含用Hive创建的database、table等元信息。元数据存储在关系型数据库中,如Derby、MySQL等。

客户端连接metastore服务,metastore再去连接MySQL数据库来存取元数据。有了metastore服务,就可以有多个客户端同时连接,而且这些客户端不需要知道MySQL数据库的用户名和密码,只需要连接metastore 服务即可

Hive适合于长时间的批处理查询分析,而Impala适合于实时交互式SQL查询。可以先使用hive进行数据转换处理,之后使用Impala在Hive处理后的结果数据集上进行快速的数据分析。

三、​​​​​​​Impala与hive的异同

Impala 与Hive都是构建在Hadoop之上的数据查询工具各有不同的侧重适应面,但从客户端使用来看Impala与Hive有很多的共同之处,如数据表元数据、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。

但是Impala跟Hive最大的优化区别在于:没有使用 MapReduce进行并行计算,虽然MapReduce是非常好的并行计算框架,但它更多的面向批处理模式,而不是面向交互式的SQL执行。与 MapReduce相比,Impala把整个查询分成一执行计划树,而不是一连串的MapReduce任务,在分发执行计划后,Impala使用拉式获取数据的方式获取结果,把结果数据组成按执行树流式传递汇集,减少的了把中间结果写入磁盘的步骤,再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销,即相比Hive没了MapReduce启动时间。

  • Impala使用的优化技术
    • 使用LLVM产生运行代码,针对特定查询生成特定代码,同时使用Inline的方式减少函数调用的开销,加快执行效率。(C++特性)
    • 充分利用可用的硬件指令(SSE4.2)。
    • 更好的IO调度,Impala知道数据块所在的磁盘位置能够更好的利用多磁盘的优势,同时Impala支持直接数据块读取和本地代码计算checksum。
    • 通过选择合适数据存储格式可以得到最好性能(Impala支持多种存储格式)。
    • 最大使用内存,中间结果不写磁盘,及时通过网络以stream的方式传递。
  • 执行计划
    • Hive: 依赖于MapReduce执行框架,执行计划分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会 被编译成多轮MapReduce,则会有更多的写中间结果。由于MapReduce执行框架本身的特点,过多的中间过程会增加整个Query的执行时间。
    • Impala: 把执行计划表现为一棵完整的执行计划树,可以更自然地分发执行计划到各个Impalad执行查询,而不用像Hive那样把它组合成管道型的 map->reduce模式,以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。
  • 数据流
    • Hive: 采用推的方式,每一个计算节点计算完成后将数据主动推给后续节点。
    • Impala: 采用拉的方式,后续节点通过getNext主动向前面节点要数据,以此方式数据可以流式的返回给客户端,且只要有1条数据被处理完,就可以立即展现出来,而不用等到全部处理完成,更符合SQL交互式查询使用
  • 内存使用
    • Hive: 在执行过程中如果内存放不下所有数据,则会使用外存,以保证Query能顺序执行完。每一轮MapReduce结束,中间结果也会写入HDFS中,同样由于MapReduce执行架构的特性,shuffle过程也会有写本地磁盘的操作。
    • Impala: 在遇到内存放不下数据时,版本1.0.1是直接返回错误,而不会利用外存,以后版本应该会进行改进。这使得Impala目前处理Query会受到一定的限制,最好还是与Hive配合使用
  • 调度
    • Hive: 任务调度依赖于Hadoop的调度策略。
    • Impala: 调度由自己完成,目前只有一种调度器simple-schedule,它会尽量满足数据的局部性,扫描数据的进程尽量靠近数据本身所在的物理机器。调度器 目前还比较简单,在SimpleScheduler::GetBackend中可以看到,现在还没有考虑负载,网络IO状况等因素进行调度。但目前 Impala已经有对执行过程的性能统计分析,应该以后版本会利用这些统计信息进行调度吧。
  • 容错
    • Hive: 依赖于Hadoop的容错能力。
    • Impala: 在查询过程中,没有容错逻辑,如果在执行过程中发生故障,则直接返回错误(这与Impala的设计有关,因为Impala定位于实时查询,一次查询失败, 再查一次就好了,再查一次的成本很低)。
  • 适用面
    • Hive: 复杂的批处理查询任务,数据转换任务。
    • Impala:实时数据分析,因为不支持UDF,能处理的问题域有一定的限制,与Hive配合使用,对Hive的结果数据集进行实时分析

四、​​​​​​​​​​​​​​Impala的优缺点

1、​​​​​​​​​​​​​​优点

  • 基于内存运算,不需要把中间结果写入磁盘,省掉了大量的I/O开销。
  • 无需转换为Mapreduce,直接访问存储在HDFS,HBase中的数据进行作业调度,速度快。
  • 使用了支持Data locality(数据本地化)的I/O调度机制,尽可能地将数据和计算分配在同一台机器上进行,减少了网络开销。
  • 支持各种文件格式,如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet。
  • 可以访问hive的metastore,对hive数据直接做数据分析。

2、​​​​​​​​​​​​​​缺点

  • 对内存的依赖大,且完全依赖于hive。
  • 实践中,分区超过1万,性能严重下降。
  • 只能读取文本文件,而不能直接读取自定义二进制文件。
  • 每当新的记录/文件被添加到HDFS中的数据目录时,该表需要被刷新。

五、Impala支持的文件格式

Impala可以对Hadoop中大多数格式的文件进行查询。它能通过create table和insert的方式将一部分格式的数据加载到table中,但值得注意的是,有一些格式的数据它是无法写入的(write to)。对于Impala无法写入的数据格式,我们只能通过Hive建表,通过Hive进行数据的写入,然后使用Impala来对这些保存好的数据执行查询操作。

文件类型

文件格式

压缩编码

能否Create?

能否Insert?

Parquet

结构化

Snappy、GZIP

Text

非结构化

LZO

能。 如果建表时没有指定存储类型,默认采用未压缩的text,字段由ASCII编码的0x01字符串分割

能 如果使用了LZO压缩,则只能通过Hive建表和插入数据。

Avro

结构化

Snappy GZIP Deflate BZIP2

在Impala 1.4.0 或者更高的版本上支持,之前的版本只能通过Hive来建表。

不能 只能通过LOAD DATA的方式将已经转换好格式的数据加载进去,或者使用Hive来插入数据

RCFile

结构化

Snappy GZIP Deflate BZIP2

不能 只能通过LOAD DATA的方式将已经转换好格式的数据加载进去,或者使用Hive来插入数据

SequenceFile

结构化

Snappy GZIP Deflate BZIP2

不能 只能通过LOAD DATA的方式将已经转换好格式的数据加载进去,或者使用Hive来插入数据

Impala支持以下压缩编码:

  • Snappy – 推荐的编码,因为它在压缩率和解压速度之间有很好的平衡性,Snappy压缩速度很快,但是不如GZIP那样能节约更多的存储空间。Impala不支持Snappy压缩的text file
  • GZIP – 压缩比很高能节约很多存储空间,Impala不支持GZIP压缩的text file
  • Deflate – Impala不支持GZIP压缩的text file
  • BZIP2 - Impala不支持BZIP2压缩的text file
  • LZO – 只用于text file,Impala可以查询LZO压缩的text格式数据表,但是不支持insert数据,只能通过Hive来完成数据的insert

六、Impala的架构

Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具(实时SQL查询引擎Impala),通过使用与商用并行关系数据库中类似的分布式查询引擎(由Query Planner、Query Coordinator和Query ExecEngine三部分组成),可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据,从而大大降低了延迟。

Impala主要由Impalad、 State Store、Catalogd和CLI组成。

  • Impalad
    • ⻆⾊名称为Impala Daemon,是在每个节点上运⾏的进程,是Impala的核⼼组件,进程名是Impalad;
    • 负责读写数据⽂件,接收来⾃Impala-shell,JDBC,ODBC等的查询请求,与集群其它Impalad分布式并⾏完成查询任务,并将查询结果返回给中⼼协调者。
    • 为了保证Impalad进程了解其它Impalad的健康状况,Impalad进程会⼀直与statestore保持通信。
    • Impalad服务由三个模块组成:Query Planner、Query Coordinator和Query Executor,前两个模块组成前端,负责接收SQL查询请求,解析SQL并转换成执⾏计划,交由后端执⾏。
  • Impala State Store
    • statestore监控集群中Impalad的健康状况,并将集群健康信息同步给Impalad。
    • statestore进程名为statestored。
  • catalogd
    • Impala执⾏的SQL语句引发元数据发⽣变化时,catalog服务负责把这些元数据的变化同步给其它Impalad进程(⽇志验证,监控statestore进程⽇志)
    • catalogd会在Impala集群启动的时候加载hive元数据信息到Impala,其他时候不会主动加载,需要使用invalidate metadata,refresh命令。
    • catalog服务对应进程名称是catalogd
    • 由于⼀个集群需要⼀个catalogd以及⼀个statestored进程,⽽且catalogd进程所有请求都是经过statestored进程发送,所以官⽅建议让statestored进程与catalogd进程安排同个节点。
  • CLI
    • 提供给用户查询使用的命令行工具(Impala Shell使用python实现),同时Impala还提供了Hue,JDBC, ODBC使用接口

七、Impapla如何执行查询

Impala执行的查询有以下几个步骤:

操作步骤

说明

1

客户端通过ODBC、JDBC、或者Impala shell向Impala集群中的任意节点发送SQL语句,这个节点的impalad实例作为这个查询的协调器(coordinator)

​编辑

2

Impala解析和分析这个查询语句来决定集群中的哪个impalad实例来执行某个任务,HDFS和HBase给本地的impalad实例提供数据访问

​编辑

3

各个impalad向协调器impalad返回数据,然后由协调器impalad向client发送结果集

​编辑

八、​​​​​​​​​​​​​​浏览器页面访问

访问impalad的管理界面http://node3:25000/

访问statestored的管理界面http://node3:25010/​​​​​​​

标签:Impala,七十,Impalad,Hive,查询,hive,客快,数据
From: https://www.cnblogs.com/shan13936/p/18104327

相关文章