性能调优-RDD持久化

性能调优：


RDD持久化


在调优王道之后就要去审视代码要做的！或者要重构代码做的！
这个是在前两步之后就必须要做的事情了！


HDFS
RDD1
RDD2
RDD3 RDD4


当第一次对RDD2执行算子，获取RDD3的时候，就会从RDD1开始计算，就是读取HDFS文件，
然后对RDD1执行算子，获取到RDD2，然后再计算，得到RDD3


默认情况下，多次对一个RDD执行算子，去获取不同的RDD；都会对这个RDD以及之前的父RDD，
全部重新计算一次；读取HDFS->RDD1->RDD2-RDD4
这种情况，是绝对绝对，一定要避免的，一旦出现一个RDD重复计算的情况，就会导致性能急剧降低。
比如，HDFS->RDD1-RDD2的时间是15分钟，那么此时就要走两遍，变成30分钟


第一，RDD架构重构与优化
尽量去复用RDD，差不多的RDD，可以抽取称为一个共同的RDD，供后面的RDD计算时，反复使用。


第二，公共RDD一定要实现持久化
北方吃饺子，现包现煮。你人来了，要点一盘饺子。馅料+饺子皮+水->包好的饺子，对包好的饺子去煮，
煮开了以后，才有你需要的熟的，热腾腾的饺子。
现实生活中，饺子现包现煮，当然是最好的了；但是Spark中，RDD要去“现包现煮”，
那就是一场致命的灾难。
对于要多次计算和使用的公共RDD，一定要进行持久化。
持久化，也就是说，将RDD的数据缓存到内存中/磁盘中，（BlockManager），
以后无论对这个RDD做多少次计算，那么都是直接取这个RDD的持久化的数据，比如从内存中或者磁盘中，
直接提取一份数据。


第三，持久化，是可以进行序列化的
如果正常将数据持久化在内存中，那么可能会导致内存的占用过大，这样的话，也许，会导致OOM内存溢出。
当纯内存无法支撑公共RDD数据完全存放的时候，就优先考虑，使用序列化的方式在纯内存中存储。
将RDD的每个partition的数据，序列化成一个大的字节数组，就一个对象；序列化后，
大大减少内存的空间占用。
序列化的方式，唯一的缺点就是，在获取数据的时候，需要反序列化。
如果序列化纯内存方式，还是导致OOM，内存溢出；就只能考虑磁盘的方式，内存+磁盘的普通方式
（无序列化）。
内存+磁盘，序列化


第四，为了数据的高可靠性，而且内存充足，可以使用双副本机制，进行持久化
持久化的双副本机制，持久化后的一个副本，因为机器宕机了，副本丢了，就还是得重新计算一次；
持久化的每个数据单元，存储一份副本，放在其他节点上面；从而进行容错；一个副本丢了，
不用重新计算，还可以使用另外一份副本。
这种方式，仅仅针对你的内存资源极度充足


actionRDD，就是一个公共RDD
第一，要用ationRDD，获取到一个公共的sessionid为key的PairRDD
第二，actionRDD，用在了session聚合环节里面


sessionid为key的PairRDD，是确定了，在后面要多次使用的
1、与通过筛选的sessionid进行join，获取通过筛选的session的明细数据
2、将这个RDD，直接传入aggregateBySession方法，进行session聚合统计


重构完以后，actionRDD，就只在最开始，使用一次，用来生成以sessionid为key的RDD


重构：sessionid2detailRDD，就是代表了通过筛选的session对应的访问明细数据


持久化，很简单，就是对RDD调用persist()方法，并传入一个持久化级别


如果是persist(StorageLevel.MEMORY_ONLY())，纯内存，无序列化，那么就可以用cache()方法来替代
StorageLevel.MEMORY_ONLY_SER()，第二选择
StorageLevel.MEMORY_AND_DISK()，第三选择
StorageLevel.MEMORY_AND_DISK_SER()，第四选择
StorageLevel.DISK_ONLY()，第五选择


如果内存充足，要使用双副本高可靠机制
选择后缀带_2的策略
StorageLevel.MEMORY_ONLY_2()


sessionid2actionRDD用了两次


filteredSessionid2AggrInfoRDD也用了两次


sessionid2detailRDD用了三次