码迷,mamicode.com
首页 > 数据库 > 详细

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

时间:2019-01-29 18:14:01      阅读:388      评论:0      收藏:0      [点我收藏+]

标签:中间   products   app   table   存在   file   each   osi   server   

代码存在码云: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 IdDescriptionSubmittedDurationStages: Succeeded/TotalTasks (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的运行过程

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

标签:中间   products   app   table   存在   file   each   osi   server   

原文地址:https://www.cnblogs.com/dgutfly/p/10334118.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!