BroadcastNestedLoopJoin和禁不掉的广播

最新推荐文章于 2025-03-19 17:33:05 发布
原创 最新推荐文章于 2025-03-19 17:33:05 发布 · 4.8k 阅读 · 14 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#scala #spark #big data

本文探讨了在Spark SQL中遇到的两种情况：一是多条件Join导致BroadcastNestedLoopJoin性能下降，二是NOT IN条件无法关闭广播。通过案例分析，提出了两种解决方案：一是通过改写Join条件并利用UNION来避免BroadcastNestedLoopJoin；二是使用NOT EXISTS子查询或LEFT ANTI JOIN替代NOT IN条件。这两种方法在不同场景下能有效提高查询性能。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

先来看一个普通的Left Join

import org.apache.spark.sql.SparkSession
import org.apache.spark.sql.functions.broadcast

case class People(id: Int, name: String)

case class Student(sid: Int, sname: String)

object TestBroadcastNestedLoopJoin3 {

    def main(args: Array[String]): Unit = {
        val spark = SparkSession
            .builder()
            .master("local")
            .appName("TestBroadcastNestedLoopJoin")
            //.config("spark.sql.autoBroadcastJoinThreshold", -1)
            .getOrCreate()
        import spark.implicits._
        val df1 = spark.createDataFrame(Seq(
            People(1, "darren"),
            People(2, "zhang"),
            People(3, "jonathan"),
            People(4, "li"),
            People(5, "joyce"),
            People(6, "chen"),
            People(7, "chaoshu"),
            People(8, "sha"),
            People(9, "cindy"),
            People(10, "xie"))).as[People]
        //        df1.show()

        val df2 = spark.createDataFrame(Seq(
            Student(1, "darren"),
            Student(2, "jonathan"))).as[Student]

        val df3 = df1.join(df2, $"id" === $"sid", joinType = "left")

        df3.show()
        df3.explain()
        spark.stop()
    }
}


+---+--------+----+--------+
| id|    name| sid|   sname|
+---+--------+----+--------+
|  1|  darren|   1|  darren|
|  2|   zhang|   2|jonathan|
|  3|jonathan|null|    null|
|  4|      li|null|    null|
|  5|   joyce|null|    null|
|  6|    chen|null|    null|
|  7| chaoshu|null|    null|
|  8|     sha|null|    null|
|  9|   cindy|null|    null|
| 10|     xie|null|    null|
+---+--------+----+--------+

