Spark-S3-SparkSQL的架构和原理是什么

本篇内容主要讲解“Spark-S3-SparkSQL的架构和原理是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Spark-S3-SparkSQL的架构和原理是什么”吧!

网站建设哪家好,找创新互联!专注于网页设计、网站建设、微信开发、微信平台小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了卫东免费建站欢迎大家使用!

Spark SQL的发展


HDFS -> HIVE
由于Hadoop在企业生产中的大量使用,HDFS上积累了大量数据,为了给熟悉RDBMS但又不理解MapReduce的技术人员提供快速上手的工具,Hive应运而生。Hive的原理是将SQL语句翻译成MapReduce计算。

Spark-S3-SparkSQL的架构和原理是什么

HIVE -> SHARK
MapReduce计算过程中大量的中间磁盘落地过程消耗了大量的I/O,降低了运行效率,为了提供SQL-on-Hadoop的效率,Shark出现了。

Shark是伯克利AMPLab实验室Spark生态环境的组件之一,它修改了Hive中的内存管理、物理计划和执行三个模块,使得SQL语句直接运行在Spark上,从而使得SQL查询的速度得到10-100倍的提升。
Spark-S3-SparkSQL的架构和原理是什么

Spark-S3-SparkSQL的架构和原理是什么

SHARK -> SPARK SQL

2014年6月1日,Shark项目和SparkSQL项目的主持人Reynold Xin宣布:停止对Shark的开发,团队将所有资源放sparkSQL项目上,至此,Shark的发展画上了句号。
Spark-S3-SparkSQL的架构和原理是什么

随着Spark的发展,Shark对于Hive的太多依赖制约了Spark的One Stack rule them all的方针,制约了Spark各个组件的相互集成,同时Shark也无法利用Spark的特性进行深度优化,所以决定放弃Shark,提出了SparkSQL项目。

随着Shark的结束,两个新的项目应运而生:SparkSQL和Hive on Spark。其中SparkSQL作为Spark生态的一员继续发展,而不再受限于Hive,只是兼容Hive;而Hive on Spark是一个Hive的发展计划,该计划将Spark作为Hive的底层引擎之一,也就是说,Hive将不再受限于一个引擎,可以采用Map-Reduce、Tez、Spark等引擎。

SparkSQL优势

SparkSQL摆脱了对Hive的依赖性,无论在数据兼容、性能优化、组件扩展方面都得到了极大的方便。
1、数据兼容方面  
不但兼容Hive,还可以从RDD、parquet文件、JSON文件中获取数据,未来版本甚至支持获取RDBMS数据以及cassandra等NOSQL数据;

2、性能优化方面  
除了采取In-Memory Columnar Storage、byte-code generation等优化技术外、将会引进Cost Model对查询进行动态评估、获取最佳物理计划等等;
    
3、组件扩展方面  
无论是SQL的语法解析器、分析器还是优化器都可以重新定义,进行扩展;

Spark SQL的性能优化

内存列存储(In-Memory Columnar Storage)
对于内存列存储来说,将所有原生数据类型的列采用原生数组来存储,将Hive支持的复杂数据类型(如array、map等)先序列化后并接成一个字节数组来存储。

这样,每个列创建一个JVM对象,从而导致可以快速地GC和紧凑的数据存储。

额外的,还可以用低廉CPU开销的高效压缩方法来降低内存开销。

更有趣的是,对于分析查询中频繁使用的聚合特定列,性能会得到很大的提高,原因就是这些列的数据放在一起,更容易读入内存进行计算。

Spark-S3-SparkSQL的架构和原理是什么

字节码生成技术(bytecode generation,即CG)

在数据库查询中有个昂贵的操作就是查询语句中的表达式,主要是由JVM的内存模型引起的。如SELECT a+b FROM table,这个查询里如果采用通用的SQL语法途径去处理,会先生成一个表达树,会多次设计虚函数的调用,这会打断CPU的正常流水线处理,减缓执行速度。
    
spark -1.1.0在catalyst模块的expressions增加了codegen模块,如果使用动态字节码生成技术,Spark SQL在执行物理计划时,会对匹配的表达式采用特定的代码动态编译,然后运行。

Spark-S3-SparkSQL的架构和原理是什么

Scala代码的优化

Spark SQL在使用Scala语言编写代码时,应尽量避免容易GC的低效代码。尽管增加了编写代码的难度,但对于用户来说,还是使用了统一的接口,让开发在使用上更加容易。
Spark-S3-SparkSQL的架构和原理是什么

Spark SQL的运行架构

SparkSQL有两个分支,sqlContext和hiveContext,sqlContext现在只支持SQL语法解析器;hiveContext现在支持SQL语法解析器和hivesql语法解析器,默认为hiveSQL语法解析器,用户可以通过配置切换成SQL语法解析器,来运行hiveSQL不支持的语法。

Spark-S3-SparkSQL的架构和原理是什么

