在必须升级 Spark 库或更改查询时，我可以安全地使用 Kafka 和 Spark 结构化流 (SSS) (>=v2.2) 以及 HDFS 上的检查点吗？即使在这些情况下，我也想无缝地继续留下的偏移量。
在网上搜索 SSS (>=2.2) 检查点机制的兼容性问题时，我发现了不同的答案。也许有人可以缓解这种情况......最好的情况是有事实/引用资料或第一人称经验支持？
- 在 Spark 的编程指南(当前 = 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?
非常感谢您的帮助。
最佳答案
当您不需要更改代码时，检查点非常有用，即发即忘程序是完美的用例。
我读了您发布的 Databricks 帖子，事实是，除非您必须执行这些更改，否则您无法知道需要执行哪些更改。我想知道他们如何预测 future 。
关于 Cloudera 上的链接，是的，他们正在谈论旧的过程，但使用结构化流仍然代码更改会使您的检查点无效。
因此，在我看来，如此多的自动化对于“即发即忘”流程很有好处。 如果您不是这种情况，将 Kafka 偏移量保存在其他地方是从上次离开的位置重新启动的好方法；您知道 Kafka 可以包含大量数据并从零重新启动以避免数据丢失，或者接受从最新偏移量重新启动的想法有时并不总是可以接受的。
记住:只要存在检查点，任何流逻辑更改都将被忽略，因此一旦部署，您就无法对作业进行更改，除非您接受丢弃检查点的想法。 通过丢弃检查点，您必须强制作业重新处理整个 Kafka 主题(最早)，或者从末尾(最新)开始跳过未处理的数据。
这很棒，不是吗？
关于apache-spark - Spark 结构化流检查点兼容性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52987275/