Spark Streaming: checkpointing 小节

以下内容主要来自 http://spark.apache.org/docs/2.1.0/streaming-programming-guide.html#checkpointing 的翻译, 其中有些名词做了保留, 翻译有些粗糙, 有时间的人还是看原官方文档来的清楚明白. 有空的话, 我会自己的一些理解补充到里面. 要想看懂以下内容, 有些基本的名词还是一定要懂的, 比如 job, task, application, transformation 等等到底是什么意思.

---

一个 Streaming application 必须保持 7 天 24 时运转, 因此必须对程序逻辑以外的错误所引发的 failure 具有一定的应对能力. 为了实现这一目的, Spark Streaming 需要有足够的 checkpoint 信息以便于能够从 failure 中进行恢复. 有两种类型的信息能够被 checkpoint:

• Metadata checkpointing (元数据检查点) – 将定义 streaming 计算的信息保存到像 HDFS 一样的容错存储中. 它被用于恢复 streaming application 中运行 driver 的节点的 failure. metadata 包含了:

  • Configruation - 用于创建 streaming application 的配置信息.
  • DStream operations - 定义 streaming application 的 DStream 操作集合.
  • Incomplete batches - 那些作业 (job) 已经在队列中但是尚未完成的 batch.

• Data checkpointing (数据检查点) - 将生成的 RDD 信息保存到可靠存储中. 这在一些涉及在多个 batch 进行组合数据, 并且有状态的转换 (transformation) 操作十分有必要. 在这样的转换中, 所生成的 RDD 依赖于之前的 RDD, 这会导致依赖链会随着时间不断增长. 为了避免这样随之带来无限制的恢复时间 (recovery time) 的增长(恢复时间与依赖链成比例), 一些中间状态的 RDD 就会被定期地 checkpoint 到可靠存储 (比如, HDFS), 以此来割断这种依赖链.

总的来说, metadata checkpointing 主要用于恢复 driver 的 failure, 而当有状态的转换操作时, 即使是一些基础的功能, data 或 RDD checkpointing 也十分必要.

什么时候启用 checkpointing

当应用满足以下任意条件时必须启用 checkpointing:

• 使用了有状态的转换操作 - 无论应用中使用了 updateStateByKey 还是 reduceByKeyAndWindow (带有反函数), 那么必须提供 checkpoint 目录来进行阶段性的 RDD checkpointing.

• 恢复运行应用的 driver 的 failure - metadata checkpoints 被用于恢复进度信息.

由于一些简单的 streaming application 并没有涉及上面的状态转换, 因此可以不启用 checkpointing 进行运行.

如何配置 checkpointing

checkpointing 可以通过在一个容错, 可靠的文件系统 (比如, HDFS, S3 等等) 上设置一个保存信息的目录进行启用. 具体的, streamingContext.checkpoint(checkpointDirectory). 此外, 如果你想要使得应用能够从 driver failure 中恢复, 你需要重写你的 streaming application 来拥有以下的一些行为:

• 当程序 (program) 首次启动时, 它将会创建一个新的 StreamingContext, 部署所有的 stream然后调用 start().
• 当程序 failure 后重启时, 它将会从 checkpoint 目录的 checkpoint 数据中重新创建一个 StreamingContext .

// Function to create and setup a new StreamingContext
// 定义函数创建并部署一个新的 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
// 从 checkpoint 数据中获取或是创建一个新的 StreamingContext
val context = StreamingContext.getOrCreate(checkpointDirectory, functionToCreateContext _)

// Do additional setup on context that needs to be done,
// irrespective of whether it is being started or restarted
context. ...
// 完成 context 一些额外的工作, 与其是否正在被启动或是重新启动无关

// Start the context
// 启动 context
context.start()
context.awaitTermination()

如果 checkpointDirectory 存在, 那么 context 会从 checkpoint 数据中被重新创建. 如果该目录不存在(也就是说, 首次运行时), 那么函数 functionToCreateContext 就会被调用来创建一个新的 context 和部署 DStream. 更多内容可见 RecoverableNetworkWordCount, 该示例将网络数据的 work count 附加到一个文件中.

除了使用 goOrCreate , 还需要保证 driver 进程能够在 failure 时被自动地重启. 这只能通过运行应用的部署底层来完成. 这一点 Deployment 一节中有进一步的讨论.

注意到 RDD 的 checkpointing 会招致将信息保存到可靠存储成本的消耗. 当 RDD 被 checkpoint 时, 这就会使得这些 batch 的处理时间有所增长. 故而需要谨慎设置 checkpoint 的间隔时间. 当 batch size 比较小 (比如 1 秒), 每个 batch 的 checkpointing 可能会大幅减少 operation thoughput. 反之, 如果 checkpointing 频率太低, 那么可能会导致 lineage 和 task size 的增长, 产生一个有害的影响. 对于需要 RDD checkpointing 的状态转换操作, 一个默认的间隔时间是至少 10 秒钟的 batch interval 的一个倍数. 这可以通过 dstream.checkpoint(checkpointInterval) 进行设置. 代表性地, 5-10 的一个 DStream 的滑动区间是设置 checkpoint 间隔时间的一个很好的尝试.