Spark SQL由Core、Catalyst、Hive、Hive-ThriftServer四部分构成:
1.Core: 负责处理数据的输入和输出,如获取数据,查询结果输出成DataFrame等
2.Catalyst: 负责处理整个查询过程,包括解析、绑定、优化等
3.Hive: 负责对Hive数据进行处理
4.Hive-ThriftServer: 主要用于对hive的访问

SparkSQL有两个分支,sqlContext和hiveContext,sqlContext现在只支持SQL语法解析器;hiveContext现在支持SQL语法解析器和hivesql语法解析器,默认为hiveSQL语法解析器,用户可以通过配置切换成SQL语法解析器,来运行hiveSQL不支持的语法。

Spark SQL语句的执行顺序
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的次序来进行的,在执行过程有时候甚至不需要读取物理表就可以返回结果,比如重新运行刚运

Spark-S3-SparkSQL的架构和原理是什么

Spark SQL的运行原理

1,使用SessionCatalog保存元数据
在解析SQL语句之前,会创建SparkSession,或者如果是2.0之前的版本初始化SQLContext,SparkSession只是封装了SparkContext和SQLContext的创建而已。会把元数据保存在SessionCatalog中,涉及到表名,字段名称和字段类型。创建临时表或者视图,其实就会往SessionCatalog注册。

2,解析SQL使用ANTLR生成未绑定的逻辑计划
当调用SparkSession的SQL或者SQLContext的SQL方法,我们以2.0为准,就会使用SparkSqlParser进行解析SQL。使用的ANTLR进行词法解析和语法解析。它分为2个步骤来生成Unresolved LogicalPlan:
词法分析:Lexical Analysis, 负责将token分组成符号类。
构建一个分析树或者语法树AST。

3,使用分析器Analyzer绑定逻辑计划
在该阶段,Analyzer会使用Analyzer Rules,并结合SessionCatalog,对未绑定的逻辑计划进行解析,生成已绑定的逻辑计划。

4,使用优化器Optimizer优化逻辑计划
优化器也是会定义一套Rules,利用这些Rule对逻辑计划和Exepression进行迭代处理,从而使得树的节点进行合并和优化。

5,使用SparkPlanner生成物理计划
SparkSpanner使用Planning Strategies,对优化后的逻辑计划进行转换,生成可以执行的物理计划SparkPlan.

6,使用QueryExecution执行物理计划
此时调用SparkPlan的execute方法,底层其实已经再触发JOB了,然后返回RDD。

Spark SQL的运行架构

TreeNode
逻辑计划、表达式等都可以用tree来表示,它只是在内存中维护,并不会进行磁盘的持久化,分析器和优化器对树的修改只是替换已有节点。

TreeNode有2个直接子类,QueryPlan和Expression。QueryPlan下又有LogicalPlan和SparkPlan. Expression是表达式体系,不需要执行引擎计算而是可以直接处理或者计算的节点,包括投影操作,操作符运算等

Rule & RuleExecutor
Rule就是指对逻辑计划要应用的规则,以到达绑定和优化。他的实现类就是RuleExecutor。优化器和分析器都需要继承RuleExecutor。

每一个子类中都会定义Batch、Once、FixPoint. 其中每一个Batch代表着一套规则,Once表示对树进行一次操作,FixPoint表示对树进行多次的迭代操作。

RuleExecutor内部提供一个Seq[Batch]属性,里面定义的是RuleExecutor的处理逻辑,具体的处理逻辑由具体的Rule子类实现。
 

Catalyst优化器

SparkSQL1.1总体上由四个模块组成:core、catalyst、hive、hive-Thriftserver:
    core处理数据的输入输出,从不同的数据源获取数据(RDD、Parquet、json等),将查询结果输出成schemaRDD;
    catalyst处理查询语句的整个处理过程,包括解析、绑定、优化、物理计划等,说其是优化器,还不如说是查询引擎;
    hive对hive数据的处理
    hive-ThriftServer提供CLI和JDBC/ODBC接口
在这四个模块中,catalyst处于最核心的部分,其性能优劣将影响整体的性能。由于发展时间尚短,还有很多不足的地方,但其插件式的设计,为未来的发展留下了很大的空间。

Spark-S3-SparkSQL的架构和原理是什么

从上图看,catalyst主要的实现组件有:
    1.sqlParse,完成sql语句的语法解析功能,目前只提供了一个简单的sql解析器;
    2.Analyzer,主要完成绑定工作,将不同来源的Unresolved LogicalPlan和数据元数据(如hive metastore、Schema catalog)进行绑定,生成resolved LogicalPlan;
    3.optimizer对resolved LogicalPlan进行优化,生成optimized LogicalPlan;
    4.Planner将LogicalPlan转换成PhysicalPlan;、
    5.CostModel,主要根据过去的性能统计数据,选择最佳的物理执行计划

