Spark SQL优化：NOT IN子查询优化解决
背景
有如下的数据查询场景。
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.AAAAAWHERE dt = '${zdt.addDay(0).format('yyyy-MM-dd')}'
)分析
通过查看SQL语句的执行计划基本就可以判断性能瓶颈所在。
| == Physical Plan ==
BroadcastNestedLoopJoin BuildRight,
Spark SQL的优化器最终将SQL优化为了一个BroadcastNestedLoopJoin。
实际上就是在对JOIN两侧的数据做笛卡尔积运算。时间复杂度为O()，过滤前的结果集行数达到了万亿级别。
优化方法
尝试将NOT IN子查询改写成了LEFT JOIN形式
SELECT a.*
FROM
(SELECT a,b,c,d,e,fFROM xxx.BBBBWHERE dt = '${zdt.addDay(0).format('yyyy-MM-dd')}'
) a
LEFT JOIN
(SELECT cFROM xxx.AAAAWHERE dt = '${zdt.addDay(0).format('yyyy-MM-dd')}'
) b
ON a.c = b.c
WHERE b.c is null执行计划如下:
Filter is null(#391L)
+- 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 则更适合连接两个较大的表。但请注意，具体的性能取决于数据分布、硬件配置和数据库管理系统的优化能力。在实际情况中，优化器可能会根据统计信息和其他因素来选择最适合的连接算法。