SparkSQL简介ITeyefenghuang - 千亿集团

SparkSQL简介ITeyefenghuang

2018-11-23 10:42:08 | 作者: 若芹 | 标签: 运用,数据,句子 | 浏览: 3390

1.1 Hive and Shark

SparkSQL的前身是Shark,给了解RDBMS但又不理解MapReduce的技能人员供给快速上手的东西,Hive应运而生,它是其时仅有运转在Hadoop上的SQL-on-Hadoop东西。可是MapReduce核算进程中许多的中心磁盘落地进程耗费了许多的I/O,下降的运转功率,为了进步SQL-on-Hadoop的功率,许多的SQL-on-Hadoop东西开端发生,其间体现较为杰出的是:

l MapR的Drill

l Cloudera的Impala

l Shark

其间Shark是伯克利试验室Spark生态环境的组件之一,它修改了下图所示的右下角的内存办理、物理方案、履行三个模块,并使之能运转在Spark引擎上,然后使得SQL查询的速度得到10-100倍的进步。

1.2 Shark和SparkSQL 

可是,跟着Spark的开展,关于狼子野心的Spark团队来说,Shark关于Hive的太多依托(如选用Hive的语法解析器、查询优化器等等),约束了Spark的One Stack Rule Them All的既定方针,约束了Spark各个组件的彼此集成,所以提出了SparkSQL项目。SparkSQL扔掉原有Shark的代码,汲取了Shark的一些长处,如内存列存储(In-Memory Columnar Storage)、Hive兼容性等,从头开发了SparkSQL代码;因为摆脱了对Hive的依托性,SparkSQL不管在数据兼容、功用优化、组件扩展方面都得到了极大的便利,真可谓“退一步,放言高论”。

l数据兼容方面  不光兼容Hive,还能够从RDD、parquet文件、JSON文件中获取数据,未来版别乃至支撑获取RDBMS数据以及cassandra等NOSQL数据;

l功用优化方面  除了采纳In-Memory Columnar Storage、byte-code generation等优化技能外、将会引入Cost Model对查询进行动态评价、获取最佳物理方案等等;

l组件扩展方面  不管是SQL的语法解析器、剖析器仍是优化器都能够从头界说,进行扩展。

2014年6月1日Shark项目和SparkSQL项目的主持人Reynold Xin宣告:中止对Shark的开发,团队将一切资源放SparkSQL项目上,至此,Shark的开展画上了句话,但也因而开展出两个直线:SparkSQL和Hive on Spark。

其间SparkSQL作为Spark生态的一员继续开展,而不再受限于Hive,仅仅兼容Hive;而Hive on Spark是一个Hive的开展方案,该方案将Spark作为Hive的底层引擎之一,也就是说,Hive将不再受限于一个引擎,能够选用Map-Reduce、Tez、Spark等引擎。

1.3 SparkSQL的功用

Shark的呈现,使得SQL-on-Hadoop的功用比Hive有了10-100倍的进步:

那么,摆脱了Hive的约束,SparkSQL的功用又有怎样样的体现呢?虽然没有Shark相关于Hive那样瞩目地功用进步,但也体现得十分优异:

为什么SparkSQL的功用会得到怎样大的进步呢?首要SparkSQL在下面几点做了优化:

A:内存列存储(In-Memory Columnar Storage)

SparkSQL的表数据在内存中存储不是选用原生态的JVM目标存储办法,而是选用内存列存储,如下图所示。

该存储办法不管在空间占用量和读取吞吐率上都占有很大优势。

关于原生态的JVM目标存储办法,每个目标一般要添加12-16字节的额定开支,关于一个270MB的TPC-H lineitem table数据,运用这种办法读入内存,要运用970MB左右的内存空间(一般是2~5倍于原生数据空间);别的,运用这种办法,每个数据记载发生一个JVM目标,假如是巨细为200B的数据记载,32G的仓库将发生1.6亿个目标,这么多的目标,关于GC来说,或许要耗费几分钟的时刻来处理(JVM的废物搜集时刻与仓库中的目标数量呈线性相关)。明显这种内存存储办法关于依据内存核算的Spark来说,很贵重也负担不起。

