Исправление контрольных точек в структурированной потоковой передаче Spark

У меня проблема с контрольными точками в рабочей среде, когда spark не может найти файл в папке _spark_metadata

18/05/04 16:59:55 INFO FileStreamSinkLog: Set the compact interval to 10 [defaultCompactInterval: 10]
18/05/04 16:59:55 INFO DelegatingS3FileSystem: Getting file status for 's3u://data-bucket-prod/data/internal/_spark_metadata/19.compact'
18/05/04 16:59:55 ERROR FileFormatWriter: Aborting job null.
java.lang.IllegalStateException: s3u://data-bucket-prod/data/internal/_spark_metadata/19.compact doesn't exist when compacting batch 29 (compactInterval: 10)

Уже был задан вопрос но решения пока нет.

В папке с контрольными точками я вижу, что пакет 29 еще не зафиксирован, поэтому могу ли я удалить что-то из контрольных точек sources, state и/или offsets, чтобы предотвратить сбой искры из-за отсутствия файла _spark_metadata/19.compact?


apache-spark spark-structured-streaming
person Yuriy Bondaruk    schedule 04.05.2018    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Проблема в том, что вы храните свои контрольные точки в S3. Контрольные точки в S3 не на 100% надежны. Чтобы узнать точную причину, по которой S3 ненадежен, прочитайте эта статья.

Решение 1. Используйте HDFS для хранения контрольных точек

Решение 2. Используйте EFS, если вы хотите использовать Amazon Web Services. В приведенной выше статье описаны все шаги подробно о настройке EFS.

Решение 3. Используйте NFS

person Harshit Sharma    schedule 13.06.2018
comment
Спасибо за ссылку на запись в блоге! Однако мы решили перейти на AWS Glue и вместо этого использовать их механизм закладок. - person Yuriy Bondaruk; 14.06.2018
comment
Я не могу отметить это как правильный ответ, так как вопрос касается исправления существующей контрольной точки, а ответ больше о причине проблемы и альтернативных решениях. В любом случае, это полезно - person Yuriy Bondaruk; 15.06.2018
comment
Исправление существующей структуры контрольных точек требует изменения поведения AWS S3. В настоящее время Spark работает с семантикой чтения после записи. Итак, Spark сначала записывает все данные во временную директорию и только после завершения пытается перечислить директорию, в которую пишется, убедившись, что папка существует, и только потом переименовывает директорию контрольной точки в ее настоящее имя. Перечисление каталога после операции PUT в S3 в конечном итоге соответствует документации S3 и может быть причиной спорадических сбоев, которые привели к полному сбою задачи контрольной точки. - person Harshit Sharma; 15.06.2018
comment
Несоответствие приводило к проблеме с контрольными точками, и мое приложение всегда давало сбой после запуска. Было два варианта: 1. Исправить файлы контрольных точек, чтобы исключить последний пакет, вызвавший сбой, или 2. Выяснить, какие файлы уже были обработаны, но все еще существуют в исходной папке, и удалить их, а затем удалить всю папку контрольных точек. После некоторых экспериментов с удалением информации о последнем пакете из файлов контрольных точек я решил пойти по второму пути. - person Yuriy Bondaruk; 15.06.2018
comment
Существующая контрольная точка не исправлена. Следуйте issues.apache.org/jira/browse/SPARK-18512, чтобы последние обновления. До тех пор люди должны использовать HDFS в качестве приемника и места для хранения контрольных точек, а затем в конечном итоге копировать данные в S3 из HDFS. - person Harshit Sharma; 10.10.2018
comment
Databricks может надежно установить контрольную точку на s3, databricks.com /blog/2017/05/31/ если вы не хотите использовать службы *FS - person c. fish; 24.09.2019
comment
Произошли ли какие-либо изменения в этом отношении? Примечание. Блоки данных в порядке. - person thebluephantom; 18.07.2020