Spark SQL优化：NOT IN子查询优化解决

文章最前： 我是Octopus，这个名字来源于我的中文名--章鱼；我热爱编程、热爱算法、热爱开源。所有源码在我的个人github ；这博客是记录我学习的点点滴滴，如果您对 Python、Java、AI、算法有兴趣，可以关注我的动态，一起学习，共同进步。

 相关文章：

1. LEFT ANTI JOIN的使用

2. Spark SQL优化：NOT IN子查询优化解决

3. hivesql-dayofweek 函数

4. percentile_approx 聚合函数

---

背景

有如下的数据查询场景。

SELECT  a
       ,b
       ,c
       ,d
       ,e
       ,f
FROM xxx.BBBB
WHERE dt = '${zdt.addDay(0).format('yyyy-MM-dd')}' 
AND predict_type  
not IN 
( 
   SELECT 
		distinct a 
   FROM 
   xxx.AAAAA
   WHERE dt = '${zdt.addDay(0).format('yyyy-MM-dd')}' 
)

分析

通过查看SQL语句的执行计划基本就可以判断性能瓶颈所在。

1. | == Physical Plan ==

2. BroadcastNestedLoopJoin BuildRight,

Spark SQL的优化器最终将SQL优化为了一个BroadcastNestedLoopJoin。

实际上就是在对JOIN两侧的数据做笛卡尔积运算。时间复杂度为O()，过滤前的结果集行数达到了万亿级别。

优化方法

尝试将NOT IN子查询改写成了LEFT JOIN形式

SELECT  a.*
FROM
(
	SELECT  a
	       ,b
	       ,c
	       ,d
	       ,e
	       ,f
	FROM xxx.BBBB
	WHERE dt = '${zdt.addDay(0).format('yyyy-MM-dd')}'
) a
LEFT JOIN
(
	SELECT  c
	FROM xxx.AAAA
	WHERE dt = '${zdt.addDay(0).format('yyyy-MM-dd')}' 
) b
ON a.c = b.c 
WHERE b.c is null

执行计划如下:

1. Filter is null(#391L)

2. +- SortMergeJoin

可以看到，JOIN方式变成了SortMergeJoin。

SortMergeJoin的原理是对JOIN两侧的数据排序后在做归并。

不妨假设：

排序的时间复杂度为O(nlogn)。
则SortMergeJoin整体的时间复杂度为O(n + nlogn)，依然是百万级数据量的过滤计算。

在数据库查询优化中，"Broadcast Nested Loop Join" 和 "Sort Merge Join" 是两种不同的关联操作算法。

Broadcast Nested Loop Join:
在这种连接算法中，一张表被广播到其他所有的节点上，然后与每个节点上的本地数据进行嵌套循环连接。这通常适用于一个小表和一个大表的连接，其中小表的数据可以很容易地广播到所有节点上。

优势:
1. 适用于小表连接： 当一个表很小而另一个表很大时，广播小表可以减少网络传输和数据传输开销。
2. 简单性： 实现相对简单，不需要进行大规模数据排序。
3. 内存友好： 不需要大量的内存，因为每次只处理小表的一行。

Sort Merge Join:
这是一种更加通用的连接算法，它不涉及表的广播，而是将连接的列进行排序，然后按照排序结果进行逐对比较，从而执行连接操作。

优势:
1. 适用于大表连接：当两个表的大小都比较大时，Sort Merge Join 可以更好地处理连接操作，因为不需要将整个表广播到各个节点。
2. 高效的顺序访问：由于涉及数据的排序，Sort Merge Join 可以更好地利用磁盘预读，提高磁盘数据访问效率。
3. 稳定性：对于不同数据分布的情况，Sort Merge Join 的性能通常比 Broadcast Nested Loop Join 更稳定。

所以，Broadcast Nested Loop Join 适用于小表和大表之间的连接，而 Sort Merge Join 则更适合连接两个较大的表。但请注意，具体的性能取决于数据分布、硬件配置和数据库管理系统的优化能力。在实际情况中，优化器可能会根据统计信息和其他因素来选择最适合的连接算法。