Комментарии 12
— Когда мы выбираем Avro Source и Avro Sink, Аvro используется только для передачи? Или данные сохраняются в Avro?
— Насколько flume конкурент новомодной kafka?
— Interseptors можно писать только на java?
- Да, только для передачи, итоговый формат зависит от стока (вы можете записывать события в формате Avro, выставив соответствующий serializer в настройках HDFS / File Roll стока). Каналы получают на вход десериализованные данные и хранят их уже как-то по своему.
- Конкуренции как таковой нет — скорее, симбиоз. Flume используется для манипуляции данными (дублирование, перенаправление, модификация и т.п.). Но при этом Flume может использовать kafk'у в качестве надежного канала (он даже есть в стандартной поставке Flume).
- Признаться, не пробовал писать на других языках :) Думаю, можно на совместимых с JVM — interceptor создается рефлексивно, нужен только конструктор по умолчанию и реализация интерфейсных методов.
Было бы неплохо объяснить что:
- Flume является средством потоковой обработки логов, т.е. вместо низких задержек у него в приоритете высокая пропускная способность и возможность простого партицирования (consistency + partition tolerance + weak availability)
- У Storm с точностью до наоборот — быстро обработали и отдали, в очередь больше положенного не кладём (availability + consistency + weak partitionioning)
- У Kafka задача — обеспечить высокую доступность с возможностью партицирования, но со слабой консистентностью (availability + partition tolerance + weak consistency)
- Сamel вообще не заморачивается с производительностью и доступностью — ему главное один интерфейс преобразовать в другой (consistency + whatever)
Грубо говоря, хаброобыватели из-за недопонимания специфических архитектурных решений высокодоступных или высокопроизводительных проектов сравнивают разные виды кошачих: тигра, гепарда, и льва; спрашивают: кто из них лучше добычу ловит? Вот надо сравнивать по обстоятельствам и ареалу обитания.
Что где использовать — зависит от объёма и скорости прироста логов, количества машин.
kafka спроектирована таким образом что бы работать в кластере, но вы не сможете получать наиболее актуальные данные в текущий момент времени. kafka это просто очередь событий/сообщений, никаких преобразований внутри не происходит. С flume ситуация совсем другая: он обрабатывает и преобразовывает логи в удобоваримый вид для последующей записи в БД hdfs / hbase / scylladb etc. flume может быть как потребителем (sink) данных с kafka, и преобразовывать логи, которые хранятся в очередях, так и поставщиком данных (source) для kafka.
По этому, это проекты с совершенно различными задачами.
Если вам не хватает пропускной способности flume — вы перед ним ставите kafka в качестве буфера.
Также очереди на kafka довольно просто реплицировать для обеспечения отказоустойчивости.
Если вам не хватает пропускной способности flume — вы перед ним ставите kafka в качестве буфера.Не могли бы вы пояснить, каким образом использование Kafka между клиентом и Flume поможет решить проблему с пропускной способностью?
Если объяснять на пальцах правой ноги, то:
Вот у вас есть винт с пропускной способностью в 3Гбит'a и большими задержками¹ и есть оперативка с пропускной способностью в 12Гбит и низкими задержками¹, вот вы ж в оперативку пишите избыток того что пишется на винт, и потребление памяти будет расти в логарифмической прогрессии, в идеальных условиях.
Вот те же яйца и с kafka и flume: у вас есть flume со средней пропускной способностью и большими задержками¹, и есть kafka, с высокой пропускной способностью и низкими задержками¹, почти как запись в /dev/null.
kafka по своей природе любит кушать гигабайты и десятки гигабайт оператвы и слаживать всё в чистом виде на винт, прямо как на грампластинку. Потом это всё можно обработать 4-8 flume'ами, положить в другую kafk'у или сразу записать в БД.
¹ — под задержкой нужно понимать готовность устройства к обработке следующего запроса.
Под пропускной способностью имеется ввиду не пропускная способность сетевого интерфейса, а то сколько запросов Flume может обработать в секунду. Тут пишется о сценарии ~300-500Гб логов в час, с которого потом выжимается 120-250Гб.
Недавно вышла хорошая книжка по похожей теме
Site Reliability Engineering
Edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy
Обычно потом пишут в БД и отрисовуют всякими graylog'aми и kibana. После устаревания утрамбовывают этот компост в "холодное" хранилище на магнитных лентах "аля бобинах", в сервисах типа Amazon Glacier, и подёргивают 6-7 раз в год.
В чистом виде логи писать в БД получается очень расточительно — БД растут как на дрожжах, да и не каждый может позволить себе завести кластер elasticsearch'ей для kibana. Ну, чуваков c elastic.co тоже можно понять, они то разрабатывали всё это не для того что бы в больших масштабах с пол-пинка заводилось — нужно ещё кучу граблей и костылей, а им с того копеечка за поддержку и наставление падаванов.
Flume — управляем потоками данных. Часть 2