Коригиране на контролни точки в структуриран стрийминг на искра

Имам проблем с контролни точки в производството, когато 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)

Вече беше зададен въпрос, но засега няма решение.

В папката checkpointing виждам, че партида 29 все още не е ангажирана, така че мога ли да премахна нещо от sources, state и/или offsets на checkpointing, за да предотвратя повреда на spark поради липсващ файл _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
Има ли промяна в това отношение? Забележка Databricks е добре. - person thebluephantom; 18.07.2020