Спарк Архитектура для обработки небольших двоичных файлов, сохраненных в HDFS

Question

Я не знаю, как построить архитектуру для последующего использования:

У меня есть веб-приложение, в котором пользователи могут загружать файлы (PDF & PPTX) и каталоги, чтобы быть обработанный. После завершения загрузки веб-приложение поместит эти файлы и каталоги в HDFS, а затем отправьте сообщения на kafka с указанием пути к этим файлам.

Spark Application считывает сообщения с потоковой передачи kafka, собирает их на master (driver) и после этого обрабатывает их. Сначала я собираю сообщения, потому что мне нужно переместить код на данные, а не перемещать данные, где получено сообщение. Я понял, что искра назначает задание исполнителю, у которого уже есть файл локально.

У меня проблемы с kafka, потому что я был вынужден собрать их сначала по вышеуказанной причине, и когда вы хотите создать катастрофу для приложения checkpoint, потому что вы пытаетесь ссылаться на SparkContext из широковещательной переменной ", даже если код запускается перед добавлением checkpointing (я использую sparkContext там, потому что мне нужно сохранять данные в ElasticSearch и PostgreSQL. Я не знаю, как именно я могу сделать обновление кода в этих условиях.

Я читал о проблемах с небольшими файлами хаопа, и я понимаю, какие проблемы В этом случае я читал, что HBase - лучшее решение для сохранения небольших файлов, чем просто сохранение в hdfs. Другая проблема в проблемах с небольшими файлами hasoop - это большое количество копий и редукторов, созданных для вычислений, но я не понимаю, там в искру ,

Что такое лучшая архитектура для этого варианта использования? Как выполнять расписание работы? Это кафка для этого? или мне нужно использовать другую услугу, такую ​​как rabbitMQ или что-то еще? Существуют ли какие-либо методы для добавления заданий в запущенное приложение Spark через некоторый REST API? Как наилучшим образом сохранить файлы? Лучше использовать Hbase, потому что у меня небольшие файлы (< 100MB)? Или мне нужно использовать SequenceFile? Я думаю, что SequenceFile не для моего использования, потому что мне нужно перерабатывать некоторые файлы случайным образом.

Какая архитектура лучше всего подходит для этого случая использования?

Спасибо!

Answer 1

Существует не один «лучший» способ построения архитектуры. Вам нужно принимать решения и придерживаться их. Сделайте архитектуру гибкой и развязанной, чтобы вы могли легко заменить компоненты, если это необходимо.

Рассмотрим следующие этапы/слои в вашей архитектуре:

1. ИПС/Приобретение/Транспортировка исходных данных (файлов)
2. обработки данных/преобразования
3. архивных данных

в качестве компонент поиска, я бы использовал Flume. Он гибкий, поддерживает множество источников, каналов (включая Kafka) и раковины. В вашем случае вы можете настроить источник, который контролирует каталог и извлекает вновь полученные файлы.

Для обработки/преобразования данных - это зависит от того, какую задачу вы решаете. Вероятно, вы решили использовать Spark Streaming. Поток струй может быть интегрирован с приемником Flume (http://spark.apache.org/docs/latest/streaming-flume-integration.html) Существуют и другие доступные варианты, например. Apache Storm. Flume прекрасно сочетается с Storm. Некоторые преобразования могут также применяться в Flume.

Для архивирования данных - не храните и не архивируйте файлы непосредственно в Hadoop, если они не превышают несколько сотых мегабайт. Одним из решений было бы разместить их в HBase.

Сделайте свою архитектуру более гибкой. Я бы размещал обработанные файлы во временном местоположении HDFS и имел некоторую работу, регулярно архивируя их в zip, HBase, Hadoop Archive (есть такое животное) или любое другое решение.

Рассмотрите возможность использования Apache NiFi (он же HDF - поток данных Hortonworks). Он использует внутренние очереди, предоставляет множество процессоров. Это может облегчить вашу жизнь и создать рабочий процесс за считанные минуты. Попробуйте. Есть хороший Hortonworks tutorial, который в сочетании с HDP Sandbox, работающим на виртуальной машине/Docker, может довести вас до скорости за очень короткое время (1-2 часа?).