从不同的角度来认识和理解Impala的架构设计

我们知道,在实时性要求不是很高的应用场景中,比如,月度统计报表生成等,我们基于传统的Hadoop MapReduce来处理海量大数据(包括使用Hive),在各方面表现都还不错,只需要离线处理数据,然后存储结果即可。但是如果在一些实时性要求相对较高的应用场景中,哪怕处理时间能够在原有的基础有大幅度地减少,也能很好地提升用户体验。对于大数据的实时性要求,其实是相对的,比如,传统使用MapReduce计算框架处理PB级别的查询分析请求,可能耗时30分钟甚至更多,但是如果能够使这个延迟大大降低,如3分钟计算出结果,这是很令人震撼的。Impala就是基于这样的需求驱动而出现的。
Impala是Cloudera开发的一款用来进行大数据实时查询分析的开源工具,它能够实现通过我们熟悉的传统关系数据库的SQL风格来操作大数据,数据可以是存储到HDFS或HBase中的。
下面,我们从不同的角度来认识和理解Cloudera Impala:

设计目标

官网给出的介绍是,使用Impala来实现SQL on Hadoop,实现对海量数据的实时查询分析,它的优势有如下几点:

  • 快速

可以方便地执行SQL语句,在数秒内返回查询分析结果。
这一点,其实还要依赖于你在HDFS或HBase上存储的数据的规模,依赖于你对Impala系统的配置调优情况,可能还依赖于你写的SQL语句的执行效率。

  • 灵活

可以直接查询存储在HDFS上的原生数据,也可以查询经过优化设计而存储的数据,只要数据的格式它们能够兼容MapReduce、Hive、Pig等等。

  • 整合&开放

可以非常容易地与Hadoop系统整合,并使用Hadoop生态系统的资源和优势,也不需要将数据迁移到特定的存储系统就能满足查询分析的要求。

  • 可伸缩性

可以很好地与一些BI应用系统协同工作,如Microstrategy、Tableau、Qlikview,等等。

支持特性

Impala支持的特性,主要包括如下几点:

  • 对 ANSI-92 SQL标准的支持

Impala支持ANSI-92 SQL所有子集,包括CREATE、ALTER、SELECT、INSERT、JOIN、GROUP BY以及子查询。它还支持分区JOIN、常用的聚合函数(SUM、COUNT、MAX、MIN、AVG等等)、topN查询。你使用这些语句时,可以像使用关系数据库中使用的SQL语句一样去设计,很容易上手。

  • 数据来源与数据格式

Impala可以操作HDFS、HBase中存储的数据,支持如下HDFS的支持文件格式:Text file、SequenceFile、RCFile、Avro file、Parquet,支持的压缩格式有:Snappy、GZIP、Deflate、BZIP,其中Snappy压缩格式的性能更好一些。

  • 支持的数据访问接口

主要包括Hive所支持的如下接口:JDBC Driver、ODBC Driver、Hue Beeswax、Cloudera Impala Query UI.,另外,还可以通过CLI接口(也就是Impala Shell)访问。

架构设计要点

Impala的架构设计视图,如图所示:

上面可以看出,位于Datanode上的每个impalad进程,都具有Query Planner、Query Coordinator、Query Exec Engine这几个组件,每个Impala节点在功能集合上是对等的,也就是说,任何一个节点都能接收外部查询请求。当有一个节点发生故障后,其他节点仍然能够接管,这还要得益于,在HDFS上,数据的副本是冗余的,只要数据能够取到,某些挂掉的impalad进程所在节点的数据,在整个HDFS中只要还存在副本(impalad进程正常的节点),还是可以提供计算的。除非,当多个impalad进程挂掉了,恰好此时的查询请求要操作的数据所在的节点,都没有存在impalad进程,这是肯定是无法计算了。
Cloudera Impala在实际应用场景中所处的位置,如图所示:

上图展示了Impala方案的相关的各种组件,简单说明如下:

  • 客户端

