<人力资源/>
基本概述
1,火花1.0版本以后,火花官方推出了火花SQL。其实最早使用的,都是Hadoop自己的蜂巢查询引擎,比如MR2,我们底层都是运行的MR2模型,底层都是基于蜂巢的查询引擎。
2,后来火花提供了鲨鱼,再后来鲨鱼被淘汰(鲨鱼制约了火花SQL的整体发展),推出了火花SQL.Shark的性能比蜂房就要高出一个数量级,而火花SQL的性能又比鲨鱼高出一个数量级。
3, SparkSQL的前身是鲨鱼,给熟悉RDBMS但又不理解MapReduce的技术人员提供快速上手的工具,蜂巢应运而生,它是当时唯一运行在Hadoop上的SQL-on-Hadoop工具。但是MapReduce计算过程中大量的中间磁盘落地过程消耗了大量的I/O,降低的运行效率,为了提高SQL-on-Hadoop的效率,大量的SQL-on-Hadoop工具开始产生,其中表现较为突出的是:
<代码> MapR的演习 Cloudera的黑斑羚 鲨鱼
4,但是蜂巢有个致命的缺陷,就是它的底层基于MR2,而MR2的洗牌又是基于磁盘的,因此导致蜂巢的性能异常低下。经常出现复杂的SQL ETL,要运行数个小时,甚至数十个小时的情况。
5,火花推出了鲨鱼,鲨鱼与蜂巢实际上还是紧密关联的,鲨鱼底层很多东西还是依赖于蜂巢,但是修改了内存管理,物理计划,执行三个模块,底层使用火花的基于内存的计算模型,从而让性能比蜂房提升了数倍到上百倍。
火花SQL特点
1,但是,随着火花的发展,对于野心勃勃的火花团队来说,鲨鱼对于蜂巢的太多依赖(如采用蜂巢的语法解析器,查询优化器等等),制约了火花的一个栈统治他们的既定方针,制约了火花各个组件的相互集成,所以提出了SparkSQL项目.SparkSQL抛弃原有鲨鱼的代码,汲取了鲨鱼的一些优点,如内存列存储(内存中的柱状存储),蜂巢兼容性等,重新开发了SparkSQL代码,由于摆脱了对蜂巢的依赖性,SparkSQL无论在数据兼容,性能优化,组件扩展方面都得到了极大的方便,真可谓“退一步,海阔天空”。
2,火花SQL的特点
1),支持多种数据源:蜂巢,抽样,拼花,JSON, JDBC等。
2),多种性能优化技术:内存中的柱状存储字节码生成成本模型动态评估等。
3),组件扩展性:对于SQL的语法解析器,分析器以及优化器,用户都可以自己重新开发,并且动态扩展。
<强>数据兼容方面强不但兼容蜂巢,还可以从抽样,拼花文件,JSON文件中获取数据,未来版本甚至支持获取RDBMS数据以及卡桑德拉等NOSQL数据;
<>强性能优化方面除了采取内存中柱状存储字节码生成等优化技术外,将会引进成本模型对查询进行动态评估,获取最佳物理计划等等;
<强>组件扩展方面无论是SQL的语法解析器,分析器还是优化器都可以重新定义,进行扩展。
2014年6月1日鲨鱼项目和SparkSQL项目的主持人雷诺鑫宣布:停止对鲨鱼的开发,团队将所有资源放SparkSQL项目上,至此,鲨鱼的发展画上了句话,但也因此发展出两个直线:SparkSQL和蜂巢alt="火花SQL笔记整理(一):火花SQL整体背景介绍">
其中SparkSQL作为火花生态的一员继续发展,而不再受限于蜂巢,只是兼容蜂巢;而蜂巢alt="火花SQL笔记整理(一):火花SQL整体背景介绍">
那么,摆脱了蜂巢的限制,SparkSQL的性能又有怎么样的表现呢?虽然没有鲨鱼相对于蜂巢那样瞩目地性能提升,但也表现得非常优异:
火花SQL性能优化技术简介
SparkSQL的表数据在内存中存储不是采用原生态的JVM对象存储方式,而是采用内存列存储,如下图所示:
内存列存储(内存中的柱状存储)
1,该存储方式无论在空间占用量和读取吞吐率上都占有很大优势。
对于原生态的JVM对象存储方式,每个对象通常要增加12到16字节的额外开销,对于一个270 mb的数据,使用这种方式读入内存,要使用970 mb左右的内存空间(通常是2 ~ 5倍于原生数据空间);另外,使用这种方式,每个数据记录产生一个JVM对象,如果是大小为200 b的数据记录,32 g的堆栈将产生1.6亿个对象,这么多的对象,对于GC来说,可能要消耗几分钟的时间来处理(JVM的垃圾收集时间与堆栈中的对象数量呈线性相关)。显然这种内存存储方式对于基于内存计算的火花来说,很昂贵也负担不起。
