По данным сайта Кафки :
« Kakfa используется для создания конвейеров данных в реальном времени и потоковых приложений ».
Просматривая Интернет повсеместно, я нашел следующее общепринятое определение понятия « потоковые данные »:
- Потоковые данные - это данные, которые непрерывно перемещаются из источника в пункт назначения по сети; и
- Потоковые данные не являются атомарными по своей природе, то есть любая часть потокового потока данных является значимой и обрабатываемой, в отличие от файла, байты которого ничего не значат, если у вас их нет; и
- Потоковые данные могут быть запущены / остановлены в любое время; и
- Потребители могут присоединять и отсоединять поток данных по желанию и обрабатывать только те его части, которые им нужны.
Теперь, если что-то, что я сказал выше, является неправильным, неполным или полностью неправильным, пожалуйста, начните исправлять меня! Если предположить, что я более или менее на пути, то ...
Теперь, когда я понимаю, что такое «потоковые данные», я понимаю, что означают Kafka и Kinesis, когда они считают себя промежуточным ПО для обработки / посредничества для приложений с потоковой передачей данных. Но это пробудило мои интересы: можно / нужно ли использовать «потоковое промежуточное ПО», такое как Kafka или Kinesis, для потоковой передачи данных, как традиционные брокеры сообщений? И наоборот: можно / нужно использовать для потоковой передачи данных традиционные MQ, такие как RabbitMQ, ActiveMQ, Apollo и т. Д.?
Давайте рассмотрим пример, в котором приложение будет отправлять своему внутреннему постоянному заграждению сообщения JSON, которые должны быть обработаны, и обработка довольно сложна (проверка, преобразование данных, фильтрация, агрегация и т. Д.):
- Случай № 1: сообщения - это каждый кадр фильма; это одно сообщение JSON на видеокадр, содержащее данные кадра и некоторые поддерживающие метаданные
- Случай № 2: сообщения представляют собой данные временного ряда, возможно, чье-то сердцебиение как функция времени. Итак, Сообщение № 1 отправлено, представляя мое сердцебиение в момент времени t = 1, Сообщение № 2 содержит мое сердцебиение в момент времени t = 2 и т. Д.
- Случай № 3: данные полностью несопоставимы и не связаны по времени или как часть какого-либо «потока данных». Возможно, события аудита / безопасности, которые запускаются, когда сотни пользователей перемещаются по кнопкам приложения и выполняют действия
Основываясь на том, как оплачиваются счета Kafka / Kinesis, и на моем понимании того, что такое «потоковые данные», они кажутся очевидными кандидатами на случаи № 1 (непрерывные видеоданные) и № 2 (непрерывные данные временных рядов). Однако я не вижу причин, по которым традиционный брокер сообщений, такой как RabbitMQ, не мог бы эффективно обрабатывать оба этих ввода.
А в случае № 3 нам предоставляется только событие, которое произошло, и нам нужно обработать реакцию на это событие. Так что для меня это говорит о необходимости традиционного брокера, такого как RabbitMQ. Но также нет причины, по которой вы не могли бы, чтобы Kafka или Kinesis обрабатывали данные событий.
В общем, я ищу рубрику, которая гласит: у меня есть данные X с характеристиками Y. Я должен использовать потоковый процессор, такой как Kafka / Kinesis, чтобы справиться с этим. Или, наоборот, тот, который помогает мне определить: у меня есть данные W с характеристиками Z. Я должен использовать традиционный брокер сообщений, чтобы справиться с этим.
Поэтому я спрашиваю: какие факторы в отношении данных (или иным образом) помогают управлять решением между потоковым процессором или брокером сообщений, поскольку оба могут обрабатывать потоковые данные, и оба могут обрабатывать (не потоковые) данные сообщения?
Kafka / Kinesis моделируется как поток. Поток имеет свойства, отличные от сообщений.
Как правило, используйте Kafka для автономной обработки потока, используйте очереди сообщений для сообщений клиент-сервер в реальном времени.
Пример использования вариантов из основного :
Иногда может быть полезно использовать оба! Например, в случае использования № 2, если бы это был поток данных, скажем, от стимулятора, я бы попросил кардиостимулятора передать данные тактового импульса в очередь сообщений RabbitMQ (используя классный протокол, такой как MQTT), где они сразу же обрабатываются в посмотрим, бьется ли все еще сердце источника. Это может привести в действие приборную панель и систему аварийного реагирования. Очередь сообщений также помещает данные временных рядов в Kafka, чтобы мы могли анализировать данные пульса с течением времени. Например, мы могли бы реализовать алгоритм для обнаружения болезней сердца, замечая тенденции в потоке сердцебиения.
источник
KafkaProducer
,Kafka
иKafkaConsumer
. Допустим,KafkaProducer
живет внутри Java-приложения, иKafkaConsumer
оно работает на каком-то Ruby-приложении / бэкэнде.KafkaProducer
отправляетMessage1
в Кафку, которая должна быть преобразована черезFunction1
. Где живетFunction1
код? На Кафке (собственно) или внутриKafkaConsumer
(в приложении Ruby)?