代码存在码云: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的运行过程