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

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:   如何能更好的运用与监控sparkSQL?或许我们改更深层次的了解它深层次的原理是什么。之前总结的已经写了传统数据库与Spark的sql解析之间的差别。那么我们下来直切主题~  如今的Spark已经支持多种多样的数据源的查询与加载,兼容了Hive,可用JDBC的方式或者ODBC来连接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:核心思想与源码分析》

目录
相关文章
|
7天前
|
消息中间件 缓存 安全
Future与FutureTask源码解析,接口阻塞问题及解决方案
【11月更文挑战第5天】在Java开发中,多线程编程是提高系统并发性能和资源利用率的重要手段。然而,多线程编程也带来了诸如线程安全、死锁、接口阻塞等一系列复杂问题。本文将深度剖析多线程优化技巧、Future与FutureTask的源码、接口阻塞问题及解决方案,并通过具体业务场景和Java代码示例进行实战演示。
26 3
|
20天前
|
SQL 监控 数据库
SQL语句是否都需要解析及其相关技巧和方法
在数据库管理中,SQL(结构化查询语言)语句的使用无处不在,它们负责数据的查询、插入、更新和删除等操作
|
24天前
|
存储
让星星⭐月亮告诉你,HashMap的put方法源码解析及其中两种会触发扩容的场景(足够详尽,有问题欢迎指正~)
`HashMap`的`put`方法通过调用`putVal`实现,主要涉及两个场景下的扩容操作:1. 初始化时,链表数组的初始容量设为16,阈值设为12;2. 当存储的元素个数超过阈值时,链表数组的容量和阈值均翻倍。`putVal`方法处理键值对的插入,包括链表和红黑树的转换,确保高效的数据存取。
50 5
|
26天前
|
Java Spring
Spring底层架构源码解析(三)
Spring底层架构源码解析(三)
|
26天前
|
XML Java 数据格式
Spring底层架构源码解析(二)
Spring底层架构源码解析(二)
|
20天前
|
SQL 数据可视化 BI
SQL语句及查询结果解析:技巧与方法
在数据库管理和数据分析中,SQL语句扮演着至关重要的角色
|
26天前
|
SQL 监控 关系型数据库
SQL错误代码1303解析与处理方法
在SQL编程和数据库管理中,遇到错误代码是常有的事,其中错误代码1303在不同数据库系统中可能代表不同的含义
|
26天前
|
SQL 存储 关系型数据库
SQL默认索引是什么:深入解析与技巧
在SQL数据库中,索引是一种用于提高查询性能的重要数据结构
|
26天前
|
SQL 开发框架 .NET
ASP.NET连接SQL数据库:实现过程与关键细节解析an3.021-6232.com
随着互联网技术的快速发展,ASP.NET作为一种广泛使用的服务器端开发技术,其与数据库的交互操作成为了应用开发中的重要环节。本文将详细介绍在ASP.NET中如何连接SQL数据库,包括连接的基本概念、实现步骤、关键代码示例以及常见问题的解决方案。由于篇幅限制,本文不能保证达到完整的2000字,但会确保
|
26天前
|
算法 Java 程序员
Map - TreeSet & TreeMap 源码解析
Map - TreeSet & TreeMap 源码解析
31 0

推荐镜像

更多