Эластичная топология Storm / сосуществование Storm и Hadoop

Мы оцениваем возможность развертывания преследования Storm, но меня это немного беспокоит. В настоящее время мы запускаем Hadoop MapReduce и хотели бы перенести часть нашей обработки с процессов MapReduce на процессы Storm. Обратите внимание, что это некоторые, но не все. У нас по-прежнему будет некоторая функциональность MapReduce.

Я нашел Mesos, который (потенциально) мог бы позволить нам поддерживать развертывание Storm и Hadoop на одном и том же оборудовании, но имел несколько других проблем:

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

  • Я хочу избежать узких мест в нашей среде Storm. Идеальным случаем было бы «раскрутить» (или наоборот) больше экземпляров Bolts по мере необходимости. Это возможно / реально?

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

Правильно ли мы подходим к этой проблеме? По сути, топология Storm «подпитывает» пакетное задание MapReduce. Некоторая часть нашей обработки может обрабатываться в потоковом режиме и была бы намного лучше в качестве топологии Storm, в то время как некоторые из них требуют пакетной обработки.

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


java hadoop mapreduce distributed-computing apache-storm
person jon    schedule 03.01.2013    source источник
comment
Что вы имеете в виду, когда говорите, что перезапуск топологии кажется довольно дорогой операцией? Дорого в каком смысле?   -  person Jack    schedule 10.01.2013
comment
Кажется, что нужно все закрыть и заново развернуть, и могут быть пробелы в недоступности.   -  person jon    schedule 12.01.2013
comment
Чтобы справиться с этим, необходимо отключить топологию и позволить очереди сообщений / данных встать в очередь у источника, когда вы затем исправите / измените свой топологию и повторно развернете. Прямо сейчас Storm не имеет возможности автоматически изменять количество болтов в текущей топологии, однако в 0.8.0+ вы можете использовать абстракцию Executors для настройки параллелизма на лету. По сути, это масштабирование вверх / вниз. Storm планирует в будущем использовать Storm-swap, который позволит вам вносить изменения, добавлять / удалять болты (изменять топологию) и заменять их с минимальным временем простоя.   -  person Jack    schedule 14.01.2013

Ответы (1)


arrow_upward
5
arrow_downward

Некоторые мысли и мой опыт проведения аналогичного эксперимента (проработанного в Спайке во время спринта):

  • По моему опыту (я могу ошибаться), вы на самом деле не раскручиваете больше болтов по мере увеличения спроса, а скорее настраиваете конфигурации параллелизма каждого из них в топологии. Топологии не масштабируются путем добавления дополнительных болтов, а масштабируются путем увеличения параллелизма для любого болта, являющегося узким местом. Возьмем пример проблемы с подсчетом слов:
builder.setBolt(4, new MyBolt(), 12)
    .shuffleGrouping(1)
    .shuffleGrouping(2)
    .fieldsGrouping(3, new Fields("id1", "id2"));

Последний параметр («12») - это параллельность этого болта. Если это узкое место в топологии и вам необходимо масштабирование для удовлетворения спроса, вы увеличиваете его. Параллелизм, равный 12, означает, что в результате 12 потоков будут выполнять болт параллельно через штормовой кластер.

  • В 0.8.0 вы можете использовать «Executors», которые также позволяют настраивать «на лету», чтобы помочь масштабировать болт / и т. Д. Вверх / вниз. Пример:

builder.setBolt (новый MyBolt (), 3) .setNumTasks (64) .shuffleGrouping ("someSpout");

Здесь количество исполнителей (потоков) для MyBolt() равно 3, и вы можете изменять количество потоков динамически, не влияя на топологию. storm rebalance используется для этого:

$ storm rebalance someTopology -n 6 -e mySpout=4 -e myBolt=6

Это изменяет количество рабочих процессов для топологии someTopology на 6, количество исполнителей / потоков для mySpout на 4 и количество исполнителей / потоков для myBolt на 6.

  • Похоже, ваша топология шторма будет обрабатывать потоковые данные. Данные, требующие пакетной обработки, будут запущены после того, как они будут сохранены в любом хранилище данных (HDFS), которое вы используете. В этом случае вы бы завернули болт, чтобы сохранить в хранилище данных все необходимые данные.
  • Если, с другой стороны, вы хотите выполнить какую-либо инкрементную обработку поверх любого хранилища данных, которое у вас уже есть (и сохранить состояние), используйте Trident (https://github.com/nathanmarz/storm/wiki/Trident-tutorial). На самом деле Trident может решить многие из ваших вопросов.
person Jack    schedule 10.01.2013
comment
Я также добавлю, что перед развертыванием топологии вы должны иметь некоторое приблизительное представление о том, какой будет нагрузка. И вам следует протестировать топологию, чтобы найти узкие места, и оттуда отрегулировать параллелизм. Я считаю, что Twitter использует Iago twitter.github.com/iago (также известный как Parrot) для API-интерфейсов нагрузочного тестирования, и, не зная больше о том, что уже может предоставить Storm, вы могли бы это использовать. - person Jack; 12.01.2013
comment
Ссылка на Trident больше не действительна. Вместо этого попробуйте: storm.apache.org/documentation/ Trident-tutorial.html - person dlaidlaw; 18.06.2015