最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

impala的原理架构介绍及应用场景

[复制链接]
发表于 2019-3-11 20:29:06 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本帖最后由 168主编 于 2019-7-3 13:07 编辑

impala概述
  由cloudera公司主导开发的大数据实时查询分析工具,宣称比原来基于MapReduce的HiveSQL查询速度提升3~90倍,且更加灵活易用。提供类SQL的查询语句,能够查询存储在hadoop的HDFS和Hbase中的PB级大数据。查询速度快是其最大的卖点。简言之impala作为大数据实时查询分析工具,具有查询速度快,灵活性高,易整合,可伸缩性强等特点。

1.查询速度快。Impala不同于hive,hive底层执行使用的是MapReduce引擎,仍然是一个批处理过程。不同于hive,impala中间结果不写入磁盘,即使及时通过网络以流的形式传递,大大降低的节点的IO开销。

2.灵活性高。可以直接查询存储在HDFS上的原生数据,也可以查询经过优化设计而存储的数据,只需要数据的格式能够兼容MapReduce、hive、Pig等等。

3.易整合。很容易和hadoop系统整合,并使用hadoop生态系统的资源和优势,不需要将数据迁移到特定的存储系统就能满足查询分析的要求。

4.可伸缩性。可以很好的与一些BI应用系统协同工作,如Microstrategy、Tableau、Qlikview等。

架构介绍
impala架构图:
1.从上图可以看出,位于Datanode上的每个impalad进程,都具有Query Planner,QueryCoordinator,Query ExecEnginer这几个组件,每个impala节点在功能上是对等的,也就是说,任何一个节点都能接受外部查询请求。当有一个节点发生故障后,其他节点仍然能够接管,这还得益于HDFS的数据冗余备份机制,即使某个impalad节点挂掉,只要挂掉的节点上的数据在其他节点上有备份,仍然是可以计算的。

2.Impala由impalad,statestore,CLI组成。下面分别概述各自的功能:

impalad是impala的核心进程,与Datanode在同一个节点上,接受客户端的查询请求(接受查询请求的impalad为Coordinator,Coordinator通过JNI调用java前端解释SQL查询语句,生成查询计划树,再通过调度器吧执行计划分发给具有相应数据的其他impalad执行),读写数据,并行执行查询,并把结果通过网络流式传给Coordinator,有Coordinator返回给客户端。同时impalad也与statestore保持连接,用于确定哪些impalad的健康的是可以执行新任务的。

state store跟踪集群中的impalad的健康状态及位置信息,并不断把健康状况发送给所有的impalad进程节点。一旦某个impala节点不可用,statestore确保将这一信息及时传达到所有的impalad进程节点,当有新的查询请求时,impalad进程节点不会把查询请求发送到不可用的节点上。statestore通过创建多个线程来处理impalad的注册订阅和与各个impalad保持心态连接。值得注意的是,statestore并非关键进程,即使不可用,impalad进程节点间仍然可以相互协调正常对外提供分布式查询。

CLI:用户查询的命令行共组,还提供了Hue、JDBC、ODBC等接口。

与hive的比价:
Impala与Hive的异同:

数据存储:使用相同的存储数据池都支持把数据存储于HDFS, HBase。

元数据:两者使用相同的元数据。

SQL解释处理:比较相似都是通过词法分析生成执行计划。

执行计划:

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配合使用。Impala在多个阶段之间利用网络传输数据,在执行过程不会有写磁盘的操作(insert除外)。

调度:

Hive:任务调度依赖于Hadoop的调度策略。

Impala:调度由自己完成,目前只有一种调度器simple-schedule,它会尽量满足数据的局部性,扫描数据的进程尽量靠近数据本身所在的物理机器。调度器目前还比较简单,在SimpleScheduler::GetBackend中可以看到,现在还没有考虑负载,网络IO状况等因素进行调度。但目前Impala已经有对执行过程的性能统计分析,应该以后版本会利用这些统计信息进行调度吧。

