Предотвращение повторной обработки данных во время обновлений приложения Spark Structured Streaming
Я использую структурированный поток с Spark 2.2. Мы используем Kafka в качестве нашего источника и используем контрольные точки для восстановления после сбоев, и e2e гарантирует только один раз. Я хотел бы получить дополнительную информацию о том, как обрабатывать обновления приложения, когда происходит изменение операций с состоянием и / или схемы вывода.
Как предполагают некоторые источники, я могу запустить обновленное приложение параллельно со старым приложением, пока оно не догонит старое приложение с точки зрения данных, а затем убить старое. Но тогда новое приложение должно будет перечитать / обработать все данные в Kafka, что может занять много времени.
Я хочу избежать повторной обработки данных в недавно развернутом обновленном приложении.
Один из способов, который я могу придумать, состоит в том, чтобы приложение продолжало записывать смещения во что-то помимо каталога контрольных точек, например, в zookeeper/hdfs, И тогда, при обновлении приложения, я командую Кафкой readstream() начать чтение со смещений, сохраненных в этом новом месте (zookeeper/hdfs) - поскольку обновленное приложение не может читать из каталога контрольных точек, который теперь считается несовместимым.
Итак, пара вопросов:
- Является ли вышеуказанное решение допустимым?
- Если да, как я могу автоматизировать обнаружение того, перезапускается ли приложение из-за сбоя / обслуживания или из-за изменений кода в операциях с состоянием и / или выходной схеме?
Любое руководство, пример или источник информации приветствуется.