Spark结构化流检查点兼容性

Question

在必须升级Spark库或更改查询的情况下，可以安全地在HDFS上使用带有Kafka和Spark结构化流（SSS）（> = v2.2）的检查点吗？即使在这种情况下，我也想无缝地继续处理剩余的偏移量。

在网络中搜索SSS（> = 2.2）检查点机制中的兼容性问题时，我找到了不同的答案。也许有人可以减轻这种情况...在最好的情况下，以事实/参考或第一人称的经验作为后盾？

1. 在Spark的编程指南（当前版本为v2.3）中，他们只是声称“ ..应该是与HDFS兼容的目录”，但甚至没有就兼容性方面的限制一字不漏。 https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html
2. Databricks至少提供了一些暗示，这完全是一个问题。 https://docs.databricks.com/spark/latest/structured-streaming/production.html#recover-after-changes-in-a-streaming-query
3. 一个Cloudera博客建议将偏移量存储在Zookeeper中，但这实际上是指“旧的” Spark Streaming实现。这是否也与结构化流媒体有关还不清楚。 https://blog.cloudera.com/blog/2017/06/offset-management-for-apache-kafka-with-apache-spark-streaming/
4. 谈话中的一个人声称，在这方面已经没有问题了……但是没有指出事实。 如何获取Kafka偏移量以进行结构化查询，以进行手动和可靠的偏移量管理？

非常感谢您的帮助。

Answer 1

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

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

关于 Cloudera 上的链接，是的，他们正在谈论旧的过程，但使用结构化流仍然代码更改会使您的检查点无效。

因此，在我看来，如此多的自动化对于“即发即忘”流程很有好处。如果您不是这种情况，将 Kafka 偏移量保存在其他地方是从上次离开的位置重新启动的好方法；你知道Kafka可以包含大量数据并从零重新启动以避免数据丢失，或者接受从最新偏移量重新启动的想法有时并不总是可以接受的。

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

太棒了，不是吗？