在需要升级spark库或更改查询的情况下，在hdfs上使用kafka和spark structured streaming（sss）（>=v2.2）检查点安全吗？即使在那些情况下，我也希望无缝地继续使用留下的偏移量。
在搜索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-流式查询中的事后更改
一个cloudera博客建议将偏移量存储在zookeeper中，但这实际上是指“旧的”spark流实现。这是否也与结构化流媒体有关，目前尚不清楚。https://blog.cloudera.com/blog/2017/06/offset-management-for-apache-kafka-with-apache-spark-streaming/
在这段对话中，一个家伙声称在这方面已经没有问题了……但没有指出事实。如何获取Kafka偏移量进行结构化查询，实现手工可靠的偏移量管理？
非常感谢您的帮助。
1条答案
按热度按时间dy2hfwbg1#
当您不需要更改代码时，检查点是很好的，启动并忘记过程是完美的用例。
我从你发布的databricks上读到了这篇文章，事实上，你不知道要做什么样的更改，直到你不得不做。我想知道他们如何预测未来。
关于cloudera上的链接，是的，他们谈论的是旧的过程，但是对于结构化流，代码更改仍然会使检查点无效。
所以，在我看来，这么多的自动化是好的火灾和忘记程序。如果这不是你的情况，保存Kafka抵消其他地方是一个很好的方式重新开始从你上次离开的地方；您知道，kafka可以包含大量数据并从零重新启动以避免数据丢失，或者接受从最新偏移量重新启动的想法有时并不总是可以接受的。
记住：只要存在检查点，任何流逻辑更改都将被忽略，因此一旦部署，就不能对作业进行更改，除非您接受放弃检查点的想法。通过丢弃检查点，您必须强制作业重新处理整个kafka主题（最早），或者从末尾开始（最晚），跳过未处理的数据。
太棒了，不是吗？