SparkSQL查询调试及长运行时长问题排查求助

一、先修正SQL语法与优化逻辑 #

• 先修复明显语法错误：你的SQL中a3.month = t1.month是笔误，应该改为t3.month，别名错误可能导致Spark执行错误的扫描逻辑，先修正再测试。
• 优化NOT EXISTS逻辑：第二个NOT EXISTS里用MAX(status)加HAVING的写法冗余，可替换为NOT EXISTS (SELECT 1 FROM table4 t4 WHERE t4.id = t1.id AND t4.year = t1.year AND t4.month = t1.month AND t4.day = t1.day AND t4.status > 3)——只要存在一条status>3的记录就满足排除条件，无需聚合计算，能大幅减少开销。

二、分析Spark执行计划 #

用list_of_id_df.explain(true)替代show(1)查看详细执行计划，重点关注：

• 全表扫描：检查table1/table2/table3/table4是否针对id、year/month/day、product等过滤/关联字段做了分区或索引，无分区/索引会导致全量扫描，这是性能瓶颈的常见原因。
• Shuffle操作：查看是否有大量Exchange（数据 shuffle）操作，shuffle的次数和数据量直接影响执行速度，若shuffle数据量过大，需调整并行度或优化关联逻辑。
• 关联顺序：确认Spark是否选择了最优关联顺序（如小表驱动大表），若大表被作为驱动表，会产生大量无效计算。
• 子查询优化：检查两个NOT EXISTS是否被优化为Left Anti Join，若未优化，可能导致子查询被重复执行，拖累整体速度。

三、检查数据存储与统计信息 #

• 分区裁剪：若表按year/month/day分区，确认查询是否触发了分区裁剪（即只扫描符合条件的分区），未触发的话需检查分区字段的过滤条件是否正确。
• 索引与统计：对高频关联/过滤字段（如id、product、code、status），可给列式存储表（如Parquet）添加Bloom Filter索引；同时执行ANALYZE TABLE [表名] COMPUTE STATISTICS收集表统计信息，让Spark优化器能基于真实数据量选择最优计划。
• 数据量验证：统计各表的行数与数据大小，若table1/table2是超大表，可先过滤t1.product='I'再关联table2，减少关联的数据量。

四、调整Spark运行配置 #

• 并行度调优：修改spark.sql.shuffle.partitions（默认200），数据量大则调大该值，避免单个shuffle分区数据过载；数据量小则调小，减少调度开销。
• 内存配置：检查spark.executor.memory和spark.driver.memory是否足够，内存不足会导致数据溢写到磁盘，性能骤降。
• 开启成本优化器（CBO）：确保spark.sql.cbo.enabled=true，结合之前的表统计信息，让Spark生成更优的执行计划。

五、分步定位瓶颈 #

拆分查询逐步验证，定位具体慢的环节：

1. 单独执行select t1.id from table1 t1 where t1.product='I'，验证table1的过滤性能。
2. 加入table2关联：select t1.id from table1 t1 join table2 t2 on t1.id=t2.cd where t1.product='I'，验证关联步骤的速度。
3. 依次添加两个NOT EXISTS子查询，观察哪一步开始变慢，锁定瓶颈点。

内容的提问来源于stack exchange，提问作者TechNewbie