有三类客户端可以与Impala进行交互:基于驱动程序的客户端(ODBC Driver和JDBC Driver,其中JDBC Driver支持Hive1与Hive2风格的驱动形式);Hue接口,可以通过Hue Beeswax接口来与Impala进行交互;Impala Shell命令行接口,类似关系数据库提供一些命令行即可,可以直接使用SQL语句与Impala交互。

  • Hive Metastore

Impala使用Hive Metastore来存储一些元数据,为Impala所使用,通过存储的元数据,Impala可以更好地知道整个集群中数据以及节点的状态,从而实现集群并行计算,对外部提供查询分析服务。

  • Cloudera Impala

Impala会在HDFS集群的Datanode上启动进程,协调位于集群上的多个Impala进程(impalad),以及执行查询。在Impala架构中,每个Impala节点都可以接收来自客户端的查询请求,然后负责解析查询,生成查询计划,并进行优化,协调查询请求在其他的多个Impala节点上并行执行,最后有负责接收查询请求的Impala节点来汇总结果,响应客户端。

  • HBase和HDFS

HBase和HDFS存储着实际需要查询的大数据。

总结

Cloudera官网所言,使用Impala比使用Hive能提高3~90的效率,我们可以参考Cloudera的官网博客。我相信,使用Impala比使用Hive能大大提升计算性能,这是真实的。Impala从发布到现在也不过一年左右时间,它还在发展之中,能有这样的表现我还是感觉很欣慰,至少让我们看到了一些商业系统能够实现的功能已经在开源项目中落地。
在我们使用Impala的过程中,我总结一下遇到的相关问题:

  • SQL解析

我发现Impala目前在SQL解析方面还有优化的余地,当前的问题,一个是SQL解析速度很慢,另一个是如果SQL比较复杂的话存在硬解析的问题,非常耗时。虽然和现在更加成熟的关系数据库Oracle、MySQL等还有一定差距,但是我相信这些只是时间问题。

  • 稳定性

可能是因为依赖于Hive的原因,通过Thrift接口来与后端进行交互,并发性比较差。当并发稍微高一点点的时候,就会出现impalad进程挂掉的问题,有时候可能还会出现类似的僵尸进程。

本文作者:Yanjun

来源:51CTO

时间: 2024-12-11 05:56:45

从不同的角度来认识和理解Impala的架构设计的相关文章

我理解的 Flux 架构

之前 review 业务代码的时候就一直想说写一篇自己对 Flux 的理解和看法,不知不觉也过去蛮久了,于是这周末打起精神写了这么一篇. 这篇文章将谈一些我对 Flux 的理解和个人看法.如果您还不太了解什么是 Flux,请先移步这里. 另外文中没有特别大段的代码,以讨论架构设计和背后的道理为主,可能会显得有点枯燥,大家可以选个不太困的时候耐心读读看:) Flux 中的几个基本概念 这是 Flux 官方提供的一张说明图: 图中有四个名词: View Store Action Dispatcher

《Scala机器学习》一一3.2 理解Spark的架构

3.2 理解Spark的架构 并行化是将工作负载划分为在不同线程或不同节点上执行的子任务.下面介绍Spark实现并行化的原理,以及它如何管理子任务的执行和子任务之间的通信.3.2.1 任务调度Spark工作负载的划分由弹性分布式数据集(Resilient Distributed Dataset,RDD)的分区数决定,这是Spark的基本抽象和管道结构.RDD是一种可并行操作的.不可变元素的分区集合.具体细节可能取决于Spark的运行模式,图3-2为Spark任务/资源调度的示意图. 图3-2 通

五大角度 高度总结 全面理解云计算

随着http://www.aliyun.com/zixun/aggregation/9356.html">信息时代的飞速发展,现在在很多领域都涉及到云计算.云存储.云服务等等,这一切的一切都离不开一个字"云",不过又能有多少人实实在在的清楚或说出云计算是什么呢?大多数的人都还是在云里雾里的.所以今天在这里给大家简单介绍下云计算,可以用高度概括的五种不同角度,全面的诠释什么是云计算. 第一,一切皆服务,简单的来说,云计算其实就是一种服务,它是一种服务的形式来提供的. 第二

