Не следует ли вам использовать S3 в качестве контрольной точки для задания структурированной потоковой передачи Spark?

Question

Я изучаю свои варианты контрольных точек с помощью Spark Structured Streaming и прочитал , что "возможная согласованность" S3 не идеальна для контрольных точек . Я пытаюсь определить, так ли это? Я сомневаюсь, что задание структурированной потоковой передачи Spark будет записывать в расположение контрольной точки, а затем читать из нее в рамках задания, чтобы определить, с чего продолжить. Разве текущая контрольная точка не будет также сохранена в памяти в контексте задания (что означает, что чтение из S3 не потребуется для определения текущей контрольной точки)?

Я могу указать местоположение на S3 для контрольных точек, но я пытаюсь определить, противоречит ли это передовой практике. Может кто-нибудь пояснить, не оптимально ли использовать S3 в качестве контрольной точки, и если да, то почему?

Answer 1

Я изучал облачную архитектуру Analytics 18 месяцев до go. AWS EC2, AWS EMR, Ноутбуки и классические. Я просмотрел эти записи и поискал в Google изменения.

Ваши первоначальные предположения преобладают, но с одним нюансом. Некоторые указатели:

• Если вы используете S3 отдельно в качестве местоположения контрольной точки, контакт AWS указал, что могут возникнуть проблемы с производительностью и надежностью.

• Для Databricks они заявляют, что dbfs может использоваться в качестве местоположения контрольной точки, что является синонимом S3-backend. Они спроектировали это как часть управляемой службы / среды.

• Quoble https://www.qubole.com/blog/structured-streaming-with-direct-write-checkpointing/ предлагают услугу для контрольной точки S3. Это говорит мне в сочетании с подходом Databricks, что простое использование S3 в качестве местоположения контрольной точки без должного внимания все еще является проблемой и, следовательно, не рекомендуется.