这些组件的基本实现方法:
    1.先将sql语句通过解析生成Tree,然后在不同阶段使用不同的Rule应用到Tree上,通过转换完成各个组件的功能。
    2.Analyzer使用Analysis Rules,配合数据元数据(如hive metastore、Schema catalog),完善Unresolved LogicalPlan的属性而转换成resolved LogicalPlan;
    3.optimizer使用Optimization Rules,对resolved LogicalPlan进行合并、列裁剪、过滤器下推等优化作业而转换成optimized LogicalPlan;
    4.Planner使用Planning Strategies,对optimized LogicalPlan

执行优化

为了说明查询优化,我们来看下图展示的人口数据分析的示例。图中构造了两个DataFrame,将它们join之后又做了一次filter操作。如果原封不动地执行这个执行计划,最终的执行效率是不高的。因为join是一个代价较大的操作,也可能会产生一个较大的数据集。如果我们能将filter下推到 join下方,先对DataFrame进行过滤,再join过滤后的较小的结果集,便可以有效缩短执行时间。而Spark SQL的查询优化器正是这样做的。简而言之,逻辑查询计划优化就是一个利用基于关系代数的等价变换,将高成本的操作替换为低成本操作的过程。

得到的优化执行计划在转换成物 理执行计划的过程中,还可以根据具体的数据源的特性将过滤条件下推至数据源内。最右侧的物理执行计划中Filter之所以消失不见,就是因为溶入了用于执行最终的读取操作的表扫描节点内。

Spark-S3-SparkSQL的架构和原理是什么

DataFrame初探

在Spark中,DataFrame是一种以RDD为基础的分布式数据集,类似于传统数据库中的二维表格。DataFrame与RDD的主要区别在于,前者带有schema元信息,即DataFrame所表示的二维表数据集的每一列都带有名称和类型。这使得Spark SQL得以洞察更多的结构信息,从而对藏于DataFrame背后的数据源以及作用于DataFrame之上的变换进行了针对性的优化,最终达到大幅提升运行时效率的目标。反观RDD,由于无从得知所存数据元素的具体内部结构,Spark Core只能在stage层面进行简单、通用的流水线优化。

DataFrame的特性

能够将单个节点集群上的大小为Kilobytes到Petabytes的数据处理为大型集群。
支持不同的数据格式(Avro,csv,弹性搜索和Cassandra)和存储系统(HDFS,HIVE表,MySQL等)。
通过Spark SQL Catalyst优化器(树变换框架)的最先进的优化和代码生成。
可以通过Spark-Core轻松地与所有大数据工具和框架集成。
提供用于Python,Java,Scala和R编程的API。

Spark-S3-SparkSQL的架构和原理是什么

创建DataFrame
在Spark SQL中,开发者可以非常便捷地将各种内、外部的单机、分布式数据转换为DataFrame。

# 从Hive中的users表构造
DataFrame users = sqlContext.table("users") 
# 加载S3上的JSON文件 
logs = sqlContext.load("s3n://path/to/data.json", "json") 
# 加载HDFS上的Parquet文件 
clicks = sqlContext.load("hdfs://path/to/data.parquet", "parquet") 
# 通过JDBC访问MySQL comments = sqlContext.jdbc("jdbc:mysql://localhost/comments", "user") 
# 将普通RDD转变为

DataFrame rdd = sparkContext.textFile("article.txt") \ 
                   .flatMap(lambda line: line.split()) \ 
                   .map(lambda word: (word, 1)) \ 
                   .reduceByKey(lambda a, b: a + b) \ 
wordCounts = sqlContext.createDataFrame(rdd, ["word", "count"])

# 将本地数据容器转变为

DataFrame data = [("Alice", 21), ("Bob", 24)] 
people = sqlContext.createDataFrame(data, ["name", "age"])

使用DataFrame

和R、Pandas类似,Spark DataFrame也提供了一整套用于操纵数据的DSL。这些DSL在语义上与SQL关系查询非常相近(这也是Spark SQL能够为DataFrame提供无缝支持的重要原因之一) 。

# 创建一个只包含"年轻"用户的DataFrame
df = users.filter(users.age < 21)

# 也可以使用Pandas风格的语法
df = users[users.age < 21]

# 将所有人的年龄加1
df.select(young.name, young.age + 1)

# 统计年轻用户中各性别人数
df.groupBy("gender").count()

# 将所有年轻用户与另一个名为logs的DataFrame联接起来
df.join(logs, logs.userId == users.userId, "left_outer")

保存DataFrame
当数据分析逻辑编写完毕后,我们便可以将最终结果保存下来或展现出来。

# 追加至HDFS上的Parquet文件

df.save(path="hdfs://path/to/data.parquet",
           source="parquet",
           mode="append")

# 覆写S3上的JSON文件

df.save(path="s3n://path/to/data.json",
           source="json",
           mode="append")

# 保存为SQL表
df.saveAsTable(tableName="young", source="parquet" mode="overwrite")

# 转换为Pandas DataFrame(Python API特有功能)
pandasDF = young.toPandas()

# 以表格形式打印输出
df.show()
 

到此,相信大家对“Spark-S3-SparkSQL的架构和原理是什么”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!


网站名称:Spark-S3-SparkSQL的架构和原理是什么
链接地址:http://myzitong.com/article/jigijh.html