设为首页 - 加入收藏 PHP编程网 - PHP站长网 (http://www.52php.cn)- 电商,百科,编程,业界,移动互联,5G,云计算,站长网!
热搜: 娱乐 专业 服务 百度
当前位置: 首页 > 大数据 > 正文

大数据分析查询引擎Impala(2)

发布时间:2021-05-14 05:07 所属栏目:[大数据] 来源:网络整理
导读:impala支持两种分布式join方式, 表广播和哈希重分布:表广播方式保持一个表的数据不动, 将另一个表广播到所有相关节点(图中t3); 哈希重分布的原理是根据join字段哈希值重新分布两张表数据(譬如图中t1和t2)。

impala支持两种分布式join方式, 表广播和哈希重分布:表广播方式保持一个表的数据不动, 将另一个表广播到所有相关节点(图中t3); 哈希重分布的原理是根据join字段哈希值重新分布两张表数据(譬如图中t1和t2)。分布式计划中的聚集函数分拆为两个阶段执行。第一步针对本地数据进行分组聚合(Pre-AGG)以降低数据量, 并进行数据重分步, 第二步, 进一步汇总之前的聚集结果(mergeAgg)计算出最终结果。 与聚集函数类似, topN也是分为两个阶段执行, (1)本地排序取topN,以降低数据量; (2) merge sort得到最终topN结果。


Backend从frontend接收plan segment并执行, 执行性能非常关键,impala采取的查询性能优化措施有


  • 向量执行。 一次getNext处理一批记录, 多个操作符可以做pipeline。

  • LLVM编译执行, CPU密集型查询效率提升5倍以上。

  • IO本地化。 利用HDFS short-circuit local read功能,实现本地文件读取

  • Parquet列存,相比其他格式性能最高提升5倍。


资源管理


impala通常与MR等离线任务运行在一个集群上, 通过YARN统一管理资源, 如何同时满足交互式查询和离线查询两种需求具有较大挑战性。 YARN通过全局唯一的Resource Mananger调度资源, 好处是RM拥有整个集群全局信息,能做出更好调度决策, 缺点是资源分配的性能不足。 Impala每个查询都需要分配资源, 当每秒查询数上千时, YARN资源分配的响应时间变的很长, 影响到查询性能。 目前通过两个措施解决这个问题:(1)引入快速、非集中式的查询准入机制, 控制查询并发度。(2)LLAM(low latency application master)通过缓存资源, 批量分配,增量分配等方式实现降低资源分配延时

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


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

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

  • 充分利用可用的硬件指令(2)。

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

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

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


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: 在遇到内存放不下数据时,当前版本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的优缺点


优点:


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

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

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

  • 可以与Hive配合使用。


缺点:


  • 不支持用户定义函数UDF。

  • 不支持text域的全文搜索。

  • 不支持Transforms。

  • 不支持查询期的容错。

  • 对内存要求高。


在Cloudera的测试中,Impala的查询效率比Hive有数量级的提升。从技术角度上来看,Impala之所以能有好的性能,主要有以下几方面的原因。


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

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

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

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

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

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


虽然Impala是参照Dremel来实现的,但它也有一些自己的特色,例如Impala不仅支持Parquet格式,同时也可以直接处理文本、SequenceFile等Hadoop中常用的文件格式。另外一个更关键的地方在于,Impala是开源的,再加上Cloudera在Hadoop领域的领导地位,其生态圈有很大可能会在将来快速成长。

可以预见,在不久的未来,Impala很可能像之前的Hadoop和Hive一样在大数 据处理领域大展拳脚。Cloudera自己也说期待未来Impala能完全取代Hive。当然,用户从Hive上迁移到Impala上来是需要时间的。需要说明的是,Impala并不是用来取代已有的MapReduce系统,而是作为MapReduce的一个强力补充。总的来说,Impala适合用来处理输出数据适中或比较小的查询,而对于大数据量的批处理任务,MapReduce依然是更好的选择。另外一个消息是,Cloudera里负责Impala的架构师Marcel Komacker就曾在Google负责过F1系统的查询引擎开发,可见Google确实为大数据的流行出钱出力。


Impala与Shark,Drill等的比较


【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

推荐文章
热点阅读