spark streaming源码分析5 checkpoint

博客地址: http://blog.csdn.net/yueqian_zhu/

这一节介绍checkpoint相关的内容

spark streaming是一个7*24小时工作的实时处理系统，所以必须保证从故障中恢复的能力。由于streaming 实际上是以小batch数据周期性的执行类似spark core中RDD的计算，所以，其worker节点的容错也就天然的继承了。但是，spark core的数据来源一般存在于hdfs中，所以并没有做driver这一层的容错保证，出错时只要重跑就可以了。而spark streaming的数据来源一般为网络、kafka等，在driver异常时，需要有机制保证从哪里继续读取计算，未完成的jobs如何重新计算等，从而保证数据的正确性。那么，这正是通过spark streaming的checkpoint机制来完成的。在spark core部分，每当提交一个job计算完成之后，就会自动调用rdd.doCheckpoint方法将rdd保存起来。streaming底层依赖spark core的计算逻辑，所以在rdd这一层，自然的会将每个最终runjob的RDD做checkpoint。

checkpoint写：

在一个jobset运行完成后，就自动调用doCheckpoint方法，将在这个jobset内所有job都完成rdd这一层级的checkpoint文件都记录在内存中（currentCheckpointFiles），同时将这个batch time的所有信息封装成checkpoint对象(主要包含DStreamGraph，pendingtimes等信息)，并序列化保存到文件中，也就是DStream层的checkpoint。

我们在对DStream作checkpoint的目的就是希望恢复当时的RDD状况，所以根据currentCheckpointFiles就可以知道所有运行完成的job，而根据pendingtimes就可以知道已经生成jobset，但尚未执行或者未全部执行的jobs。这样，当从checkpoint文件中恢复出来后，就可以恢复当时的状况。注意的是，由于pendingtimes记录的是jobset级别的，对于已经执行了jobset中一部分job的情况，就只能保证at-least once逻辑。另外，前面的章节讲到过，在一个jobset结束后，会处理ClearMetaData消息。其中有一项功能就是清理checkpoint数据，清理一些过期的checkpoint文件以及内存信息。

WAL 预写日志

分为driver端和executor端。为了防止receiver接受数据后宕掉，从而有一部分数据因未来得及处理而丢失，可以通过预写日志(WAL)将接收到的数据保存到容错的文件系统中，保证数据的零丢失。同理，我们在接收到数据后会将block的元信息上报driver，用于记录实际接收到的数据的具体位置。在driver的WAL中，也会将这部分信息写入日志中，从而在driver异常重启后，可以从日志中恢复这些信息，保证接收到的数据的可用性。

checkpoint读：

1、ssc的getOrCreate方法，如果是从checkpoint文件中读取的，则反序列化成checkpoint对象，再初始化ssc

2、从DStream这一层的checkpoint中，根据checkpoint files获取generateRdds

3、在初始化ReceivedBlockTracker时，如果开启了WAL，则从日志中读取恢复。再根据pendingtimes中的时间去重新提交jobs

以上如有错误，请反馈给我，谢谢。。。