我试图了解检查点的内容和相应的恢复；理解检查点的过程显然是解决问题的自然方法，因此我浏览了以下列表：
我仍然在努力了解检查点末尾磁盘上的内容。
我对Spark Checkpointing的理解：
如果您的DAG确实很长，并且您的Spark集群失败，则检查点可以通过保持中间状态（例如，到HDFS。因此，借助检查点，可以将50个转换的DAG减少为4-5个转换。但这会破坏DAG。
流式检查点
我的Spark Streaming作业的微批处理为5秒。据我了解， JobScheduler 每5秒钟提交一次新的 job ，调用 JobGenerator 生成 RDD DAG从 DStreamGraph 获得新的微批处理，同时 receiver 同时为下一个周期继续收集下一新微批处理的数据。据我了解，如果启用检查点，它将定期保持检查点的“当前状态”。
问题：
这是什么“状态”？这是基本RDD和仅适用于当前微批处理的DAG的运算符/转换状态的组合吗？所以我有以下内容：
"event":"user"作为检查点 T = 12 的结果，磁盘上到底有哪些内容？它会只存储 ubatch 2 的DAG运营商的当前状态吗？
a。如果是，则在恢复期间 T = 100 ，最后可用的检查点位于 T = 12 。已经成功处理的 T = 15 上的 ubatch 3 会发生什么情况。应用程序是否在这里重新处理 ubatch 3 并处理幂等性？如果是，我们是否转到流媒体来源，例如Kafka并倒带偏移量，以便能够从 ubatch 3 开始重播内容？
b。如果否，那么什么确切地进入T = 12的检查点目录？