Потоковое решение на основе S3 с использованием Apache Spark или Flink - PullRequest
Новая
       56

Потоковое решение на основе S3 с использованием Apache Spark или Flink

0 голосов
/ 29 июня 2019

У нас есть пакетные конвейеры, записывающие файлы (в основном csv) в корзину s3.Некоторые из этих конвейеров пишут поминутно, а некоторые - каждые 5 минут.В настоящее время у нас есть пакетное приложение, которое запускается каждый час для обработки этих файлов.

Бизнес хочет, чтобы данные были доступны каждые 5 минут.Вместо того, чтобы запускать пакетные задания каждые 5 минут, мы решили использовать Apache Spark структурированной потоковой передачи и обрабатывать данные в режиме реального времени.Мой вопрос заключается в том, насколько легко / сложно реализовать это решение?

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

Если вы считаете, что существует лучшая архитектура / шаблон для этой проблемы, пожалуйста, укажите мне правильное направление.

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

1 Ответ

0 голосов
/ 30 июня 2019

Я нашел способ сделать это, не самый эффективный способ. Так как мы уже производили решения на основе Kafka, мы могли перенести событие в Kafka, используя потоки s3 и лямбду. Событие будет содержать только метаданные, такие как расположение и размер файла.

Это сделает программу spark немного более сложной, так как файл будет прочитан и обработан внутри исполнителя, который фактически не использует распределенную обработку. Или же, прочитайте в executor и верните данные обратно драйверу, чтобы использовать распределенную обработку искры. Это потребует, чтобы приложение spark планировалось намного лучше с точки зрения памяти, поскольку размеры входного файла сильно меняются.

https://databricks.com/blog/2019/05/10/how-tilting-point-does-streaming-ingestion-into-delta-lake.html

...