В моем предыдущем посте я обсуждал нашу BigData Trifecta , в которую входят Storm, Kafka и Cassandra. Кафка сыграл роль нашей работы / очереди данных. Storm исполнял роль нашего механизма ввода / передачи данных, а Cassandra — нашей системы записи для хранения всех вещей.
Cassandra — отличное решение для гибкого и масштабируемого хранилища, но если вы не купите Datastax Enterprise, вы останетесь сами по себе для неструктурированного поиска. Таким образом, нам нужен механизм, который мог бы индексировать данные, которые мы помещаем в Cassandra.
Изначально шел с нашим триггерным механизмом кассандры, подключенным к бэкэнду SOLR. ( https://github.com/hmsonline/cassandra-indexing) Этого было достаточно, но, поскольку мы масштабируем наше использование Cassandra, мы ожидаем гораздо большую нагрузку на SOLR, что означает дополнительную нагрузку для управления отношениями подчиненный / ведущий. Пытаясь опередить это, мы хотели посмотреть на другие альтернативы.
Мы оценили Elastic Search (ES) перед выбором SOLR. ES был лучше почти во всех аспектах: производительность, администрирование, масштабируемость и т. Д. Но он все еще чувствовал себя молодым. Мы провели эту оценку еще в середине 2011 года, и найти коммерческую поддержку ES было сложно по сравнению с SOLR.
Однако в этом году ситуация существенно изменилась, когда появился Elastic Search , и привлек некоторых существенных игроков . С учетом наших оговорок мы решили пересмотреть Elastic Search, но под новым углом.
Теперь у нас есть Storm полностью в нашем технологическом стеке. Поскольку Storm выступал в качестве нашего механизма приема, мы решили отойти от механизма, основанного на триггерах, и вместо этого мы решили организовать поток данных между Cassandra и ES с помощью Storm.
Это побудило нас написать и открыть исходный код болта Elastic Search для Storm:
https://github.com/hmsonline/storm-elastic-search.
Мы просто прикрепили этот болт к концу нашей топологии Storm, и без особых усилий мы получили индекс всех данных, которые мы пишем Кассандре.
Для болта мы реализовали тот же шаблон «картографирования», который мы использовали для рефакторинга болта Шторм Кассандры . Чтобы использовать болт, вам просто нужно реализовать TupleMapper , который имеет следующие методы:
public String mapToDocument(Tuple tuple); public String mapToIndex(Tuple tuple); public String mapToType(Tuple tuple); public String mapToId(Tuple tuple);
Подобно болту Кассандры, где вы отображаете кортеж в ряд Кассандры, здесь вы просто сопоставляете кортеж с документом, который можно опубликовать в Elastic Search (ES). ES требуется четыре элемента информации для индексации документа: сами документы (JSON), индекс, к которому должен быть добавлен документ, идентификатор документа и тип.
Мы включили маппер по умолчанию, который делает не что иное, как извлечение четырех разных частей данных непосредственно из кортежа на основе имени поля:
https://github.com/hmsonline/storm-elastic-search/blob/master/src/main /java/com/hmsonline/storm/contrib/bolt/elasticsearch/mapper/DefaultTupleMapper.java
Болт все еще * очень * сырой. У меня есть образец топологии, который использует его с Болтом Кассандры. Я постараюсь получить это как можно скорее.
Sidenote: Мы все еще ждем решения проблемы с classpath в Storm, прежде чем сможем сделать еще один выпуск. (См .: https://github.com/nathanmarz/storm/issues/115 )
Как всегда, дайте мне знать, если у вас возникли проблемы.