我理解的“前端架构”(来自2014年)

写在前面的话: 怀着一个酝酿了蛮长时间的念头,打开电脑,想对一些思考做一点记录.关于标题,关于"前端",关于"架构" . 其实是有蛮多话想说的,但是前面这几个字却打上去了又删掉.想为下面的内容找一个合适的开始.但是似乎总是不那么如意. 回到这个话题,或许应该从以前的认知慢慢说起. 过往的认知 不可否认的说,曾经很长的一段时间,当我大部分时间还集中在业务上的时候,对"架构"这个词有点嗤之以鼻.尤其是"前端架构".觉得说"

如何理解移动信息架构?

  恶补交互基础知识的好机会!这个国外系列的交互教程非常实用,适合包括设计师.开发.产品等学习,今天的第一部分归纳总结并比较了多种主流的设计模式和信息架构,全文图示丰富,直观易懂,译者还很用心地将图片转成中文版,看起来不费力,强烈推荐呦! Lost:大约在1993年,我父亲带回家一部体型硕大.形似砖头的移动电话.当时,我们全家人都对这个稀物表示难以置信的兴奋,但是没有人会认为它会对我们的生活产生巨大影响.几年后,当我的一些朋友决定购买它时,我仍然会把它看作是一种花样和噱头. 如今全世界共有60亿

vue2.0源码分析之理解响应式架构

分享前啰嗦 我之前介绍过vue1.0如何实现observer和watcher.本想继续写下去,可是vue2.0横空出世..所以 直接看vue2.0吧.这篇文章在公司分享过,终于写出来了.我们采用用最精简的代码,还原vue2.0响应式架构实现 以前写的那篇 vue 源码分析之如何实现 observer 和 watcher可以作为本次分享的参考. 不过不看也没关系,但是最好了解下Object.defineProperty 本文分享什么 理解vue2.0的响应式架构,就是下面这张图 顺带介绍他比rea

架构设计中服务层的简单理解

   在ddd设计中我们经常会提到服务层,服务层是什么?职责是什么?有什么好处?.    先看简单的层次图(注:这里并没有考虑其他多余的领域逻辑数据层存储,或者UOW这些细节)    我的理解是服务层是处于我的应用程序业务层和表现层之间的应用程序边界,边界可能是很薄的一层类设计或者是分布式服务网络跃点.它是一个与技术无关的名词.由表现层直接调用,契约,执行命令(修改状态(CUD))或者是查询返回dto(数据迁移对象)(cms,命令-查询分离).他对业务逻辑层接口很清楚,组织业务逻辑 微服务形成宏

我理解的主题网站设计

一个简单的主题网站,可谓"麻雀虽小,五脏俱全",虽只涉及首页.索引页和内容页这种所谓"三个页面"设计思想,但却集合了简单 Web 设计之精髓. 首页涉及美工设计.用户交互以及内容布局等,主要版块则有导航区域.推荐内容.最新内容.热点内容.日期索引.来源索引.标签索引等,除此还有友情链接.广告区域和版权信息等,其中像导航区域.版本信息等整站风格保持一致. 索引页在美工设计和样式上和首页风格一致,布局则比较清晰,除了导航区域和版权信息区域外,还将保留诸如标签索引.热门图

Cloudera Impala架构设计要点

我们知道,在实时性要求不是很高的应用场景中,比如,月度统计报表生成等,我们基于传统的Hadoop MapReduce来处理海量大数据(包括使用Hive),在各方面表现都还不错,只需要离线处理数据,然后存储结果即可.但是如果在一些实时性要求相对较高的应用场景中,哪怕处理时间能够在原有的基础有大幅度地减少,也能很好地提升用户体验.对于大数据的实时性要求,其实是相对的,比如,传统使用MapReduce计算框架处理PB级别的查询分析请求,可能耗时30分钟甚至更多,但是如果能够使这个延迟大大降低,如3分钟