大数据 -97 Spark 集群 SparkSQL 原理详细解析 Broadcast Shuffle SQL 解析过程

点一下关注吧!!!非常感谢!!持续更新!!!
🚀 AI 篇持续更新中!(长期更新)
AI 炼丹日志-31- 千呼万唤始出来 GPT-5 发布!“快的模型 + 深度思考模型 + 实时路由”,持续打造实用 AI 工具指南!📐🤖
💻 Java 篇正式开启!(300 篇)
目前 2025 年 09 月 15 日更新到:Java-124 深入浅出 MySQL Seata 框架详解:分布式事务的四种模式与核心架构 MyBatis 已完结,Spring 已完结,Nginx 已完结,Tomcat 已完结,分布式服务正在更新!深入浅出助你打牢基础!
📊 大数据板块已完成多项干货更新(300 篇):
包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件,覆盖离线+实时数仓全栈!大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解

章节内容
上节我们完成了如下的内容:
SparkSQL 语句 编码 测试 结果
输入输出
数据源包含如 Parquet、JSON、CSV、Avro、ORC、Hive、JDBC、ODBC
TextFile

SparkSQL 中的 Join
数据分析中将两个数据集进行 Join 操作是很常见的场景。在 Spark 的物理计划阶段,Spark 的 Join Selection 类会根据 Join Hints 策略,Join 表的大小、Join 是等值 Join 还是不等值以及参与 Join 的 Key 是否可以排序等条件来选择最终的 Join 策略,最后 Spark 会利用选择好的 Join 策略执行最终的计算。
当前 Spark 一共支持五种 Join 策略:
Broadcast hash join (BHJ)
Shuffle hash join (SHJ)
Shuffle sort merge join(SMJ)
Shuffle-and-replicate nested loop join,又叫笛卡尔积(Cartesian product join)
Broadcast nested loop join(BNLJ)
其中 BHJ 和 SMJ 这两种 Join 策略是我们运行 Spark 任务最常见的。JoinSelection 会先根据 Join 的 Key 为等值 Join 来选择 Broadcast hash join、Shuffle hash join、Shuffle sort merge join 中的一个。如果 Join 的 Key 为不等值 Join 或者没有指定 Join 条件,则会选择 Broadcast nested loop join 或 Shuffle-and-replicate nested loop join。不同的 Join 策略在执行效率上差别很大,了解每种 Join 策略的执行过程和适用条件是很有必要的。
Broadcast Hash Join
Broadcast Hash Join 的实现是将小表的数据广播到 Spark 所有的 Executor 端,这个广播过程和我们自己去广播数据没有什么区别:
利用 Collect 算子将小表的数据从 Executor 端拉到 Driver 端
在 Driver 端调用 sparkContext.broadcast 广播到所有 Executor 端
在 Executor 端使用广播的数据与大表进行 Join 操作(实际上执行 Map 操作)
这种 Join 策略避免了 Shuffle 操作,一般而言,Broadcast Hash Join 会比其他 Join 策略执行的要快。

使用这种 Join 策略必须满足如下的条件:
小表的数据必须很小,可以通过 spark.sql.autoBroadcasetJoinThreshold 参数来配置,默认是 10MB
如果内存比较大,可以将阈值适当加大
将 spark.sql.autoBroadcastJoinThreshold 参数设置为-1,可以关闭这种连接方式
只能用于等值 Join,不要求参与 Join 的 keys 可排序
Shuffle Hash Join
当表中的数据比较大,又不适合使用广播,这个时候就可以考虑 Shuffle Hash Join。Shuffle Hash Join 同样是在大表和小表进行 Join 的时候选择了一种策略。它的计算思想是:把大表和小表按照相同的分区算法和分区数据进行分区(根据参与 Join 的 Keys 进行分区),这样保证了 Hash 值一样的数据都分发到同一个分区中,然后在同一个 Executor 中两张表 Hash 值一样的分区就可以在本地进行 Hash Join 了。在进行 Join 之前,还会对小表的分区构建 Hash Map,Shuffle Hash Join 利用了分治思想,把大问题拆解成小问题去解决。

要启动 Shuffle Hash Join 必须满足以下条件:
仅支持等值 Join,不要求参与 Join 的 Keys 可排序
spark.sql.join.perferSortMergeJoin 参数必须设置值为 false,参数从 Spark2.0 版本引入,默认值是 true,也就是默认情况下是 Sort Merge Join
小表的大小(plan.stats.sizeInBytes)必须小于(spark.sql.autoBroadcastJoinThreshold * spark.sql.shuffle.partitions(默认 200))
而且小表大小(stats.sizeInBytes)的三倍必须小于等于大表的大小(stats.sizeInBytes),也就是(a.stats.sizeInBytes * 3 < b.stats.sizeInBytes)
Shuffle Sort Merge Join
前面两种 Join 策略对表的大小都有条件的,如果参与 Join 的表都很大,这时候就得考虑用 Shuffle Sort Merge Join 了。Shuffle Sort Merge Join 的实现事项:
将两张表按照 Join Key 进行 Shuffle,保证 Join Key 值相同的记录会被分在相应的分区
对每个分区内的数据进行排序
排序后再对相应的分区内的记录进行连接
无论分区多大,Sort Merge Join 都不用把一侧的数据全部加载到内存中,而是即用即丢。因为两个序列都有序,从头遍历,碰到 Key 相同的就输出,如果不同,左边小取左边,反之就取右边。这样大大提高了大数据量下的 SQL Join 的稳定性。

