之前的运行数据被清除了,只能再运行一次,对比一下sparkSQL语句的影响
纯SQL的时间
对应时间表
| 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