14checkpoint在Spark中的应用及分析

checkpoint在spark中主要有两块应用：一块是在spark core中对RDD做checkpoint，可以切断做checkpoint RDD的依赖关系，将RDD数据保存到可靠存储（如HDFS）以便数据恢复；另外一块是应用在spark streaming中，使用checkpoint用来保存DStreamGraph以及相关配置信息，以便在Driver崩溃重启的时候能够接着之前进度继续进行处理（如之前waiting batch的job会在重启后继续处理）。

一、spark core中checkpoint的应用

首先，要设置checkpoint的目录（一般是hdfs目录），这个目录用来持久化RDD相关的数据（包括每个partition实际数据，以及partitioner（如果有的话））。然后在RDD上调用checkpoint的方法即可。
使用代码：

sc.setCheckpointDir(checkpointDir.toString)
val rdd = sc.makeRDD(1 to 20, numSlices = 1)
rdd.cache()
rdd.checkpoint()

checkpoint的写流程

• RDD中的数据是什么时候写入的？是在rdd调用checkpoint方法时候吗？
  首先看一下RDD中checkpoint方法，可以看到在该方法中是只是新建了一个ReliableRDDCheckpintData的对象，并没有做实际的写入工作。实际触发写入的时机是在runJob生成该RDD后，调用RDD的doCheckpoint方法来做的。
• 在做checkpoint的时候，具体写入了哪些数据到HDFS了？
  在经历调用RDD.doCheckpoint → RDDCheckpintData.checkpoint → ReliableRDDCheckpintData.doCheckpoint → ReliableRDDCheckpintData.writeRDDToCheckpointDirectory后，在writeRDDToCheckpointDirectory方法中可以看到：将作为一个单独的任务（RunJob）将RDD中每个parition的数据依次写入到checkpoint目录（writePartitionToCheckpointFile），此外如果该RDD中的partitioner如果不为空，则也会将该对象序列化后存储到checkpoint目录。所以，在做checkpoint的时候，写入的hdfs中的数据主要包括：RDD中每个parition的实际数据，以及可能的partitioner对象（writePartitionerToCheckpointDir）。
  partitioner 故名思意就是确定每条数据应该发往哪个partition的分区器，最常用的HashPartitioner。
• 在对RDD做完checkpoint以后，对做RDD的本省又做了哪些收尾工作？
  在写完checkpoint数据到hdfs以后，将会调用rdd的markCheckpoined方法，主要斩断该rdd的对上游的依赖，以及将partitions置空等操作。
• 实际过程中，使用RDD做checkpoint的时候需要注意什么问题？
  调用checkpoint，在RDD计算完毕后，会再次通过RunJob将每个partition数据保存到HDFS，这样RDD将会计算两次，所以为了避免此类情况，最好将RDD进行先cache，然后再checkpoint。

checkpoint的读流程

在做完checkpoint后，获取原来RDD的依赖以及partitions数据都将从CheckpointRDD中获取。也就是说获取原来rdd中每个partition数据以及partitioner等对象，都将转移到CheckPointRDD中。

在CheckPointRDD的一个具体实现ReliableRDDCheckpintRDD中的compute方法中可以看到，将会从hdfs的checkpoint目录中恢复之前写入的partition数据。而partitioner对象（如果有）也会从之前写入hdfs的paritioner对象恢复。

总的来说，checkpoint读取过程是比较简单的。

二、spark streaming中checkpoint的应用

在streaming中使用checkpoint主要包含以下两点：设置checkpoint目录，初始化StreamingContext时调用getOrCreate方法，即当checkpoint目录没有数据时，则新建streamingContext实例，并且设置checkpoint目录，否则从checkpoint目录中读取相关配置和数据创建streamingcontext。
要使checkpoint生效，要在创建streamingcontext 时指定checkpoint目录，这样可以从checkpoint目录恢复streamingContext，防止driver端故障，否则不能恢复driver。
使用代码：

// Function to create and setup a new StreamingContext
def functionToCreateContext(): StreamingContext = {
  val ssc = new StreamingContext(...)   // new context
  val lines = ssc.socketTextStream(...) // create DStreams
  ...
  ssc.checkpoint(checkpointDirectory)   // set checkpoint directory
  ssc
}
// Get StreamingContext from checkpoint data or create a new one
val context = StreamingContext.getOrCreate(checkpointDirectory, functionToCreateContext _)

streaming中checkpoint写流程

• streaming中checkpoint是在何时做的？
  在spark streaming中，jobGenerator会定期生成任务（jobGenerator.generateJobs)。在任务生成后将会调用doCheckpoint方法对系统做checkpoint。此外，在当前批次任务结束，清理metadata（jobGenerator.clearMetadata）时，也会调用doCheckpoint方法。
• 在streaming checkpoint过程中，具体都写入了哪些数据到checkpoint目录？
  做checkpoint的主要逻辑基本都在JobGenerator.doCheckpoint方法中。
  在该方法中，首先更新当前时间段需要做checkpoint RDD的相关信息，如在DirectKafkaInputDStream中，将已经生成的RDD信息的时间，topic，partition，offset等相关信息进行更新。
  其次，通过checkpointWriter将Checkpoint对象写入到checkpoint目录中（CheckPoint.write → CheckpointWriteHandle）。至此，我们清楚了，写入到checkpoint目录的数据其实就是Checkpoint对象。
  具体包括相关配置信息，checkpoint目录，DStreamGraph等。对于DStreamGraph，主要包含InputDstream以及outputStream等相关信息，从而我们可以看出定义应用相关的计算函数也被序列化保存到checkpoint目录中了。
• streaming checkpoint都有哪些坑？
  应用定义的计算函数也被序列化到checkpoint目录，当应用代码发生改变时，此时就没法从checkpoint恢复。个人感觉这是checkpoint在生产环境使用中碰到的最大障碍。
  另外，当从checkpoint目录恢复streamingContext时，配置信息啥的也都是从checkpoint读取的（只有很少的一部分配置是reload的，具体见读流程），当重启任务时，新改变的配置就可能不生效，导致很奇怪的问题。
  此外，broadcast变量在checkpoint中使用也受到限制。

streaming中checkpoint读流程

在spark streaming任务从checkpoint恢复streamingContext时，将会触发对之前保存的checkpoint对象的读取动作。在StreamingContext的getOrCreate方法中，通过checkpoint.read方法从checkpoint目录中恢复之前保存的Checkpoint对象。一旦该对象存在，将使用Checkpoint创建streamingContext。于此同时，在StreamingContext中DStreamGraph的恢复借助之前保存的对象，并且调用restoreCheckpointData恢复之前生成而未计算的RDD，从而接着之前的进度进行数据处理。

三、checkpoint总结

对于spark streaming，不适合使用checkpoint。