【Spark调优】：RDD持久化策略

【场景】

　　Spark对RDD执行一系列算子操作时，都会重新从头到尾计算一遍。如果中间结果RDD后续需要被被调用多次，可以显式调用 cache()和 persist()，以告知 Spark，临时保存之前的计算结果，这样后续多个RDD使用时，就不用重新计算该临时结果了，从而节约计算资源。

　　要注意cache和persist是惰性的，需要action算子来触发。

【Spark的持久化级别】

【选择一种最合适的持久化策略】

默认情况下，性能最高的当然是MEMORY_ONLY，但前提是内存必须足够足够大，可以绰绰有余地存放下整个RDD的所有数据。因为不进行序列化与反序列化操作，就避免了这部分的性能开销；对这个RDD的后续算子操作，都是基于纯内存中的数据的操作，不需要从磁盘文件中读取数据，性能也很高；而且不需要复制一份数据副本，并远程传送到其他节点上。但是这里必须要注意的是，在实际的生产环境中，恐怕能够直接用这种策略的场景还是有限的，如果RDD中数据比较多时（比如几十亿），直接用这种持久化级别，会导致JVM的OOM内存溢出异常。
如果使用MEMORY_ONLY级别时发生了内存溢出，那么建议尝试使用MEMORY_ONLY_SER级别。该级别会将RDD数据序列化后再保存在内存中，此时每个partition仅仅是一个字节数组而已，大大减少了对象数量，并降低了内存占用。这种级别比MEMORY_ONLY多出来的性能开销，主要就是序列化与反序列化的开销。但是后续算子可以基于纯内存进行操作，因此性能总体还是比较高的。此外，可能发生的问题同上，如果RDD中的数据量过多的话，还是可能会导致OOM内存溢出的异常。
如果纯内存的级别都无法使用，那么建议使用MEMORY_AND_DISK_SER策略，而不是MEMORY_AND_DISK策略。因为既然到了这一步，就说明RDD的数据量很大，内存无法完全放下。序列化后的数据比较少，可以节省内存和磁盘的空间开销。同时该策略会优先尽量尝试将数据缓存在内存中，内存缓存不下才会写入磁盘。
通常不建议使用DISK_ONLY和后缀为_2的级别：因为完全基于磁盘文件进行数据的读写，会导致性能急剧降低，有时还不如重新计算一次所有RDD。后缀为_2的级别，必须将所有数据都复制一份副本，并发送到其他节点上，数据复制以及网络传输会导致较大的性能开销，除非是要求作业的高可用性，否则不建议使用。

持久化的数据在Spark UI的Storage中可以看到，当然，前提是在rdd.unpersist(true)之前

【checkpoint】

　　1. checkpoint也是数据持久化，且持久化到磁盘，但与checkpoint与rdd.persist(StorageLevel.DISK_ONLY) 有区别：

rdd.persist(StorageLevel.DISK_ONLY)

　　可以将 RDD 的 partition 持久化到磁盘，但该 partition 由 blockManager 管理。一旦 driver program 执行结束，也就是 executor 所在进程 CoarseGrainedExecutorBackend stop，blockManager 也会 stop，被 cache 到磁盘上的 RDD 也会被清空(整个 blockManager 使用的 local 文件夹被删除)，无法被其他 dirver program 使用。

checkpoint

　　将 RDD 持久化到 HDFS 或本地文件夹，如果不被手动 remove 掉，数据将会一直存在，也就是说可以被另外一个 driver program 使用，而 cached RDD 不能被其他 dirver program 使用。

2.cache 机制是每计算出一个要 cache 的 partition 就直接将其 cache 到内存了。但 checkpoint 没有使用这种第一次计算得到就存储的方法，而是等到 job 结束后另外启动专门的 job 去完成 checkpoint 。也就是说需要 checkpoint 的 RDD 会被计算两次。因此，生产上使用 rdd.checkpoint() 的时候，建议加上 rdd.cache()，这样第二次运行的 job 就不用再去计算该 rdd 了，直接读取 cache 写磁盘。

　　代码实践：https://github.com/wwcom614/Spark