之前的运行数据被清除了,只能再运行一次,对比一下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