我是靠谱客的博主 笨笨芝麻,最近开发中收集的这篇文章主要介绍Apache Impala架构解析及与Hive、SparkSQL的性能比较,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

一、Impala介绍

Impala是Cloudera公司主导开发的新型查询系统,它提供SQL语义,能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义,但由于Hive底层执行使用的是MapReduce引擎,仍然是一个批处理过程,难以满足查询的交互性。相比之下,Impala的最大特点也是最大特点就是它的快速。

Impala是用于处理存储在Hadoop集群中的大量数据的MPP(大规模并行处理)SQL查询引擎。 它是一个用C ++和Java编写的开源软件。 与其他Hadoop的SQL引擎相比,它提供了高性能和低延迟。换句话说,Impala是性能最高的SQL引擎(提供类似RDBMS的体验),它提供了访问存储在Hadoop分布式文件系统中的数据的最快方法。

二、Impala架构解析

从上图(引用自Apache Impala官网)中看出,可以首先大体上描述下一个SQL从提交到获取查询结果是经历了哪些步骤(下面的步骤和上图中步骤不一一对应):

1、客户端提交任务:客户端通过beeswax或者HiveServer2接口发送一个SQL查询请求到Impalad节点,查询包括一条SQL和相关的configuration信息(只对本次查询生效),查询接口提供同步和异步的方式执行,两种接口都会返回一个queryId用于之后的客户端操作。

2、查询解析和分析: SQL提交到Impalad节点之后交由FE模块处理,由Analyser依次执行SQL的词法分析、语法分析、语义分析、查询重写等操作,生成该SQL的Statement信息。

3、单机执行计划生成:根据上一步生成的Statement信息,由Planner生成单机的执行计划,该执行计划是有PlanNode组成的一棵树,这个过程中也会执行一些SQL优化,例如Join顺序改变、谓词下推等。

4、分布式执行计划生成:由Planner将单机执行计划转换成分布式并行物理执行计划,物理执行计划由一个个的Fragment组成,Fragment之间有数据依赖关系,处理过程中需要在原有的执行计划之上加入一些ExchangeNode和DataStreamSink信息等。

5、任务调度和分发:由BE处理生成的分布式物理执行计划,将Fragment根据数据分区信息发配到不同的Impalad节点上执行。Impalad节点接收到执行Fragment请求交由Backend模块处理Fragment的执行。

6、子任务执行:每一个Fragment的执行输出通过DataStreamSink发送到下一个Fragment,由下一个Fragment的ExchangeNode接收,Fragment运行过程中不断向coordinator节点汇报当前运行状态。

7、结果汇总:查询的SQL通常情况下需要有一个单独的Fragment用于结果的汇总,它只在coordinator节点运行,将多个backend的最终执行结果汇总,转换成ResultSet信息。

8、客户端查询结果:客户端调用获取ResultSet的接口,读取查询结果。

9、关闭查询:客户端调用CloseOperation关闭本次查询,标志着本次查询的结束。

三、Impala组件

1. Impala Daemon组件

  Impalad是Impala的核心进程,运行在所有的数据节点上,可以读写数据,并接收客户端的查询请求,并行执行来自集群中其他节点的查询请求,将中间结果返回给调度节点。调用节点将结果返回给客户端。用户在Impala集群上的某个节点提交数据处理请求 则该节点称为coordinator node(协调器节点),其他的集群节点传输其中的处理的部分数据到该coordinator node,coordinator node负责构建最终的结果数据返回给用户。
Impala 支持在提交任务的时候(采用JDBC ,ODBC 方式) 采用round-robin算法来实现负载均衡,将任务提交到不同的节点上
Impalad 进程通过持续的和statestore 通信来确认自己所在的节点是否健康 和是否可以接受新的任务请求

2. Impala Statestore(主要优化点,线程数)

  状态管理进程,定时检查The Impala Daemon的健康状况,协调各个运行Impalad的实例之间的信息关系,Impala正是通过这些信息去定位查询请求所要的数据,进程名叫作 statestored,在集群中只需要启动一个这样的进程,如果Impala节点由于物理原因、网络原因、软件原因或者其他原因而下线,Statestore会通知其他节点,避免查询任务分发到不可用的节点上。

3. Impala Catalog Service(元数据管理和元存储)

  元数据管理服务,进程名叫做catalogd,将数据表变化的信息分发给各个进程。接收来自statestore的所有请求 ,每个Impala节点在本地缓存所有元数据。 当处理极大量的数据和/或许多分区时,获得表特定的元数据可能需要大量的时间。 因此,本地存储的元数据缓存有助于立即提供这样的信息。当表定义或表数据更新时,其他Impala后台进程必须通过检索最新元数据来更新其元数据缓存,然后对相关表发出新查询。

4. 其他组件列表

Impala client:将HiveQL请求送给Impalad,并等待结果返回给用户
Impalad:

Planner > FE(JAVA):负责解析查询请求,并生成执行计划树(Query Plan Tree)。