关于内存列存储来说,将一切原生数据类型的列选用原生数组来存储,将Hive支撑的杂乱数据类型(如array、map等)先序化后并接成一个字节数组来存储。这样,每个列创立一个JVM目标,然后导致能够快速的GC和紧凑的数据存储;额定的,还能够运用低价CPU开支的高效紧缩办法(如字典编码、行长度编码等紧缩办法)下降内存开支;更风趣的是,关于剖析查询中频频运用的聚合特定列,功用会得到很大的进步,原因就是这些列的数据放在一同,更简略读入内存进行核算。

B:字节码生成技能(bytecode generation,即CG)

在数据库查询中有一个贵重的操作是查询句子中的表达式,首要是因为JVM的内存模型引起的。比方如下一个查询:

SELECT a + b FROM table

在这个查询里,假如选用通用的SQL语法途径去处理,会先生成一个表达式树(有两个节点的Add树,参阅后边章节),在物理处理这个表达式树的时分,将会如图所示的7个进程:

1.  调用虚函数Add.eval(),需求承认Add两头的数据类型

2.  调用虚函数a.eval(),需求承认a的数据类型

3.  断定a的数据类型是Int,装箱

4.  调用虚函数b.eval(),需求承认b的数据类型

5.  断定b的数据类型是Int,装箱

6.  调用Int类型的Add

7.  回来装箱后的核算成果

其间屡次涉及到虚函数的调用,虚函数的调用会打断CPU的正常流水线处理,减缓履行。

Spark1.1.0在catalyst模块的expressions添加了codegen模块,假如运用动态字节码生成技能(装备spark.sql.codegen参数),SparkSQL在履行物理方案的时分,对匹配的表达式选用特定的代码,动态编译,然后运转。如上比方,匹配到Add办法:

然后,经过调用,终究调用:

终究完结作用相似如下伪代码:

val a: Int = inputRow.getInt(0)

val b: Int = inputRow.getInt(1)

val result: Int = a + b

resultRow.setInt(0, result)

关于Spark1.1.0,对SQL表达式都作了CG优化,详细能够参看codegen模块。CG优化的完结首要仍是依托scala2.10的运转时放射机制(runtime reflection)。关于SQL查询的CG优化,能够简略地用下图来表明:

C:Scala代码优化

别的,SparkSQL在运用Scala编写代码的时分,尽量防止低效的、简略GC的代码;虽然添加了编写代码的难度,但关于用户来说,仍是运用一致的接口,没遭到运用上的困难。下图是一个Scala代码优化的示意图:

2、 SparkSQL运转架构

相似于联系型数据库,SparkSQL也是句子也是由Projection(a1,a2,a3)、Data Source(tableA)、Filter(condition)组成,别离对应sql查询进程中的Result、Data Source、Operation,也就是说SQL句子按Result Data Source Operation的次第来描绘的。

 

当履行SparkSQL句子的次第为:

1.对读入的SQL句子进行解析(Parse),分辨出SQL句子中哪些词是关键词(如SELECT、FROM、WHERE),哪些是表达式、哪些是Projection、哪些是Data Source等,然后判别SQL句子是否标准;

2.将SQL句子和数据库的数据字典(列、表、视图等等)进行绑定(Bind),假如相关的Projection、Data Source等都是存在的话,就表明这个SQL句子是能够履行的;

3.一般的数据库会供给几个履行方案,这些方案一般都有运转统计数据,数据库会在这些方案中挑选一个最优方案(Optimize);

4.方案履行(Execute),按Operation Data Source Result的次第来进行的,在履行进程有时分乃至不需求读取物理表就能够回来成果,比方从头运转刚运转过的SQL句子,或许直接从数据库的缓冲池中获取回来成果。

