Совместимость с Spark Checkpoint для потоковой передачи

Question

Безопасно ли использовать Kafka и Spark Structured Streaming (SSS) (> = v2.2) с контрольными точками на HDFS в тех случаях, когда мне нужно обновить библиотеку Spark или при изменении запроса?Я бы хотел без проблем продолжить смещение, оставленное позади, даже в этих случаях.

Я нашел разные ответы при поиске в сети проблем совместимости в механизме контрольных точек SSS (> = 2.2).Может быть, кто-то может облегчить ситуацию ... в лучшем случае, подкрепленный фактами / ссылками или опытом от первого лица?

1. В руководстве по программированию Spark (current = 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

Контрольные точки хороши, когда вам не нужно менять код, процедуры запуска и забывания являются идеальными вариантами использования.

Я прочитал сообщение из опубликованных вами блоков данных, правда в том, что вы не можете знать,какие изменения призваны делать, пока вы не должны их делать.Интересно, как они могут предсказать будущее.

Насчет ссылки на Cloudera, да, они говорят о старой процедуре, но с помощью структурированной потоковой передачи все равно изменения кода лишают вас контрольных точек.

Итак, вПо моему мнению, такая большая автоматизация хороша для процедуры Fire and Forget.Если это не ваш случай, сохранение смещения Кафки в другом месте - это хороший способ перезапустить с того места, где вы ушли в прошлый раз;вы знаете, что Kafka может содержать много данных и перезапускаться с нуля, чтобы избежать потери данных или принять идею перезапуска с последнего смещения, иногда это не всегда приемлемо.

Помните: любое изменение логики потока будет игнорироваться какПока есть контрольные точки, поэтому вы не можете вносить изменения в свою работу после развертывания, если вы не согласны с идеей отбросить контрольные точки.Отбрасывая контрольные точки, вы должны заставить задание повторно обработать всю тему Kafka (самое раннее) или начать прямо в конце (самое последнее), пропуская необработанные данные.

Это здорово, не правда ли?