慢执行分析
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中可能会有较大的执行规模。以下是一些建议和优化策略:
-
广播小表(
t_2
): 如果较小的表(t_2
)可以适应每个Spark执行器的内存,可以使用广播。广播是一种技术,其中较小的表被发送到每个执行器,减少了洗牌的需求。在Spark SQL中,你可以使用BROADCAST
提示:SELECT /*+ BROADCAST(t_2) */ t_1.lon as lon, ...
但是,是否广播取决于较小表的大小和Spark集群中的可用内存。
-
分区和桶化: 确保两个表都适当地进行了分区和桶化。这可以帮助减少连接操作期间需要洗牌的数据量。例如,如果连接键的分布是均匀的,这可能导致更有效的连接操作。
-
优化连接条件: