性能调优:
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用了三次
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用了三次