2.1 Tree和Rule

SparkSQL对SQL句子的处理和联系型数据库对SQL句子的处理选用了相似的办法,首要会将SQL句子进行解析(Parse),然后构成一个Tree,在后续的如绑定、优化等处理进程都是对Tree的操作,而操作的办法是选用Rule,经过形式匹配,对不同类型的节点选用不同的操作。在整个sql句子的处理进程中,Tree和Rule彼此合作,完结了解析、绑定(在SparkSQL中称为Analysis)、优化、物理方案等进程,终究生成能够履行的物理方案。

2.1.1 Tree

l  Tree的相关代码界说在sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/trees

l  Logical Plans、Expressions、Physical Operators都能够运用Tree表明

l  Tree的详细操作是经过TreeNode来完结的

Ø  SparkSQL界说了catalyst.trees的日志,经过这个日志能够形象的表明出树的结构

Ø  TreeNode能够运用scala的调集操作办法(如foreach, map, flatMap, collect等)进行操作

Ø  有了TreeNode,经过Tree中各个TreeNode之间的联系,能够对Tree进行遍历操作,如运用transformDown、transformUp将Rule应用到给定的树段,然后用成果代替旧的树段;也能够运用transformChildrenDown、transformChildrenUp对一个给定的节点进行操作,经过迭代将Rule应用到该节点以及子节点。

l  TreeNode能够细分红三种类型的Node:

Ø  UnaryNode 一元节点,即只要一个子节点。如Limit、Filter操作

Ø  BinaryNode 二元节点,即有左右子节点的二叉节点。如Jion、Union操作

Ø  LeafNode 叶子节点,没有子节点的节点。首要用户指令类操作,如SetCommand

 

2.1.2 Rule

l  Rule的相关代码界说在sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/rules

l  Rule在SparkSQL的Analyzer、Optimizer、SparkPlan等各个组件中都有应用到

l  Rule是一个抽象类,详细的Rule完结是经过RuleExecutor完结

l  Rule经过界说batch和batchs,能够简洁的、模块化地对Tree进行transform操作

l  Rule经过界说Once和FixedPoint,能够对Tree进行一次操作或屡次操作(如对某些Tree进行屡次迭代操作的时分,到达FixedPoint次数迭代或到达前后两次的树结构没改变才中止操作,详细参看RuleExecutor.apply)

2.2 sqlContext和hiveContext的运转进程

SparkSQL有两个分支,sqlContext和hiveContext,sqlContext现在只支撑SQL语法解析器(SQL-92语法);hiveContext现在支撑SQL语法解析器和hivesql语法解析器,默以为hiveSQL语法解析器,用户能够经过装备切换成SQL语法解析器,来运转hiveSQL不支撑的语法,

2.2.1 sqlContext的运转进程

sqlContext总的一个进程如下图所示:

1.SQL句子经过SqlParse解析成UnresolvedLogicalPlan;

2.运用analyzer结合数据数据字典(catalog)进行绑定,生成resolvedLogicalPlan;

3.运用optimizer对resolvedLogicalPlan进行优化,生成optimizedLogicalPlan;

4.运用SparkPlan将LogicalPlan转化成PhysicalPlan;

5.运用prepareForExecution()将PhysicalPlan转化成可履行物理方案;

6.运用execute()履行可履行物理方案;

7.生成SchemaRDD。

在整个运转进程中涉及到多个SparkSQL的组件,如SqlParse、analyzer、optimizer、SparkPlan等等

2.2.2hiveContext的运转进程

hiveContext总的一个进程如下图所示:

1.SQL句子经过HiveQl.parseSql解析成Unresolved LogicalPlan,在这个解析进程中对hiveql句子运用getAst()获取AST树,然后再进行解析;

2.运用analyzer结合数据hive源数据Metastore(新的catalog)进行绑定,生成resolved LogicalPlan;

