记一次复杂左连接的优化之路

慢执行分析

create table t3 as
select t_1.lon as lon,
t_1.lat as lat,
t_1.label as label,
t_1.is_core as is_core,
t_2.grid_id as grid_id,
t_2.mid_jd as mid_jd,
t_2.mid_wd as mid_wd,
t_2.zs_jd as zs_jd,
t_2.zs_wd as zs_wd,
t_2.yx_jd as yx_jd,
t_2.yx_wd as yx_wd
from t_1
left join t_2
on t_1.lon >= t_2.zs_jd and t_1.lon <= t_2.yx_jd and t_1.lat >= t_2.yx_wd and t_1.lat <= t_2.zs_wd
分析上述代码，如果t_1表的数量级是100万、t_2的数量级是1000万，那么这个左连接在spark中会有多大的执行规模，如何进行优化

这段代码是一个在Spark中执行的SQL查询，它在两个表t_1和t_2之间执行左连接。连接条件基于纬度（lat）和经度（lon）列的空间约束。

如果t_1有100万行，t_2有1000万行，这个左连接在Spark中可能会有较大的执行规模。以下是一些建议和优化策略：

1. 广播小表（t_2）： 如果较小的表（t_2）可以适应每个Spark执行器的内存，可以使用广播。广播是一种技术，其中较小的表被发送到每个执行器，减少了洗牌的需求。在Spark SQL中，你可以使用BROADCAST提示：

   SELECT /*+ BROADCAST(t_2) */ t_1.lon as lon, ...
   

   但是，是否广播取决于较小表的大小和Spark集群中的可用内存。

2. 分区和桶化： 确保两个表都适当地进行了分区和桶化。这可以帮助减少连接操作期间需要洗牌的数据量。例如，如果连接键的分布是均匀的，这可能导致更有效的连接操作。

3. 优化连接条件：