Flume — управляем потоками данных. Часть 1

[LeshiyUrban]

Спасибо за информацию. А это с Apache Camel слегка не конкурирует?

[Deneb]

К несчастью, я не имею практического опыта работы с Apache Camel. После беглого прочтения User Guide/Manual для Camel могу сказать, что здесь вряд ли может быть конкуренция:

• Flume предназначен для транспортировки данных, Camel — скорее для реализации взаимодействия сервисов.
• Flume делает упор на надежность доставки, Camel, как мне кажется — на гибкость формата сообщений и интерактивность.

Я думаю, Camel логичнее использовать для задач, где решающую роль играет содержимое сообщений/событий, а Flume — где нужно "разложить данные по полочкам". Было бы интересно услышать ваше мнение)

[LeshiyUrban]

Мое мнение зиждется на беглом прочтении документации о Apache Flume и нескольких лет разработки на Apache Camel)
Camel довольно таки универсальный инструмент для передачи, преобразования и маршрутизации сообщений откуда угодно, куда угодно и как угодно. С огромным набором готовых входов (Source в терминологии Flume), выходов (Sink в т. Flume) и преобразований. Важное отличие: надо кодировать (xml, DSL, java, scala, groovy) и одним конфигом как в Flume не обойтись.
У меня создалось впечатление, что Flume это Camel, из которого выкинули все по-максимуму и дописали пару функций)) Но это чисто ИМХО.

[Deneb]

А есть в Camel какой-то аналог каналов Flume? Я видел, что Camel поддерживает транзакционность, но что будет, если один из endpoint's окажется в нерабочем состоянии? Где будет копиться очередь не доставленных сообщений и дойдут ли они в итоге, когда машина вернется в строй?

[LeshiyUrban]

Очередь сообщений будет копится в зависимости от типа источника. Например: для БД, транзакция означает откат и в БД, seda — аналог BlockingQueue с заданием лимитов. В каждом случае по своему.
Если упрощено, то да, в большинстве случаев сообщение будет передано, когда абонент вернется в строй

[Deneb]

Если речь идет о БД, то тогда наверное имеет смысл сравнивать производительность. В Flume каналы реализованы для быстрой передачи довольно больших объемов данных. Сейчас я не готов предоставить характеристики "в попугаях", пожалуй затрону эту тему в следующих частях. Спасибо за ответ!

[voidnugget]

Некорректно сравнивать Camel с Flume так как задачи совсем различные: Flume разрабатывался для потоковой обработки логов в конвейерах, а Camel для преобразования разнородных интерфейсов.

[dgr]

Я бы еще добавил, что Flume очень легко расширяется, написать собственный source, channel или sink просто.

[Deneb]

Да, вы совершенно правы, разработка самописных компонентов для Flume не требует значительных усилий. Правда, мы разрабатывали только source/sink реализации — channel'ы как-то не было необходимости) Во второй части цикла приведу примеры нестандартных компонентов.

[f1sherox]

Отличная статья, спасибо. Жду продолжения.
Есть ли опыт работы с Apache Storm? Интересно узнать мнение о работе этого инструмента в сравнении с Flume.

[Deneb]

Здесь ситуация такая же как с Apache Camel — опыта работы с Apache Storm у меня нет =) Судя по описаниям и примерам, Storm является "вычислительным инструментом без хранения данных", Flume же — просто транспорт. Да, он позволяет выполнять различные манипуляции над данными, но задачи типа MapReduce, конечно, решать не умеет. Я думаю, что Storm ближе к категории инструментов типа Akka.