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. 在这次对话中，有个人声称在这方面已经没有问题了……但是却没有指出事实。 How to get Kafka offsets for structured query for manual and reliable offset management?

我们非常感谢您的帮助。

Answer 1

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

我从您发布的Databricks中阅读了该帖子，事实是，您必须要做这些，才能知道需要进行哪种更改。我想知道他们如何预测未来。

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

因此，我认为，对于Fire and Forget程序而言，太多的自动化是有益的。 如果不是这种情况，则将Kafka偏移量保存在其他位置是从上次离开的位置重新开始的好方法；您知道，Kafka可以包含大量数据并从零开始重新启动以避免数据丢失，或者接受从最新偏移量重新启动的想法有时并不总是可以接受的。

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

太好了，不是吗？