Coordinator > BE(C++):拆解请求(Fragment),负责定位数据位置,并发送请求到Exec Engine,汇聚请求结果上报。

Exec Engine > BE(C++):执行Fragment子查询,比如scan,Aggregation,Merge etc。
statestore server:维护Impalad的伙伴关系,负责通知伙伴关系变化,类似于仪表盘的zk的故障监控功能。

meta server:

Hive Meta Storage:用户维护表的schema信息等元数据(存在于一个关系型数据库)。

NameNode of HDFS:用于定位hdfs的数据位置。

HMaster of HBase:用于定位HBase的数据的位置。

storage server:

HDFS:HDFS的DataNode服务。

HBASE:HBase的RegionServer服务。

四、Impala的优缺点

1. Impala的优点

1) Impala不需要把中间结果写入磁盘,省掉了大量的I/O开销。

2) 省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢(默认每个心跳间隔是3秒钟),Impala直接通过相应的服务进程来进行作业调度,速度快了很多。

3) Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式,而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶,因此可做更多的查询优化,从而省掉不必要的shuffle、sort等开销。

4) 通过使用LLVM来统一编译运行时代码,避免了为支持通用编译而带来的不必要开销。

5) 用C++实现,做了很多有针对性的硬件优化,例如使用SSE指令。

6) 使用了支持Data locality的I/O调度机制,尽可能地将数据和计算分配在同一台机器上进行,减少了网络开销

2. Impala的缺点

1) Impala不提供任何对序列化和反序列化的支持。

2) Impala只能读取文本文件,而不能读取自定义二进制文件。

3) 每当新的记录/文件被添加到HDFS中的数据目录时,该表需要被刷新

五、Impala的功能

1.Impala可以根据Apache许可证作为开源免费提供。

2.Impala支持内存中数据处理,它访问/分析存储在Hadoop数据节点上的数据,而无需数据移动。

3.Impala为HDFS中的数据提供了更快的访问。

4.可以将数据存储在Impala存储系统中,如Apache HBase和Amazon s3。

5.Impala支持各种文件格式,如LZO,序列文件,Avro,RCFile和Parquet。

6.使用Impala,您可以使用传统的SQL知识以极快的速度处理存储在HDFS中的数据。

7.由于在数据驻留(在Hadoop集群上)时执行数据处理,因此在使用Impala时,不需要对存储在Hadoop上的数据进行数据转换和数据移动。

8.使用Impala,您可以访问存储在HDFS,HBase和Amazon s3中的数据,而无需了解Java(MapReduce作业)。您可以使用SQL查询的基本概念访问它们。

9.为了在业务工具中写入查询,数据必须经历复杂的提取 - 变换负载(ETL)周期。但是,使用Impala,此过程缩短了。加载和重组的耗时阶段通过新技术克服,如探索性数据分析和数据发现,使过程更快。

六、Hive、SparkSQL、Impala性能对比

参照cloudera公司做的性能基准对比测试,所有测试都运行在一个完全相同的21节点集群上,每个节点只配有64G内存。之所以内存不配大,就是为了消除人们对于Impala只有在非常大的内存上才有好性能的错误认识。

配置:

  • 双物理CPU,每个12核,Intel Xeon CPU E5-2630L 0 at 2.00GHz

  • 12个磁盘驱动器,每个磁盘932G,1个用作OS,其它用作HDFS

  • 每节点64G内存

对比产品:

  • Impala

  • Hive-on-Tez

  • Spark SQL

  • Presto

查询:

  1. 21个节点上的数据量为15T

  2. 测试场景取自TPC-DS,一个开放的决策支持基准(包括交互式、报表、分析式查询)

  3. 由于除Impala外,其它引擎都没有基于成本的优化器,本测试使用的查询都使用SQL-92标准的连接

  4. 采用统一的Snappy压缩编码方式,各个引擎使用各自最优的文件格式,Impala和Spark SQL使用Parquet,Hive-on-Tez使用ORC,Presto使用RCFile。

  5. 对每种引擎多次运行和调优

结果:
单用户如下图所示:

多用户如下图所示(引用自Apache Impala官网):

查询吞吐率如下图所示(引用自Apache Impala官网):

Imapal底层采用MPP技术,支持快速交互式SQL查询。与Hive共享元数据存储。Impalad是核心进程,负责接收查询请求并向多个数据节点分发任务。statestored进程负责监控所有Impalad进程,并向集群中的节点报告各个Impalad进程的状态。catalogd进程负责广播通知元数据的最新信息。由测试结果可知,对于单用户查询,Impala比其它方案最多快13倍,平均快6.7倍。对于多用户查询,差距进一步拉大:Impala比其它方案最多快27.4倍,平均快18倍。

最后

以上就是笨笨芝麻为你收集整理的Apache Impala架构解析及与Hive、SparkSQL的性能比较的全部内容,希望文章能够帮你解决Apache Impala架构解析及与Hive、SparkSQL的性能比较所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(49)

评论列表共有 0 条评论

立即
投稿
返回
顶部