Spark大型电商项目实战-及其改良 比对sparkSQL和纯RDD实现的结果

Posted 2021-02-06 DGUT_FLY

代码存在码云:https://coding.net/u/funcfans/p/sparkProject/git

 

代码主要学习https://blog.csdn.net/u012318074/article/category/6744423/1这里的

发现样例作为正式项目来说效率太低了,为了知识点而知识点.对原代码做了一定优化

第1个项目:用户访问session随机抽取统计

用户数量一般在100(测试环境)10的8次方(生产环境),不管是哪种都比访问数据少的多.一般这种数据量可以装入内存,使用Map一一映射,并广播这个变量,实现map join并防止数据倾斜

某些确定要过滤得数据(本例的访问数据要过滤访问时间和关键词,用户数据要过滤性别和年龄),就在sparkSQL初始化rdd阶段就过滤掉(按原例在访问数据和用户数据join之后才执行filter算子,这中间要过多少无效数据,还有后面的coalesce优化还要占用时间)

无法避免的数据倾斜(本例的所有join都满足map join优化条件,所以要优化的地方都是dintinct和bykey系算子),使用局部聚合的方式可以缓解倾斜

原例为了展示foreachPartition的重要性,故意把数据库的写入部分使用foreach算子进行操作,这个地方使用foreachPartition重写之后,执行效率提高了3倍(去年12月的执行数据,现在不知道咋地开这个项目会java heap space,大概是数据量调太多了)，最后的foreach(Partition)算子是对数据库的I/O操作，量还不小,相比内部的运算来说，这个操作的执行时间太长了。大数据分析最好不要一次性导出大量数据，能在集群里面分析出信息量较少的结果导出最好

原先的性能数据没保存,现在还因为谜之bug的问题(其实就是数据量的问题,只是卡在flatMapToPair执行session随机抽取这个步骤一直没执行完上了)没有执行结果

第3个项目:不同地区的top10商品统计

这里数据处理都发生在集群内，导出的数据量少，可以加大数据量测试。

同样的，这个项目也是为知识点而知识点。所以要亲自实践一下，sparkSQL和纯RDD实现哪个快，顺带考查自己的RDD优化功底。

此处用的均为同一数据源

AreaTop3ProductSpark这个类，是作者的原例

AreaTop3ProductRDD这个类，是本人对业务的分析转换成的纯RDD实现

AreaTop3ProductRDDSpeedUp这个类，是对上一个类的进一步优化，观察优化效果

AreaTop3ProductSql这个类，是本人对业务的分析转换成的纯sparkSQL实现

结果如下：

Job Id	Description	Submitted	Duration	Stages: Succeeded/Total	Tasks (for all stages): Succeeded/Total
4	collect at AreaTop3ProductSql.java:99	2019/01/29 11:19:04	5 s	7/7	883/883 (2 failed)
3	collect at AreaTop3ProductRDDSpeedUp.java:371	2019/01/29 11:19:02	0.8 s	3/3	123/123
2	collect at AreaTop3ProductRDDSpeedUp.java:212	2019/01/29 11:19:02	28 ms	1/1	1/1
1	collect at AreaTop3ProductRDD.java:353	2019/01/29 11:19:01	1 s	7/7	247/247
0	collect at AreaTop3ProductSpark.java:108	2019/01/29 11:18:45	14 s	7/7	724/724 (2 failed)

 (直接复制history server的html代码)

 原例的执行效率最慢，纯SQL只快1.8倍，可见hivecontext中的dataframe和RDD相互转换耗费的时间不短；并且使用了sql的应用都有failed，进入内部可以发现，javaRDD步骤各有1个出现(Too many open files)错误，可见hivecontext需要与本地文件系统交互

纯RDD的执行时间均将近1秒，不过speedUp的优化效果很不稳定，12月的测试发现。某些数据下用了speedUp的地方反而会拖累执行效率

下节重点分析纯RDD的运行过程