Spark之SQL解析(源码阅读十)

  如何能更好的运用与监控sparkSQL?或许我们改更深层次的了解它深层次的原理是什么。之前总结的已经写了传统数据库与Spark的sql解析之间的差别。那么我们下来直切主题~

  如今的Spark已经支持多种多样的数据源的查询与加载,兼容了Hive,可用JDBC的方式或者ODBC来连接Spark SQL。下图为官网给出的架构.那么sparkSql呢可以重用Hive本身提供的元数据仓库(MetaStore)HiveQL、以及用户自定义函数(UDF)序列化反序列化的工具(SerDes).

  下来我们来细化SparkContext,大的流程是这样的:

  1、SQL语句经过SqlParser解析成Unresolved LogicalPlan;

  2、使用analyzer结合数据字典(catalog)进行绑定,生成Resolved LogicalPlan;

  3、使用optimizerResolved LogicalPlan进行优化,生成Optimized LogicalPlan;

  4、使用SparkPlanLogicalPlan转换成PhysiclPlan;

  5、使用prepareForExceptionPhysicalPlan转换成可执行物理计划。

  6、使用execute()执行可执行物理计划,生成DataFrame.

  这些解析的过程,我们都可以通过监控页面观察的到。

  下来我们先从第一个Catalog开始,什么是Catalog?它是一个字典表,用于注册表,对标缓存后便于查询,源码如下:

  

  这个类呢,是个特质,定义了一些tableExistes:判断表是否存在啊,registerTable:注册表啊、unregisterAllTables:清除所有已经注册的表啊等等。在创建时,new的是SimpleCatalog实现类,这个类实现了Catalog中的所有接口,将表名logicalPlan一起放入table缓存,曾经的版本中呢,使用的是mutable.HashMap[String,LogicalPlan]。现在声明的是ConcurrentHashMap[String,LogicalPlan]

  然后呢,我们来看一下词法解析器Parser的实现。在原先的版本中,调用sql方法,返回的是SchemaRDD,现在的返回类型为DataFrame:

  

  你会发现,调用了parseSql,在解析完后返回的是一个物理计划。

  

  我们再深入parse方法,发现这里隐式调用了apply方法

  

  下来我们看一下,它的建表语句解析,你会发现其实它是解析了物理计划,然后模式匹配来创建表:

  

  最后调用了RefreshTable中的run方法:

  

  那么创建完表了,下来开始痛苦的sql解析。。。上传说中的操作符函数与解析的所有sql函数!

  

   

  一望拉不到底。。。这个Keyword其实是对sql语句进行了解析:

  

  然后拿一个select的sql语法解析为例,本质就是将sql语句的条件进行了匹配过滤筛选

  

  一个select的步骤包括,获取DISTINCT语句投影字段projection表relationswhere后的表达式group by后的表达式hiving后的表达式排序字段orderingLimit后的表达式。随之就进行匹配封装操作RDD,Filter、Aggregate、Project、Distinct、sort、Limit,最终形成一颗LogicalPlan的Tree.

  那么join操作,也包含了左外连接、全外连接、笛卡尔积等。

  

  好的,既然sql的执行计划解析完了,下来该对解析后的执行计划进行优化,刚才的解析过程将sql解析为了一个Unresolved LogicalPlan的一棵树。下来Analyzeroptimizer将会对LogicalPlan的这棵树加入各种分析和优化操作,比如列剪枝谓词下压啊。

  AnalyzerUnresolved LogicalPlan数据字典(catalog)进行绑定,生成resolved LogicalPlan.然后呢OptimizerResolved LogicalPlan进行优化,生成Optimized LogicalPlan.

  

  这里的useCachedData方法实际是用于将LogicalPlan的树段替换为缓存中的。具体过滤优化看不懂啊TAT 算了。。第一遍源码,讲究先全通一下吧。

  下来,一系列的解析啊、分析啊、优化啊操作过后,因为生成的逻辑执行计划无法被当做一般的job来处理,所以为了能够将逻辑执行计划按照其他job一样对待,需要将逻辑执行计划变为物理执行计划。

  

  如下图,你注意哦,配置文件中shufflePartition的个数就是从这里传进来的。

  

  

  这里面真正牛逼变态的是BasicOperators。它对最常用的SQL关键字都做了处理,每个处理的分支,都会调用planLater方法,planLater方法给child节点的LogicalPlan应用sparkPlanner,于是就差形成了迭代处理的过程。最终实现将整颗LogicalPlan树使用SparkPlanner来完成转换。最终执行物理计划。

  

  

参考文献:《深入理解Spark:核心思想与源码分析》

时间: 2024-10-15 21:26:41

Spark之SQL解析(源码阅读十)的相关文章

SparkStreaming(源码阅读十二)

