Что мешает сразу раскидывать всё это добро по 4-8 узлам Flume? Мы же рассматриваем потоковую обработку данных, у нас нет никакого «потом». Если в цепочке хотя бы 1 звено не успевает, то в итоге «забиваются» все звенья перед ним — это вопрос времени. Другое дело, если вы рассматриваете пиковые нагрузки (т.е. Flume не справляется эпизодически) — но что тогда мешает просто сделать каналы потолще?
Я думаю, чтобы определиться с решением, нужно сначала понять — а что дальше планируется делать с логами? Ведь отправить их в Flume/Kafka — это не конечная цель.
Да, только для передачи, итоговый формат зависит от стока (вы можете записывать события в формате Avro, выставив соответствующий serializer в настройках HDFS / File Roll стока). Каналы получают на вход десериализованные данные и хранят их уже как-то по своему.
Конкуренции как таковой нет — скорее, симбиоз. Flume используется для манипуляции данными (дублирование, перенаправление, модификация и т.п.). Но при этом Flume может использовать kafk'у в качестве надежного канала (он даже есть в стандартной поставке Flume).
Признаться, не пробовал писать на других языках :) Думаю, можно на совместимых с JVM — interceptor создается рефлексивно, нужен только конструктор по умолчанию и реализация интерфейсных методов.
Здесь ситуация такая же как с Apache Camel — опыта работы с Apache Storm у меня нет =) Судя по описаниям и примерам, Storm является "вычислительным инструментом без хранения данных", Flume же — просто транспорт. Да, он позволяет выполнять различные манипуляции над данными, но задачи типа MapReduce, конечно, решать не умеет. Я думаю, что Storm ближе к категории инструментов типа Akka.
Если речь идет о БД, то тогда наверное имеет смысл сравнивать производительность. В Flume каналы реализованы для быстрой передачи довольно больших объемов данных. Сейчас я не готов предоставить характеристики "в попугаях", пожалуй затрону эту тему в следующих частях. Спасибо за ответ!
А есть в Camel какой-то аналог каналов Flume? Я видел, что Camel поддерживает транзакционность, но что будет, если один из endpoint's окажется в нерабочем состоянии? Где будет копиться очередь не доставленных сообщений и дойдут ли они в итоге, когда машина вернется в строй?
К несчастью, я не имею практического опыта работы с Apache Camel. После беглого прочтения User Guide/Manual для Camel могу сказать, что здесь вряд ли может быть конкуренция:
Flume предназначен для транспортировки данных, Camel — скорее для реализации взаимодействия сервисов.
Flume делает упор на надежность доставки, Camel, как мне кажется — на гибкость формата сообщений и интерактивность.
Я думаю, Camel логичнее использовать для задач, где решающую роль играет содержимое сообщений/событий, а Flume — где нужно "разложить данные по полочкам". Было бы интересно услышать ваше мнение)
Да, вы совершенно правы, разработка самописных компонентов для Flume не требует значительных усилий. Правда, мы разрабатывали только source/sink реализации — channel'ы как-то не было необходимости) Во второй части цикла приведу примеры нестандартных компонентов.
Я думаю, Camel логичнее использовать для задач, где решающую роль играет содержимое сообщений/событий, а Flume — где нужно "разложить данные по полочкам". Было бы интересно услышать ваше мнение)