Распределенные вычисления с использованием очереди сообщений VS Map/Reduce

Question

Контекст:

Мы рассматриваем AMQP-совместимое решение как способ вычисления постоянного потока данных, объем которого составляет 90 ГБ в день. То, чего мы хотели бы достичь, это живая статистика, более или менее основанная на всех или некоторой комбинации метрик, которые мы наблюдаем. Рассматриваемая стратегия состоит в том, чтобы отправлять данные в очередь и иметь дельты данных рабочего процесса, отправляя данные обратно в очередь в виде совокупности исходных данных.

Наблюдение:

Для меня это похоже на работу для чего-то вроде Hadoop, но проблемы (и щиты) были подняты, в основном, о скорости. У меня не было времени для сравнения обоих показателей, хотя мы ожидали прокачки большого количества данных через очередь (где-нибудь в районе 10~100 Мбит / с). Я все еще думаю, что это похоже на работу для распределенной вычислительной системы, и я также чувствую, что решение для очереди будет масштабироваться хуже, чем решение для распределенных вычислений.

Вопрос:

Проще говоря, я прав? Я немного читал о Hadoop + HDFS, я думал об использовании другой FS, такой как Luster или что-то подобное, чтобы обойти NodeName SPOF, и использовал какое-то решение, чтобы иметь некоторую терпимость к отказу узлов любого вида на весь кластер.

Answer 1

Очень сложно написать свое собственное решение для "распределенной среды", когда вам нужна отказоустойчивость, хорошая балансировка и т. Д. Если вам нужна карта / уменьшение в реальном времени, вы должны использовать шторм, который использует Твиттер для своих огромных потребностей в данных. Он менее сложен, чем hadoop, и лучше использует входные данные типа очереди (на мой взгляд).

Также, если вы решите проанализировать свои данные на hadoop, не слишком беспокоитесь о SPOF имени узла, есть несколько способов избежать этого.