== Physical Plan ==
*(1) BroadcastHashJoin [id#0], [sid#7], LeftOuter, BuildRight
:- LocalTableScan [id#0, name#1]
+- BroadcastExchange HashedRelationBroadcastMode(List(cast(input[0, int, false] as bigint)))
   +- LocalTableScan [sid#7, sname#8]

正常的BroadcastHashJoin，性能很好。
但是，我修改一下Join条件：

问题一，多个条件或者关系，广播无法关闭

val df3 = df1.join(df2, $"id" === $"sid" || $"name" === $"sname", joinType = "left")

+---+--------+----+--------+
| id|    name| sid|   sname|
+---+--------+----+--------+
|  1|  darren|   1|  darren|
|  2|   zhang|   2|jonathan|
|  3|jonathan|   2|jonathan|
|  4|      li|null|    null|
|  5|   joyce|null|    null|
|  6|    chen|null|    null|
|  7| chaoshu|null|    null|
|  8|     sha|null|    null|
|  9|   cindy|null|    null|
| 10|     xie|null|    null|
+---+--------+----+--------+

== Physical Plan ==
BroadcastNestedLoopJoin BuildRight, LeftOuter, ((id#0 = sid#7) || (name#1 = sname#8))
:- LocalTableScan [id#0, name#1]
+- BroadcastExchange IdentityBroadcastMode
   +- LocalTableScan [sid#7, sname#8]

这里就出现了性能很差的BroadcastNestedLoopJoin。
这是就想到了方案，关闭广播不就行了。

方案一：关闭广播（错误的方案）

打开注视，然后再运行看看

.config("spark.sql.autoBroadcastJoinThreshold", -1)

+---+--------+----+--------+
| id|    name| sid|   sname|
+---+--------+----+--------+
|  1|  darren|   1|  darren|
|  2|   zhang|   2|jonathan|
|  3|jonathan|   2|jonathan|
|  4|      li|null|    null|
|  5|   joyce|null|    null|
|  6|    chen|null|    null|
|  7| chaoshu|null|    null|
|  8|     sha|null|    null|
|  9|   cindy|null|    null|
| 10|     xie|null|    null|
+---+--------+----+--------+

== Physical Plan ==
BroadcastNestedLoopJoin BuildRight, LeftOuter, ((id#0 = sid#7) || (name#1 = sname#8))
:- LocalTableScan [id#0, name#1]
+- BroadcastExchange IdentityBroadcastMode
   +- LocalTableScan [sid#7, sname#8]

可以看出没有任何变化，并不能关闭广播。
注：其实仔细想想也能想明白，问什么关闭广播对BroadcastNestedLoopJoin不管用。因为BroadcastNestedLoopJoin需要对右表进行逐行遍历。所以必须把全部右表的内容广播到各个计算节点。
如果右表的数据量很大，就会出现broadcastTimeout的异常。所以，需要尽可能避免BroadcastNestedLoopJoin。

方案二，正确的方案

开着广播的情况

//打开broadcast
//.config("spark.sql.autoBroadcastJoinThreshold", -1)
// 导入包
import org.apache.spark.sql.functions.lit

        val df3_1 = df1.join(df2, $"id" === $"sid", joinType = "inner")
            .union(df1.join(df2, $"name" === $"sname", joinType = "inner"))
            .distinct()

        val df3 = df1.join(df3_1.selectExpr("id as id_1"), $"id" === $"id_1", joinType = "left_anti")
            .withColumn("sid", lit(null))
            .withColumn("sname", lit(null))
            .union(df3_1)

+---+--------+----+--------+
| id|    name| sid|   sname|
+---+--------+----+--------+
|  4|      li|null|    null|
|  5|   joyce|null|    null|
|  6|    chen|null|    null|
|  7| chaoshu|null|    null|
|  8|     sha|null|    null|
|  9|   cindy|null|    null|
| 10|     xie|null|    null|
|  1|  darren|   1|  darren|
|  2|   zhang|   2|jonathan|
|  3|jonathan|   2|jonathan|
+---+--------+----+--------+

== Physical Plan ==
Union
:- *(5) Project [id#0, name#1, null AS sid#132, null AS sname#133]
:  +- *(5) BroadcastHashJoin [id#0], [id_1#90], LeftAnti, BuildRight
:     :- LocalTableScan [id#0, name#1]
:     +- BroadcastExchange HashedRelationBroadcastMode(List(cast(input[0, int, false] as bigint)))
:        +- *(4) HashAggregate(keys=[id#0, name#1, sid#7, sname#8], functions=[])
:           +- Exchange hashpartitioning(id#0, name#1, sid#7, sname#8, 200)
:              +- *(3) HashAggregate(keys=[id#0, name#1, sid#7, sname#8], functions=[])
:                 +- Union
:                    :- *(1) BroadcastHashJoin [id#0], [sid#7], Inner, BuildRight
:                    :  :- LocalTableScan [id#0, name#1]
:                    :  +- BroadcastExchange HashedRelationBroadcastMode(List(cast(input[0, int, false] as bigint)))
:                    :     +- LocalTableScan [sid#7, sname#8]
:                    +- *(2) BroadcastHashJoin [name#1], [sname#8], Inner, BuildRight
:                       :- LocalTableScan [id#0, name#1]
:                       +- BroadcastExchange HashedRelationBroadcastMode(List(input[1, string, true]))
:                          +- LocalTableScan [sid#7, sname#8]
+- *(9) HashAggregate(keys=[id#0, name#1, sid#7, sname#8], functions=[])
   +- ReusedExchange [id#0, name#1, sid#7, sname#8], Exchange hashpartitioning(id#0, name#1, sid#7, sname#8, 200)

关闭广播的情况：

== Physical Plan ==
Union
:- *(11) Project [id#0, name#1, null AS sid#84, null AS sname#85]
:  +- SortMergeJoin [id#0], [id_1#42], LeftAnti
:     :- *(1) Sort [id#0 ASC NULLS FIRST], false, 0
:     :  +- Exchange hashpartitioning(id#0, 200)
:     :     +- LocalTableScan [id#0, name#1]
:     +- *(10) Sort [id_1#42 ASC NULLS FIRST], false, 0
:        +- Exchange hashpartitioning(id_1#42, 200)
:           +- *(9) HashAggregate(keys=[id#0, name#1, sid#7, sname#8], functions=[])
:              +- Exchange hashpartitioning(id#0, name#1, sid#7, sname#8, 200)
:                 +- *(8) HashAggregate(keys=[id#0, name#1, sid#7, sname#8], functions=[])
:                    +- Union
:                       :- *(4) SortMergeJoin [id#0], [sid#7], Inner
:                       :  :- *(2) Sort [id#0 ASC NULLS FIRST], false, 0
:                       :  :  +- ReusedExchange [id#0, name#1], Exchange hashpartitioning(id#0, 200)
:                       :  +- *(3) Sort [sid#7 ASC NULLS FIRST], false, 0
:                       :     +- Exchange hashpartitioning(sid#7, 200)
:                       :        +- LocalTableScan [sid#7, sname#8]
:                       +- *(7) SortMergeJoin [name#1], [sname#8], Inner
:                          :- *(5) Sort [name#1 ASC NULLS FIRST], false, 0
:                          :  +- Exchange hashpartitioning(name#1, 200)
:                          :     +- LocalTableScan [id#0, name#1]
:                          +- *(6) Sort [sname#8 ASC NULLS FIRST], false, 0
:                             +- Exchange hashpartitioning(sname#8, 200)
:                                +- LocalTableScan [sid#7, sname#8]
+- *(19) HashAggregate(keys=[id#0, name#1, sid#7, sname#8], functions=[])
   +- ReusedExchange [id#0, name#1, sid#7, sname#8], Exchange hashpartitioning(id#0, name#1, sid#7, sname#8, 200)

可以看到方案二也很复杂，Union倒不是问题，问题有三次Join，要看实际效果怎样，需要用真实的数据进行测试。这里只提到思路。

参考

Avoid Broadcast nested loop join

问题二，not in条件， 广播无法关闭

打开广播开关

        df1.createOrReplaceTempView("df1")
        df2.createOrReplaceTempView("df2")
        val df3 = spark.sql(
            """
              |select * from df1 where id not in (select sid from df2)
              |""".stripMargin)

+---+--------+
| id|    name|
+---+--------+
|  3|jonathan|
|  4|      li|
|  5|   joyce|
|  6|    chen|
|  7| chaoshu|
|  8|     sha|
|  9|   cindy|
| 10|     xie|
+---+--------+

== Physical Plan ==
BroadcastNestedLoopJoin BuildRight, LeftAnti, ((id#0 = sid#7) || isnull((id#0 = sid#7)))
:- LocalTableScan [id#0, name#1]
+- BroadcastExchange IdentityBroadcastMode
   +- LocalTableScan [sid#7]

可以看到广播无法关闭

方案一，使用not exists，正确的方案

       val df3 = spark.sql(
            """
              |select * from df1 where not exists (select 1 from df2 where df1.id = df2.sid)
              |""".stripMargin)

+---+--------+
| id|    name|
+---+--------+
|  6|    chen|
|  3|jonathan|
|  5|   joyce|
|  9|   cindy|
|  4|      li|
|  8|     sha|
|  7| chaoshu|
| 10|     xie|
+---+--------+

== Physical Plan ==
SortMergeJoin [id#0], [sid#7], LeftAnti
:- *(1) Sort [id#0 ASC NULLS FIRST], false, 0
:  +- Exchange hashpartitioning(id#0, 200)
:     +- LocalTableScan [id#0, name#1]
+- *(3) Sort [sid#7 ASC NULLS FIRST], false, 0
   +- Exchange hashpartitioning(sid#7, 200)
      +- *(2) Project [sid#7]
         +- LocalTableScan [1#26, sid#7]

可以看到不再使用BroadcastNestedLoopJoin了

参考

Disable broadcast when query plan has BroadcastNestedLoopJoin
BroadcastNestedLoopJoin example

方案二，使用left anti join，正确的方案

val df3 = df1.join(df2, $"id" === $"sid", joinType = "left_anti")

+---+--------+
| id|    name|
+---+--------+
|  6|    chen|
|  3|jonathan|
|  5|   joyce|
|  9|   cindy|
|  4|      li|
|  8|     sha|
|  7| chaoshu|
| 10|     xie|
+---+--------+

关闭广播时的行为

== Physical Plan ==
SortMergeJoin [id#0], [sid#7], LeftAnti
:- *(1) Sort [id#0 ASC NULLS FIRST], false, 0
:  +- Exchange hashpartitioning(id#0, 200)
:     +- LocalTableScan [id#0, name#1]
+- *(2) Sort [sid#7 ASC NULLS FIRST], false, 0
   +- Exchange hashpartitioning(sid#7, 200)
      +- LocalTableScan [sid#7]

打开广播时的行为

== Physical Plan ==
*(1) BroadcastHashJoin [id#0], [sid#7], LeftAnti, BuildRight
:- LocalTableScan [id#0, name#1]
+- BroadcastExchange HashedRelationBroadcastMode(List(cast(input[0, int, false] as bigint)))
   +- LocalTableScan [sid#7]

都没有使用BroadcastNestedLoopJoin，可以跟据具体情况选择

什么样的sql会产生BroadcastNestedLoopJoin
u011624157的专栏
02-28 968
join条件不等值时
【硬刚大数据之面试篇】2021年从零到大数据专家面试篇之SparkSQL篇
微信搜：import_bigdata，大数据领域硬核原创作者
07-28 1695
????欢迎关注博客主页：https://blog.csdn.net/u013411339 ????欢迎点赞 ???? 收藏 ⭐留言 ???? ，欢迎留言交流！ ????本文由【王知无】原创，首发于 CSDN博客！ ????本文首发CSDN论坛，未经过官方和本人允许，严禁转载！ 本文是对《【硬刚大数据之学习路线篇】2021年从零到大数据专家的学习指南(全面升级版)》的面试部分补充。 硬刚大数据系列文章链接： 2021年从零到大数据专家的学习指南(全面升级版) 2021年从零到大数据专家面试篇之H
【Spark的五种Join策略解析】
岸芷汀兰
09-12 3017
Spark将参与Join的两张表抽象为流式遍历表(streamIter)和查找表(buildIter)，通常streamIter为大表，buildIter为小表，我们不用担心哪个表为streamIter，哪个表为buildIter，这个spark会根据join语句自动帮我们完成。对于每条来自streamIter的记录，都要去buildIter中查找匹配的记录，所以buildIter一定要是查找性能较优的数据结构。
Spark中的JOIN机制
Java/Python大数据随笔
07-16 1817
Apache Spark共提供了五种JOIN机制，其中常用的有三种：Shuffle Hash Join、Broadcast Hash Join及Sort Merge Join，它们都基于Hash Join，只不过需要在Hash Join前后进行Shuffle、Broadcast或Sort实际上，Hash Join算法来自于传统数据库，而Shuffle、Broadcast和Sort是大数据（数据仓库）在分布式场景下两者结合的产物。因此，我们也说大数据（数据仓库）是由传统数据库发展而来的。
跳出BroadcastNestedLoopJoin和禁不掉的广播
weixin_47015814的博客
03-19 551
使用方法2，至少让我知道这个BroadcastNestedLoopJoin只能修改sql语句，比如把里面关联的一些逻辑抽取成临时视图。参考以上链接解决了我一直在排查的问题，为什么禁了广播join，作业执行还是走广播join，最后超时报错。
SparkSQL中的三种Join及其具体实现（broadcast join、shuffle hash join和sort merge join）
hellojoy的博客
02-04 4660
https://blog.csdn.net/wlk_328909605/article/details/82933552 1.小表对大表（broadcast join） 将小表的数据分发到每个节点上，供大表使用。executor存储小表的全部数据，一定程度上牺牲了空间，换取shuffle操作大量的耗时，这在SparkSQL中称作Broadcast Join Broadcast Join的条件有以下几个： *被广播的表需要小于 spark.sql.autoBroadcastJoinThresho.
SparkSQL的Join的实现方式
junkmachine的博客
09-16 1497
SparkSql笔记
sparkSQL的三种join（broadcast join、shuffle hash join和sort merge join）以及AE
rong_king_的博客
04-07 8052
每天一个小例子： spark中， 1.left semi join （左半连接）的意思就是， JOIN 子句中右边的表只能在 ON 子句中设置过滤条件，右表中有重复的数据会自动跳过，具体详见：https://blog.csdn.net/happyrocking/article/details/79885071 2. left anti join 含义：left anti join 是 not in/not exists 子查询的一种更高效的实现，相当于not in或者not exists，left anti
BroadcastNestedLoopJoin
03-21
在这种连接方式下，假设存在两张表 `T1` 和 `T2`，其中 `T2` 被选为较小的表进行广播，则具体过程如下： - **广播阶段**: 较小的表 (`T2`) 会被序列化并通过网络传输到参与计算的所有节点[^3]。 - **本地匹配阶段**...
spark大表join小表，广播小表示例
最新发布
03-31
这时候如果countries表很小，可以把它广播出去，每个节点只保留一份副本，大表的数据不需要移动，直接在本地进行join操作。这样应该能提升性能。 那在代码层面怎么实现呢？记得在Spark中可以使用broadcast函数来...
spark5种join策略
u011624157的专栏
05-16 990
因为是否小表走广播是根据spark对元数据的估算得到的，如果join表有很多的filter容易把表估大，造成本可以广播的情况实际没有广播
干货|Spark优化之高性能Range Join
大数据星球-浪尖
12-02 473
作者|张兴超编辑|林颖供稿|ADI Carmel Team本文共3884字，预计阅读时间10分钟导 读Carmel是eBay内部基于Apache Spark打造的一款SQL-on-Had...
【Spark精讲】Spark五种JOIN策略
话数Science
12-16 6803
Spark JOIN详解，Spark五种JOIN策略，Shuffle Hash Join，Broadcast Hash Join，Sort Merge Join，Cartesian Join，Broadcast Nested Loop Join
每个 Spark 工程师都应该知道的五种 Join 策略
过往记忆大数据
09-13 5192
数据分析中将两个数据集进行 Join 操作是很常见的场景。在 Spark 的物理计划（physical plan）阶段，Spark 的 JoinSelection 类会根据 Join h...
Spark优化，高性能Range Join
一个写湿的程序猿
03-02 534
Spark优化，高性能Range Join导读1 背景2 Range Join的定义3 方案设计3.1 基于Range构建的查询方案设计3.1.1 Range Index的创建3.1.2 Range数据的查找3.2 基于Point构建的查询方案设计3.2.1 Range Index的创建3.2.2 Range数据的查找4 性能对比4.1 时间复杂度对比4.2 优化后的SQL查询时间对比4.3 Spark DAG对比4.4 和业界主流的OLAP引擎对比5 实 现6 总 结 导读 Carmel是eBay内部基于
大数据技术架构(组件)33——Spark：Spark SQL--Join Type
sysocc的博客
02-12 801
1.5、如果用户没有指定任何Join Hint，那么就根据Join的策略Broadcast Hash Join ---> Shuffle Hash Join --> Sort Merge Join ---> Cartesian Product Join --> Broadcast Nested Loop Join顺序选择Join策略。当然用户也可以手动选择策。1、Shuffle阶段：对两个表参与Join的keys使用相同的分区算法和分区数进行分区，目的就是为了保障相同的key都分配到相同的分区里面。
spark的广播变量(Broadcast)
zeng6325998的博客
03-26 2456
注明:大部分知识点是从官方文档翻译，少部分是自己测试，或者在实际项目中的总结。 官方文档地址:https://spark.apache.org/docs/latest/rdd-programming-guide.html#shared-variables 原理 通常情况下，spark的变量只为单独的task工作。广播变量的出现，可以在每台服务器保存一个变量而不是在每一个task上保留一份。官方...
SparkSQL 如何选择 join 策略
m0_59236433的博客
11-30 1118
Join 操作是大数据分析领域必不可少的操作，本文将从原理层面介绍 SparkSQL 支持的五大连接策略及其应用场景。SparkSQL 内置了五种连接策略，如下所示。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值