Spark 结构化流检查点兼容性答案

【问题标题】：Spark Structured Streaming Checkpoint CompatibilitySpark 结构化流检查点兼容性
【发布时间】：2023-03-10 03:53:01
【问题描述】：

在我必须升级 Spark 库或更改查询的情况下，我是否可以安全地使用 Kafka 和 Spark 结构化流 (SSS) (>=v2.2) 以及 HDFS 上的检查点？即使在这些情况下，我也想无缝地继续使用留下的偏移量。

在网上搜索 SSS (>=2.2) 检查点机制中的兼容性问题时，我发现了不同的答案。也许有人可以减轻这种情况……最好有事实/参考资料或第一人称经验支持？

在 Spark 的编程指南 (current=v2.3) 中，他们只是声称“..应该是与 HDFS 兼容的目录”，但在兼容性方面甚至没有留下任何关于约束的字眼。 https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html
Databricks 至少给出了一些提示，表明这是一个问题。 https://docs.databricks.com/spark/latest/structured-streaming/production.html#recover-after-changes-in-a-streaming-query
Cloudera 博客建议将偏移量存储在 Zookeeper 中，但这实际上是指“旧”的 Spark Streaming 实现。如果这也与结构化流有关，还不清楚。 https://blog.cloudera.com/blog/2017/06/offset-management-for-apache-kafka-with-apache-spark-streaming/
此对话中的一个人声称在这方面不再存在问题......但没有指出事实。 How to get Kafka offsets for structured query for manual and reliable offset management?

非常感谢您的帮助。

【问题讨论】：

【解决方案1】：

当您不需要更改代码时，检查点非常有用，触发和忘记过程是完美的用例。

我阅读了您发布的 Databricks 的帖子，事实是，除非您必须执行这些更改，否则您无法知道需要执行哪些更改。我想知道他们如何预测未来。

关于 Cloudera 上的链接，是的，他们说的是旧程序，但使用结构化流式处理仍然代码更改会使您的检查点无效。

所以，在我看来，如此多的自动化对于“一劳永逸”程序是有好处的。如果这不是您的情况，那么将 Kafka 偏移量保存到其他地方是从上次离开的地方重新开始的好方法；您知道 Kafka 可以包含大量数据并从零重新启动以避免数据丢失或接受从最新偏移量重新启动的想法有时并不总是可以接受的。

请记住：只要有检查点，任何流逻辑更改都将被忽略，因此一旦部署，您就无法更改作业，除非您接受丢弃检查点的想法。通过丢弃检查点，您必须强制作业重新处理整个 Kafka 主题（最早），或者从最后开始（最新）跳过未处理的数据。

很好，不是吗？

【讨论】：

感谢您的意见。我当前的后备解决方案是查找检查点/提交文件夹。有一个文件以 json 结构存储最近的提交，可以直接用作 Spark 的 Kafka 偏移配置的输入。