session聚合统计

session聚合统计（统计出访问时长和访问步长，各个区间的session数量占总session数量的比例）
如果不进行重构，直接来实现，思路：
1、actionRDD，映射成<sessionid,Row>的格式
2、按sessionid聚合，计算出每个session的访问时长和访问步长，生成一个新的RDD
3、遍历新生成的RDD，将每个session的访问时长和访问步长，去更新自定义Accumulator中的对应的值
4、使用自定义Accumulator中的统计值，去计算各个区间的比例
5、将最后计算出来的结果，写入MySQL对应的表中

普通实现思路的问题：
1、为什么还要用actionRDD，去映射？其实我们之前在session聚合的时候，映射已经做过了。多此一举
2、是不是一定要，为了session的聚合这个功能，单独去遍历一遍session？其实没有必要，已经有session数据
之前过滤session的时候，其实，就相当于，是在遍历session，那么这里就没有必要再过滤一遍了

重构实现思路：
1、不要去生成任何新的RDD（处理上亿的数据）
2、不要去单独遍历一遍session的数据（处理上千万的数据）
3、可以在进行session聚合的时候，就直接计算出来每个session的访问时长和访问步长
4、在进行过滤的时候，本来就要遍历所有的聚合session信息，此时，就可以在某个session通过筛选条件后
将其访问时长和访问步长，累加到自定义的Accumulator上面去
5、就是两种截然不同的思考方式，和实现方式，在面对上亿，上千万数据的时候，甚至可以节省时间长达半个小时，或者数个小时

开发Spark大型复杂项目的一些经验准则：
1、尽量少生成RDD
2、尽量少对RDD进行算子操作，如果有可能，尽量在一个算子里面，实现多个需要做的功能
3、尽量少对RDD进行shuffle算子操作，比如groupByKey、reduceByKey、sortByKey（map、mapToPair）
shuffle操作，会导致大量的磁盘读写，严重降低性能
有shuffle的算子，和没有shuffle的算子，甚至性能，会达到几十分钟，甚至数个小时的差别
有shfufle的算子，很容易导致数据倾斜，一旦数据倾斜，简直就是性能杀手（完整的解决方案）
4、无论做什么功能，性能第一
在传统的J2EE或者.NET后者PHP，软件/系统/网站开发中，我认为是架构和可维护性，可扩展性的重要 程度，远远高于了性能，大量的分布式的架构，设计模式，代码的划分，类的划分（高并发网站除外）
大数据中，比如MapReduce、Hive、Spark、Storm，我认为性能的重要程度，远远大于一些代码的规范，和设计模式，代码的划分，类的划分；大数据，大数据，最重要的，就是性能主要就是因为大数据以及大数据项目的特点，决定了，大数据的程序和项目的速度，都比较慢