要完整去学习spark源码是一件非常不容易的事情,但是咱可以积少成多嘛~那么,Spark Streaming是怎么搞的呢? 本质上,SparkStreaming接收实时输入数据流并将它们按批次划分,然后交给Spark引擎处理生成按照批次划分的结果流: SparkStreaming提供了表示连续数据流的.高度抽象的被称为离散流的Dstream,可以使用kafka.Flume和Kiness这些数据源的输入数据流创建Dstream,也可以在其他Dstream上使用map.reduce.join.win

Zookeeper源码阅读(十八) 选举之快速选举算法FastLeaderElection

目录 前言 FastLeaderEleaction基本结构 选举方法分析 思考 参考 前言 在过去的两节里已经分析了选举过程中的一些实体类和网络IO相关的机制与源码,这一节将会对zookeeper选举的核心类FastLeaderElection进行分析. FastLeaderEleaction基本结构 可以看到FastLeaderElection的基本结构还是比较清晰的,主要从新的成员变量类和内部类来分析下FastLeaderElection的基本结构. Notification /** * N

Zookeeper源码阅读(十四) 单机Server

前言 前面两篇主要说了下client-server的session相关的内容,到这里client的内容以及client-server的连接的内容也就基本告一段落了,剩下的部分就是server部分内部的结构,zk的选举以及server部分的工作机制等了. 这一篇主要说下单机server的启动过程,里面会涉及到一些server内部的工作机制和机构. Server架构 可以看到Zookeeper的server端主要分为几个大模块,ZKDatabase是zk server内部的内存数据库,内部维护了节点

SDWebImage源码阅读(十五)UIView+WebCacheOperation

这个分类主要用来对 UIView 的图像下载操作添加.取消和移除. .h 1 * Set the image load operation (storage in a UIView based dictionary) 2 * 3 * @param operation the operation 4 * @param key key for storing the operation 5 */ 6 - (void)sd_setImageLoadOperation:(nullable id)oper

Zookeeper源码阅读(十二) Seesion(1)

前言 前面三篇主要从client的角度说了下client和server建立连接的过程,这一篇和后面一篇开始看下Zookeeper中非常重要的一个概念:Session,session是zookeeper client和server建立和维护连接的单位(我这个描述感觉有点奇怪 ?? ). Session状态 Zookeeper的所有操作基本都是基于session的,如之前提到的wathcer的机制,客户端请求的顺序执行和临时节点的生命周期. 从我们使用API的角度,session的连接和保持就是客户

[Apache Spark源码阅读]天堂之门——SparkContext解析

稍微了解Spark源码的人应该都知道SparkContext,作为整个Project的程序入口,其重要性不言而喻,许多大牛也在源码分析的文章中对其做了很多相关的深入分析和解读.这里,结合自己前段时间的阅读体会,与大家共同讨论学习一下Spark的入口对象—天堂之门—SparkContex. SparkContex位于项目的源码路径\spark-master\core\src\main\scala\org\apache\spark\SparkContext.scala中,源文件包含Classs Sp

淘宝数据库OceanBase SQL编译器部分 源码阅读--生成逻辑计划

body, td { font-family: tahoma; font-size: 10pt; } 淘宝数据库OceanBase SQL编译器部分 源码阅读--生成逻辑计划 SQL编译解析三部曲分为:构建语法树,生成逻辑计划,指定物理执行计划.第一步骤,在我的上一篇博客淘宝数据库OceanBase SQL编译器部分 源码阅读--解析SQL语法树里做了介绍,这篇博客主要研究第二步,生成逻辑计划. 一. 什么是逻辑计划?我们已经知道,语法树就是一个树状的结构组织,每个节点代表一种类型的语法含义.如

淘宝数据库OceanBase SQL编译器部分 源码阅读--生成物理查询计划

SQL编译解析三部曲分为:构建语法树,制定逻辑计划,生成物理执行计划.前两个步骤请参见我的博客<<淘宝数据库OceanBase SQL编译器部分 源码阅读--解析SQL语法树>>和<<淘宝数据库OceanBase SQL编译器部分 源码阅读--生成逻辑计划>>.这篇博客主要研究第三步,生成物理查询计划. 一. 什么是物理查询计划 与之前的阅读方法一致,这篇博客的两个主要问题是what 和how.那么什么是物理查询计划?物理查询计划能够直接执行并返回数据结果数

spark.mllib源码阅读-分类算法4-DecisionTree

本篇博文主要围绕Spark上的决策树来讲解,我将分为2部分来阐述这一块的知识.第一部分会介绍一些决策树的基本概念.Spark下决策树的表示与存储.结点分类信息的存储.结点的特征选择与分类:第二部分通过一个Spark自带的示例来看看Spark的决策树的训练算法.另外,将本篇与上一篇博文"spark.mllib源码阅读bagging方法"的bagging子样本集抽样方法结合,也就理解了Spark下的决策森林树的实现过程. 第一部分: 决策树模型 分类决策树模型是一种描述对实例进行分类的树形