容错:

Hive:依赖于Hadoop的容错能力。

Impala:在查询过程中,没有容错逻辑,如果在执行过程中发生故障,则直接返回错误(这与Impala的设计有关,因为Impala定位于实时查询,一次查询失败,再查一次就好了,再查一次的成本很低)。但从整体来看,Impala是能很好的容错,所有的Impalad是对等的结构,用户可以向任何一个 Impalad提交查询,如果一个Impalad失效,其上正在运行的所有Query都将失败,但用户可以重新提交查询由其它Impalad代替执行,不会影响服务。对于State Store目前只有一个,但当State Store失效,也不会影响服务,每个Impalad都缓存了State Store的信息,只是不能再更新集群状态,有可能会把执行任务分配给已经失效的Impalad执行,导致本次Query失败。

适用面:

Hive:复杂的批处理查询任务,数据转换任务。

Impala:实时数据分析,因为不支持UDF,能处理的问题域有一定的限制,与Hive配合使用,对Hive的结果数据集进行实时分析。

Impala相对于Hive所使用的优化技术:

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

2、使用LLVM产生运行代码,针对特定查询生成特定代码,同时使用Inline的方式减少函数调用的开销,加快执行效率。

3、充分利用可用的硬件指令(SSE4.2)。

4、更好的IO调度,Impala知道数据块所在的磁盘位置能够更好的利用多磁盘的优势,同时Impala支持直接数据块读取和本地代码计算checksum。

5、通过选择合适的数据存储格式可以得到最好的性能(Impala支持多种存储格式)。

6、最大使用内存,中间结果不写磁盘,及时通过网络以stream的方式传递。

impala查询处理过程
Impalad分为Java前端与C++处理后端,接受客户端连接的Impalad即作为这次查询的Coordinator,Coordinator通过JNI调用Java前端对用户的查询SQL进行分析生成执行计划树,不同的操作对应不用的PlanNode,如:SelectNode, ScanNode, SortNode, AggregationNode, HashJoinNode等等。

执行计划树的每个原子操作由一个PlanFragment表示,通常一条查询语句由多个Plan Fragment组成, PlanFragment 0表示执行树的根,汇聚结果返回给用户,执行树的叶子结点一般是Scan操作,分布式并行执行。

Java前端产生的执行计划树以Thrift数据格式返回给ImpalaC++后端(Coordinator)(执行计划分为多个阶段,每一个阶段叫做一个PlanFragment,每一个PlanFragment在执行时可 以由多个Impalad实例并行执行(有些PlanFragment只能由一个Impalad实例执行,如聚合操作),整个执行计划为一执行计划树),由 Coordinator根据执行计划,数据存储信息(Impala通过libhdfs与HDFS进行交互。通过hdfsGetHosts方法获得文件数据 块所在节点的位置信息),通过调度器(现在只有simple-scheduler, 使用round-robin算法)Coordinator::Exec对生成的执行计划树分配给相应的后端执行器Impalad执行(查询会使用LLVM 进行代码生成,编译,执行。

应用场景

Impala的优缺点:
优点:

1.支持SQL查询,快速查询大数据。

2.可以对已有数据进行查询,减少数据的加载,转换。

3.多种存储格式可以选择(Parquet,Text, Avro, RCFile, SequeenceFile)。

4.可以与Hive配合使用。

缺点:

1.不支持用户定义函数UDF。

2.不支持text域的全文搜索。

3.不支持Transforms。

4.不支持查询期的容错。

5.对内存要求高。

在实时性要求不高的应用场景中,比如,月度、季度、年度报表的生成。可以使用基于传统的HadoopMapreduce处理海量大数据。但是在一些实时性要求很高的场景

中,一方面满足实时性要求,一方面提升用户体验。Impala因其快速的响应能力当之无愧作为首选查询分析工具。
---------------------
作者:anickname
来源:CSDN
楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 20:37

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表