3.运用optimizer对resolved LogicalPlan进行优化,生成optimized LogicalPlan,优化前运用了ExtractPythonUdfs(catalog.PreInsertionCasts(catalog.CreateTables(analyzed)))进行预处理;

4.运用hivePlanner将LogicalPlan转化成PhysicalPlan;

5.运用prepareForExecution()将PhysicalPlan转化成可履行物理方案;

6.运用execute()履行可履行物理方案;

7.履行后,运用map(_.copy)将成果导入SchemaRDD。

2.3 catalyst优化器

SparkSQL1.1总体上由四个模块组成:core、catalyst、hive、hive-Thriftserver:

l  core处理数据的输入输出,从不同的数据源获取数据(RDD、Parquet、json等),将查询成果输出成schemaRDD;

l  catalyst处理查询句子的整个处理进程,包括解析、绑定、优化、物理方案等,说其是优化器,还不如说是查询引擎;

l  hive对hive数据的处理

l  hive-ThriftServer供给CLI和JDBC/ODBC接口

在这四个模块中,catalyst处于最中心的部分,其功用好坏将影响全体的功用。因为开展时刻尚短,还有许多缺乏的当地,但其插件式的规划,为未来的开展留下了很大的空间。下面是catalyst的一个规划图:

 

其间虚线部分是今后版别要完结的功用,实线部分是现已完结的功用。从上图看,catalyst首要的完结组件有:

lsqlParse,完结sql句子的语法解析功用,现在只供给了一个简略的sql解析器;

lAnalyzer,首要完结绑定作业,将不同来历的Unresolved LogicalPlan和数据元数据(如hive metastore、Schema catalog)进行绑定,生成resolved LogicalPlan;

loptimizer对resolved LogicalPlan进行优化,生成optimized LogicalPlan;

l Planner将LogicalPlan转化成PhysicalPlan;

l CostModel,首要依据曩昔的功用统计数据,挑选最佳的物理履行方案

这些组件的根本完结办法:

l 先将sql句子经过解析生成Tree,然后在不同阶段运用不同的Rule应用到Tree上,经过转化完结各个组件的功用。

l Analyzer运用Analysis Rules,合作数据元数据(如hive metastore、Schema catalog),完善Unresolved LogicalPlan的特点而转化成resolved LogicalPlan;

l optimizer运用Optimization Rules,对resolved LogicalPlan进行兼并、列裁剪、过滤器下推等优化作业而转化成optimized LogicalPlan;

l Planner运用Planning Strategies,对optimized LogicalPlan

3、SparkSQL CLI

CLI(Command-Line Interface,指令行界面)是指可在用户提示符下键入可履行指令的界面,它一般不支撑鼠标,用户经过键盘输入指令,核算机接收到指令后予以履行。Spark CLI指的是运用指令界面直接输入SQL指令,然后发送到Spark集群进行履行,在界面中显现运转进程和终究的成果。

Spark1.1相较于Spark1.0最大的不同就在于Spark1.1添加了Spark SQL CLI和ThriftServer,使得Hive用户还有用惯了指令行的RDBMS数据库办理员较简略地上手,真实含义进步入了SQL年代。

【注】Spark CLI和Spark Thrift Server试验环境为第二课《Spark编译与布置(下)Spark编译装置》所建立

3.1  运转环境阐明 3.1.1 硬软件环境

l  主机操作系统:Windows 64位,双核4线程,主频2.2G,10G内存

l  虚拟软件:VMware® Workstation 9.0.0 build-812388

l  虚拟机操作系统:CentOS 64位,单核

l  虚拟机运转环境:

Ø  JDK:1.7.0_55 64位

Ø  Hadoop:2.2.0(需求编译为64位)

Ø  Scala:2.11.4

Ø  Spark:1.1.0(需求编译)

Ø  Hive:0.13.1

3.1.2 机器网络环境

集群包括三个节点,节点之间能够免暗码SSH拜访,节点IP地址和主机名散布如下:

版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表千亿集团立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章