Это не фактический ответ, но он не уместился в комментарии. Кроме того, это не исправление, просто обойти.
Spark также удерживает смещения и проверяет целостность при использовании сообщений. Редко случается, что состояние смещения, поддерживаемое в Spark Streaming API, не совпадает с тем, что имеет Kafka. Вы можете проверить целостность смещений:
kafka-simple-consumer-shell --broker-list BROKER:9092 --clientId GROUP_ID --offset 752000 --print-offsets --max-messages 1000 --topic TOPIC | grep offset
Здесь 752000 - закрытие смещения, но перед неудачным вы видите исключение.
Вы можете перебрать вывод и посмотреть, в порядке ли смещения в Кафке.
Однако в нашем случае смещения в Кафке были просто хорошими. У нас был сбой в Кафке, и нам пришлось восстанавливать, восстанавливая журналы. Таким образом, подход, который мы использовали, заключался в том, чтобы просто пропустить смещения до точки, когда состояние Spark Streaming совпадает с Kafka.
Для этого мы использовали инструмент kt как
kt group -brokers BROKER:9092 -topic TOPIC -group GROUP_ID -partitions 113 -reset 753000
Здесь в разделе 113 есть проблема смещения (вы можете найти его из исключения), а 753000 - это возможное смещение, которое, как вы догадываетесь, должно быть в дальнейшем. Иногда вам нужно повторить процесс и перезапустить работу, чтобы прийти к выводу, что все в порядке.
Этот процесс полностью экспериментальный, потому что в сообщении не указано, какое смещение отсутствует. Следовательно, исходя из вашего требования, сколько данных потерять, все в порядке, вы можете выбрать число до или после смещения, указанного в журнале. Например, если в сообщении журнала напечатано смещение 752900, вы можете пропустить ошибку, установив ее на 752800 (ошибочное смещение раньше) или установить более раннюю, например 752950. В последнем случае пропускается 50 сообщений.