要启用 Shuffle Sort Merge Join 必须满足以下条件:
仅支持等值 Join,并且要求参与 Join 的 Keys 可排序
Cartesian Product Join
如果 Spark 中两张参与 Join 的表没有指定连接条件,那么产生 Cartesian Product Join,这个 Join 得到的结果其实就是两张表行数的乘积。
Broadcast Nested Loop Join
可以把 Broadcast Nested Loop Join 的执行看做下面的计算:
可以看出 Broadcast Nested Loop Join 在某些情况会对某张表重复扫描多次,效率非常低。从名字可以看出,这种 Join 会根据相关条件对小表进行广播,以减少表的扫描次数。Broadcast Nested Loop Join 支持等值和不等值 Join,支持所有的 Join 类型。
SQL 解析过程
基本概念
SparkSQL 可以说 Spark 中的精华部分,原来基于 RDD 构建大数据计算任务,重新在向 Dataset 转移,原来基于 RDD 写的代码也在迁移。使用 SparkSQL 编码的好处是非常大的,尤其是性能方面,有很大提升。SparkSQL 中各种内嵌的性能优化比写 RDD 遵循各种最佳实践更加靠谱。尤其对于新手来说,比如先 Filter 再 Map,SparkSQL 中会自动进行谓词下推,Spark SQL 中会自动使用 Broadcast Join 来广播小表,把 Shuffle Join 转换为 Map Join 等等。
SparkSQL 对 SQL 语句的处理和关系型数据库类似,即词法/语法解析、绑定、优化、执行。SparkSQL 会先将 SQL 语句解析成一棵树,然后使用规则(Rule)对 Tree 进行绑定、优化等处理过程。SparkSQL 由:Core、Catalyst、Hive、Hive-ThriftServer 四部分构成:
Core:负责处理数据的输入和输出,如获取数据,查询结果输出成 DataFrame 等
Catalyst:负责处理整个查询过程,包括解析、绑定、优化等。
Hive:负责对 Hive 数据进行处理
Hive-ThriftServer:主要用于对 Hive 的访问


SparkSQL 的代码复杂度是问题的本质复杂度带来说,SparkSQL 中的 Catalyst 框架大部分逻辑是在一个 Tree 类型的数据结构上做各种折腾,基于 Scala 来实现还是很优雅的,Scala 的偏函数和强大的 Case 正则匹配,让整个代码看起来非常优雅。
SparkSession 是编写 Spark 应用代码的入口,启动一个 spark-shell 会提供给你创建 spark-session,这个对象是整个 Spark 应用的起始点,以下是 SparkSession 的一些重要的变量和方法:

编写代码
运行输出
执行代码可见控制台输出如下数据(我就不往服务器发了):

分析内容
queryExecution 就是对整个执行计划的执行引擎,里面有执行过程中各个中间过程变量,整个执行流程如下:

刚才的例子中的 SQL 语句经过 Parser 解析后就会变成一个抽象语法树,对应解析后的逻辑计划 AST 为:
在执行计划中 Project/Projection 代表的意思是投影

其中过滤条件变为了 Filter 节点,这个节点是 UnaryNode (一元节点)类型,只有一个孩子。两个表中的数据变为了 UnresolvedRelation 节点,节点类型为 LeafNode,即叶子节点,Join 操作为节点,这个是一个 BinaryNode 节点,有两个孩子。以上节点都是 LogicalPlan 类型的,可以理解为各种操作的 Operator,SparkSQL 对各种操作定义了各种 Operator。

这些 Operator 组成的语法树就是整个 Catatyst 优化的基础,Catatyst 优化器会在这个树上进行分析修改,把树上的节点挪来挪去进行优化。经过 Parser 有了抽象语法树,但是并不知道 Score,Sum 这些东西,所以就需要 Analyer 定位。
Analyzer 会把 AST 上所有 Unresolved 的东西都转换为 Resolved 状态,SparkSQL 有很多 Resolve 规则:
ResolverRelations:解析表(列)的基本类型信息
ResolveFunctions:解析出来函数的基本信息
ResolveReferences:解析引用,通常是解析列名

常见优化逻辑


这里用到的优化有:谓词下推(Push Down Predicate)、常量折叠(Constant Folding)、字段裁剪(Columning Pruning):

做完逻辑优化,还需要先转换为物理执行计划,将逻辑上可行的执行计划变为 Spark 可以真正执行的计划:

SparkSQL 把逻辑节点转换为了相应的物理节点,比如 Join 算子,Spark 根据不同的场景为该算子制定了不同的算法策略。
数据在一个一个的 Plan 中流转,然后每个 plan 里面表达式都会对数据进行处理,就相当于经过了一个个小函数的调用处理,这里面有大量的函数调用开销,可以把这些小函数内联一下,当成一个大函数。可以看到最终执行计划每个节点面前有个*号,说明整段代码生成被启用。
版权声明: 本文为 InfoQ 作者【武子康】的原创文章。
原文链接:【http://xie.infoq.cn/article/eb94a99e52184e272e3b3cd00】。文章转载请联系作者。
评论