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

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

纯SQL的时间

对应时间表

Stage Id	Description	Submitted	Duration	Tasks: Succeeded/Total	Input	Output	Shuffle Read	Shuffle Write
24	collect at AreaTop3ProductSql.java:99	2019/01/30 10:26:49	0.6 s	200/200			867.8 KB
23	javaRDD at AreaTop3ProductSql.java:306	2019/01/30 10:26:47	2 s	200/200			891.7 KB	869.4 KB
21	javaRDD at AreaTop3ProductSql.java:306	2019/01/30 10:26:46	1 s	200/200			224.1 KB	733.2 KB
20	javaRDD at AreaTop3ProductSql.java:306	2019/01/30 10:26:46	0.5 s	200/200			406.5 KB	224.3 KB
22	javaRDD at AreaTop3ProductSql.java:306	2019/01/30 10:26:45	0.6 s	41/41				159.9 KB
19	javaRDD at AreaTop3ProductSql.java:306	2019/01/30 10:26:45	0.2 s	1/1				4.0 KB
18	javaRDD at AreaTop3ProductSql.java:306	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

转载于:https://www.cnblogs.com/dgutfly/p/10337433.html