Spark大型电商项目实战-及其改良(3) 分析sparkSQL语句的性能影响

时间:2021-06-07 00:47:16

之前的运行数据被清除了,只能再运行一次,对比一下sparkSQL语句的影响

纯SQL的时间

Spark大型电商项目实战-及其改良(3) 分析sparkSQL语句的性能影响

对应时间表

Stage Id Description Submitted Duration Tasks: Succeeded/Total Input Output Shuffle Read Shuffle Write
24 2019/01/30 10:26:49 0.6 s
200/200
 
 
    867.8 KB  
23 2019/01/30 10:26:47 2 s
200/200
 
 
    891.7 KB 869.4 KB
21 2019/01/30 10:26:46 1 s
200/200
 
 
    224.1 KB 733.2 KB
20 2019/01/30 10:26:46 0.5 s
200/200
 
 
    406.5 KB 224.3 KB
22 2019/01/30 10:26:45 0.6 s
41/41
 
 
      159.9 KB
19 2019/01/30 10:26:45 0.2 s
1/1
 
 
      4.0 KB
18 2019/01/30 10:26:45 0.8 s
41/41 (1 failed)
 
 
      402.6 KB

 以码云的com.ibeifeng.sparkproject.spark.product.AreaTop3ProductSql代码为参考,根据数据量和执行先后可大概发现算子和sql语句的对应关系

这里可以看到,代码只有5次sparksql执行,但是对应算子却有6个

从上节对AreaTop3ProductRDD的分析可以看到,sparkSQL也是以map-reduce作为一次计算的单位

id 22对应161行的createDataFrame,因为商品信息是在倒数第2次dataframe操作时才被join,并且此算子运行结束与否不影响id 20的运行

id 18对应189行的sql操作(第1阶段,reduce join之前要对此表map)

id 19对应128行的load操作(为什么18和19是这种顺序,仔细看时间长度就知道,城市数据和session访问数据不在同一数量级)

id 20对应189行的sql操作(第2阶段,reduce join之后还要map一次)

id 21对应214行的sql操作

id 24对应304行的sql操作(这里有些想不通,对应的sql语句要先group再select,那样应该先reduce再map,前面的sql操作也有join,难道说是因为join的表太小被map join了?)

与未深度优化的RDD程序相比,sparkSQL的运行效率低很多,并且还容易爆too many files错误

那么为什么sparkSQL还能被这么广泛使用呢?emmmm