利用临时表优化spark sql案例

一个实际的案例，sql处理逻辑很复杂，跑不动，只摘取关键逻辑的代码进行分析。

优化前

sql精简后关键部分

关键逻辑：从三个表取数据，然后分别inner join

数据特征：临时表1有16亿+，临时表2有4亿+，临时表3只有200+。

yarn资源管理页面分析

只有一个job，1000多个task，一直非常慢，跑到最后两个task卡住了 。

进入job看看

从截图分析步骤

stage0： 生成4亿的临时表2数据

stage1： 生成16亿的临时表1数据

stage2：对临时表1、2进行第一次shuffle

stage3：生成200+的临时表3数据

stage4：进行第二shuffle

stage5：结果处理

任务卡在stage4，又是shuffle过程，其实stage3生成的数据区区只有200条。

优化思路：临时表3只有200多条数据，虽然非常小，但也利用广播机制，跟大量的临时结果数据join时会走shuffle。如果对stage3生成的临时数据落地到中间表，利用广播机制(默认广播最大不超过10M，可以根据实际修改)，第二次reduce端shuffle改成map端shuffle。

优化后

观察任务运行情况

看看job3执行情况

从DAG图可以看出，前面的第二次shuffle已经没有了。

结果对比：优化前2个小时还没有跑出来，优化后，1个小时左右就over了。