Использование Hadoop для параллельной обработки, а не больших данных

Я управляю небольшой командой разработчиков, и в любой момент времени у нас есть несколько проектов (одноразовых) данных, которые можно было бы считать "Смутно параллельным" - Обычно они включают в себя запуск одиночного script на одном компьютере в течение нескольких дней, классический пример - обработка нескольких тысяч PDF файлов для извлечения некоторого ключевого текста и размещение в CSV файле для последующей вставки в базу данных.

Теперь мы выполняем достаточно таких задач, которые я начал исследовать при разработке простой очереди очередей с использованием RabbitMQ с несколькими запасными серверами (с целью использования Amazon SQS/S3/EC2 для проектов, требующих большего масштабирования)

В поисках примеров других, которые делают это, я постоянно сталкиваюсь с классическим примером Hadoop New York Times:

New York Times использовала 100 экземпляров Amazon EC2 и приложение Hadoop для обработки 4 ТБ необработанных данных TIFF изображения (хранящихся на S3) в 11 миллионов готовых PDF файлов в течение 24 часов при стоимости вычислений около $240 (не включая полосу пропускания)

Что звучит идеально? Поэтому я исследовал Hadoop и Map/Reduce.

Но что я не могу решить, как они это сделали? Или почему они это сделали?

Преобразование TIFF в PDF не является проблемой Map/Reduce? Разве простая работа не была бы лучше?

Другой классический пример Hadoop - "wordcount" из Yahoo Hadoop Tutorial, кажется, идеально подходит для Map/Reduce, и я могу понять, почему это такое мощный инструмент для больших данных.

Я не понимаю, как эти "смущающие параллельные" задачи помещаются в шаблон Map/Reduce?

TL; DR

Это очень концептуальный вопрос, в основном я хочу знать, как бы мне подгонять задачу "обрабатывать несколько тысяч PDF файлов для извлечения некоторого ключевого текста и помещать в файл CSV" в шаблон Map/Reduce?

Если вы знаете какие-либо примеры, которые были бы идеальными, я не прошу вас написать его для меня.

(Примечания: У нас есть код для обработки PDF файлов, я не прошу об этом - это всего лишь пример, это может быть любая задача. Я прошу о том, чтобы эти процессы как в шаблоне Hadoop Map/Reduce - когда нет четких элементов "Карта" или "Уменьшить" для задачи.)

Ура!

Ответ 1

Ваше мышление верно.

Вышеупомянутые примеры, которые вы упомянули, использовали только часть решения, которое предлагает hasoop. Они определенно использовали параллельную вычислительную способность hadoop плюс распределенную файловую систему. Не обязательно, чтобы вам всегда нужен шаг снижения. У вас может не быть взаимозависимости данных между параллельными процессами, которые выполняются. в этом случае вы устраните шаг уменьшения.

Я думаю, ваша проблема также будет вписываться в домен решения hadoop.

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

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

Дело здесь в том, что вам не нужен шаг уменьшения, вы просто используете параллельную вычислительную способность hadoop, плюс вы готовы выполнять свои задания на не очень дорогостоящем оборудовании.

Ответ 2

Мне нужно добавить еще одну вещь: обработка ошибок и повторная попытка. В распределенной среде узкие сбои довольно распространены. Я регулярно запускаю кластер ЭМИ, состоящий из нескольких сотен узлов, в течение 3 - 8 дней и обнаруживаю, что 3 или 4 сбой в течение этого периода очень вероятен. Hadoop JobTracker будет красиво повторно отправлять неудавшиеся задачи (до определенного количества раз) в другой node.