如何理解troubleshooting 错误的持久化方式以及checkpoint的使用

本篇文章为大家展示了如何理解troubleshooting 错误的持久化方式以及checkpoint的使用，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

        来说下CheckPoint，有时候它对故障会产生效果，它最起效果的时候是什么时候呢？如果缓存BlockManager会根据你的缓存策略去把数据存到内存或者磁盘！持久化，大多数时候，都是会正常工作的。但是就怕，有些时候，会出现意外。比如说，缓存在内存中的数据，可能莫名其妙就丢失掉了。Executor进程挂掉了。或者说，存储在磁盘文件中的数据，莫名其妙就没了，文件被误删了。企业虽然没碰到过，但是有可能。

• 出现上述情况的时候，接下来，如果要对这个RDD执行某些操作，可能会发现RDD的某个partition找不到了。对消失的partition重新计算，计算完以后再缓存和使用。有些时候，计算某个RDD，可能是极其耗时的。可能RDD之前有大量的父RDD。那么如果你要重新计算一个partition，可能要重新计算之前所有的父RDD对应的partition。

• 这种情况下，就可以选择对这个RDD进行checkpoint，以防万一。进行checkpoint，就是说，会将RDD的数据，持久化一份到容错的文件系统上（比如hdfs）。在对这个RDD进行计算的时候，如果发现它的缓存数据不见了。优先就是先找一下有没有checkpoint数据（到hdfs上面去找）。如果有的话，就使用checkpoint数据了。不至于说是去重新计算。

• checkpoint，其实就是可以作为是cache的一个备胎。如果cache失效了，checkpoint就可以上来使用了。checkpoint有利有弊，利在于，提高了spark作业的可靠性，一旦发生问题，还是很可靠的，不用重新计算大量的rdd；但是弊在于，进行checkpoint操作的时候，也就是将rdd数据写入hdfs中的时候，还是会消耗性能的。

• checkpoint，用性能换可靠性。先做了缓冲后做了checkpoint，比如到HDFS那就是会从缓存存到HDFS上面进行checkpoint操作！后面我们再对这个RDD进行使用，然后其实它有个组件叫CacheManager，然后CacheManager会到BlockManager上面去找数据，如果有就通过CacheManager拿到数据，如果没有就会从checkpoint的地方去拿数据

checkpoint原理：

1. 在代码中，用SparkContext，设置一个checkpoint目录，可以是一个容错文件系统的目录，比如hdfs；

2. 在代码中，对需要进行checkpoint的rdd，执行RDD.checkpoint()；

3. RDDCheckpointData（spark内部的API），接管你的RDD，会标记为marked for checkpoint，准备进行checkpoint

4. 你的job运行完之后，会调用一个finalRDD.doCheckpoint()方法，会顺着rdd lineage，回溯扫描，发现有标记为待checkpoint的rdd，就会进行二次标记，inProgressCheckpoint，正在接受checkpoint操作

5. job执行完之后，就会启动一个内部的新job，去将标记为inProgressCheckpoint的rdd的数据，都写入hdfs文件中。（备注，如果rdd之前cache过，会直接从缓存中获取数据，写入hdfs中；如果没有cache过，那么就会重新计算一遍这个rdd，再checkpoint）

6. 将checkpoint过的rdd之前的依赖rdd，改成一个CheckpointRDD*，强制改变你的rdd的lineage。后面如果rdd的cache数据获取失败，直接会通过它的上游CheckpointRDD，去容错的文件系统，比如hdfs中，获取checkpoint的数据。

说一下checkpoint的使用

1. SparkContext，设置checkpoint目录

2. 对RDD执行checkpoint操作

上述内容就是如何理解troubleshooting 错误的持久化方式以及checkpoint的使用，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注亿速云行业资讯频道。