Уточнение прецедентов для Hadoop против RabbitMQ + Celery

Я знаю, что к этому есть похожие вопросы, такие как:

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

Итак, я пользователь python, который хочет создавать программы, которые либо/оба:

  • Слишком большие для
  • Слишком долго для

делать на одной машине и обрабатывать их на нескольких машинах. Я знаком с пакетом многопроцессорности (single-machine) в python, и теперь я пишу код стиля mapreduce. Я знаю, что моя функция, например, легко распараллеливается.

Обращаясь к моим обычным умным консультантам CS, я сформулировал свой вопрос как:

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

В соответствии с этим разрывом моего прецедента, я думаю, что я мог бы в равной степени использовать Hadoop или набор работников Celery + RabbitMQ broker. Однако, когда я прошу совета у мудрецов, они реагируют на меня так, как будто я совершенно сумасшедший, чтобы взглянуть на Hadoop и Celery как на сопоставимые решения. Я довольно много читал о Hadoop, а также о Celery. Я думаю, что у меня довольно хорошее понимание того, что оба делают --- то, что я, похоже, не понимаю:

  • Почему они считаются такими раздельными, настолько разными?
  • Учитывая, что они, похоже, воспринимаются как совершенно разные технологии - каким образом? Каковы варианты использования, которые отличают один от другого или лучше для другого?
  • Какие проблемы могут быть решены с обеих сторон, и в каких областях было бы особенно глупо использовать один или другой для?
  • Существуют ли, возможно, лучшие, более простые способы достижения мультипроцессорности, такие как Pool.map() - функциональность для нескольких машин? Представьте себе, что моя проблема не ограничена хранением, а ЦП и ОЗУ, необходимыми для расчета, поэтому нет необходимости иметь слишком мало места для хранения результатов, возвращаемых рабочими. (т.е. я делаю что-то вроде моделирования, где мне нужно генерировать много вещей на небольших машинах, засеянных значением из базы данных, но они уменьшаются до того, как они вернутся к исходной машине/базе данных.)

Я понимаю, что Hadoop - это большой стандарт данных, но Сельдерей также выглядит хорошо поддержанным; Я ценю, что это не java (потоковый API-интерфейс python для использования для хаопа выглядел неудобным для меня), поэтому я был бы склонен использовать параметр Celery.

Ответы

Ответ 1

  • Они одинаковы в том, что оба могут решить проблему, которую вы описываете (map-reduce). Они отличаются тем, что Hadoop полностью построен для решения только того, что usecase и Celey/RabbitMQ построена для облегчения выполнения Задачи на разных узлах с использованием передачи сообщений. Сельдерей также поддерживает различные применения.

  • Hadoop решает проблему уменьшения карты, имея большую и специальную файловую систему, из которой картограф берет свои данные, отправляет ее в кучу узлов карты и сводит ее к этой файловой системе. Это имеет то преимущество, что это действительно быстро. Недостатком является то, что он работает только с текстовым вводом данных, Python на самом деле не поддерживается и что если вы не можете делать (слегка) разные операции. Сельдерей - это исполнитель заданий на основе сообщений. В нем вы определяете задачи и группируете их вместе в рабочем процессе (который может быть map-reduce рабочим процессом). Его преимущества заключаются в том, что он основан на python, что вы можете сшить задачи вместе в пользовательском рабочем процессе. Недостатком является то, что он полагается на единый брокер брокер/результат и время его установки.

  • Итак, если у вас есть несколько лог файлов на уровне Gb и вы не хотите писать на Java и иметь запасные серверы, которые используются исключительно для запуска Hadoop, используйте это. Если вам нужна гибкость при работе с рабочими задачами, используйте Celery. Или.....

  • Да! Существует новый проект от одной из компаний, которые помогли создать протокол обмена сообщениями AMQP, который используется RabbitMQ (и другими). Он называется ZeroMQ, и он принимает распределенные сообщения/выполнение на следующий уровень, странно снижая уровень абстракции по сравнению с Celery. Он определяет сокеты, которые вы можете связать друг с другом различными способами для создания каналов обмена сообщениями между узлами. Все, что вы хотите делать с этими сообщениями, зависит от вас, чтобы писать. Хотя это может звучать так: "что хорошего - тонкая обертка вокруг сокета", на самом деле он находится на правильном уровне абстракции. Прямо сейчас в нашей компании мы разыгрываем все наши сообщения о сельдере и перестраиваем их с помощью ZeroMQ. Мы обнаружили, что сельдерей слишком упрям, о том, как должны выполняться задачи и что настройка/конфигурация в целом - это боль. Также, что брокер в середине, который должен обрабатывать весь трафик, стал для большинства узких мест.

Резюме:

  • Подсчитайте вхождения "the" в книге с минимальным программированием и большим количеством времени установки/настройки: Hadoop
  • Создайте атомарные задачи и будьте уверены, что они будут работать вместе с не большим программированием и большим количеством времени установки/настройки: Celery
  • Полностью контролируйте, что делать с вашими сообщениями и как их программировать практически без настройки/времени настройки: ZeroMQ
  • Имейте боль без настройки/времени конфигурации: Розетки