2

我正在尝试了解检查点的内容和相应的恢复；理解检查点的过程显然是自然的方式，所以我浏览了以下列表：

我仍然在努力理解检查点末尾的磁盘上发生了什么。

我对 Spark 检查点的理解：

如果你有很长的 DAG 并且你的 spark 集群失败了，检查点通过将中间状态持久化到 HDFS 来帮助。因此，在检查点的帮助下，可以将 50 个转换的 DAG 减少到 4-5 个转换。它虽然打破了 DAG。

流式传输中的检查点

我的 Spark Streaming 作业有一个 5 秒的微批处理。据我了解，JobScheduler每 5 秒提交一个新作业，它调用JobGenerator从DStreamGraph为新的微批次生成RDD DAG ，同时接收器继续为下一个新的微批次收集数据循环。据我了解，如果我启用检查点，它将定期保持检查点“当前状态”。

问题：

  1. 这个“状态”是什么？这是仅针对当前微批次的基本 RDD 和 DAG 的运算符/转换状态的组合吗？所以我有以下内容：

    ubatch 0 at T=0 ----> SUCCESS
ubatch 1 at T=5 ----> SUCCESS
ubatch 2 at T=10 ---> SUCCESS
--------------------> Checkpointing kicks in now at T=12
ubatch 3 at T=15 ---> SUCCESS
ubatch 4 at T=20
--------------------> Spark Cluster DOWN at T=23 => ubatch 4 FAILS!!!
...
--------------------> Spark Cluster is restarted at *T=100*

    由于T=12的检查点，磁盘上的具体内容是什么？它会只存储ubatch 2的 DAG 运算符的当前状态吗？

    一个。如果是，则在T=100恢复期间，最后一个可用检查点位于T=12。已成功处理的T=15的ubatch 3会发生什么情况。应用程序是否在此处重新处理ubatch 3并处理幂等性？如果是，我们是否会转到流媒体源（例如 Kafka）并倒回偏移量以便能够重播从ubatch 3开始的内容？

    湾。如果不是，那么在 T=12 时检查点目录中究竟有什么内容？

4

0 回答 0