大数据项目实战之调优思路

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数据
3、之前过滤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，我认为性能的重要程度，远远大于一些代码的规范和设计模式，代码的划分，类的划分；大数据最重要的，就是性能
        主要因为大数据以及大数据项目的特点决定了，大数据的程序和项目的速度，都比较慢,如果不优先考虑性能的话，会导致一个大数据处理程序运行时间长度数个小时，甚至数十个小时,此时，对于用户体验，简直就是一场灾难    
        所以，推荐大数据项目，在开发和代码的架构中，优先考虑性能；其次考虑功能代码的划分、解耦合
        我们如果采用第一种实现方案，那么其实就是代码划分（解耦合、可维护）优先，设计优先
        如果采用第二种方案，那么其实就是性能优先
        讲了这么多，除了技术本身和项目经验以外；非常重要的一点，就是积累了处理各种问题的经验