Традиционные брокеры сообщений и потоковые данные

По данным сайта Кафки :

« 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. Я должен использовать традиционный брокер сообщений, чтобы справиться с этим.

Поэтому я спрашиваю: какие факторы в отношении данных (или иным образом) помогают управлять решением между потоковым процессором или брокером сообщений, поскольку оба могут обрабатывать потоковые данные, и оба могут обрабатывать (не потоковые) данные сообщения?

Кафка занимается упорядоченными журналами атомарных сообщений. Вы можете просматривать его как pub/subрежим брокеров сообщений, но со строгим упорядочением и возможностью воспроизведения или поиска по потоку сообщений в любой момент в прошлом, который все еще сохраняется на диске (что может быть навсегда).

Суть потоковой передачи Kafka заключается в противоположности удаленному вызову процедур, таких как Thrift или HTTP, и пакетной обработке, как в экосистеме Hadoop. В отличие от RPC, компоненты взаимодействуют асинхронно: между отправкой сообщения и моментом, когда получатель просыпается и воздействует на него, могут проходить часы или дни. В разные моменты времени может быть много получателей, или, возможно, никто никогда не потрудится принять сообщение. Несколько производителей могут производить по одной и той же теме без ведома потребителей. Кафка не знает, подписаны ли вы, или сообщение было использовано. Сообщение просто записывается в журнал, где его может прочитать любой заинтересованный участник.

В отличие от пакетной обработки, вам интересны отдельные сообщения, а не просто гигантские коллекции сообщений. (Хотя нередко архивировать сообщения Kafka в файлы Parquet в HDFS и запрашивать их как таблицы Hive).

Случай 1 : Кафка не сохраняет каких-либо особых временных отношений между производителем и потребителем. Он плохо подходит для потокового видео, потому что Kafka разрешено замедлять, ускорять, перемещать и запускать и т. Д. Для потокового мультимедиа мы хотим снизить общую пропускную способность в обмен на низкую и, что более важно, стабильную задержку (в противном случае известный как низкий джиттер). Кафка также прилагает большие усилия, чтобы никогда не потерять сообщение. При потоковом видео мы обычно используем UDP и используем контент, чтобы пропустить кадр здесь и там, чтобы видео продолжалось. SLA для процесса, поддерживаемого Kafka, обычно составляет от нескольких секунд до минут, когда он здоров, и от нескольких часов до нескольких дней, когда он здоров. SLA для потоковой передачи мультимедиа составляет десятки миллисекунд.

Netflix может использовать Kafka для перемещения кадров во внутренней системе, которая транскодирует терабайты видео в час и сохраняет их на диск, но не для отправки их на экран.

Случай 2 : Абсолютно. Таким образом мы используем Кафку у моего работодателя.

Случай 3 : Вы можете использовать Kafka для такого рода вещей, и мы это делаем, но вы платите некоторые ненужные накладные расходы, чтобы сохранить порядок. Поскольку вы не заботитесь о порядке, вы, вероятно, можете выжать еще больше производительности из другой системы. Если ваша компания уже поддерживает кластер Kafka, то, вероятно, лучше использовать его повторно, а не брать на себя бремя обслуживания другой системы обмена сообщениями.

Kafka / Kinesis моделируется как поток. Поток имеет свойства, отличные от сообщений.

• Потоки имеют контекст для них. У них есть порядок. Вы можете применять оконные функции к потокам. Хотя каждый элемент в потоке имеет смысл, он может быть более значимым с контекстом вокруг него
• Поскольку у потоков есть порядок, вы можете использовать это, чтобы сделать определенные утверждения о семантике обработки. Например, Apache Trident предположительно имеет семантику "точно один раз" при использовании из потока Kafka.
• Вы можете применять функции к потокам. Вы можете преобразовать поток, фактически не потребляя его. Вы можете лениво потреблять поток. Вы можете пропустить части потока.
• Вы можете по сути воспроизводить потоки в Kafka, но вы не можете (без дополнительного программного обеспечения) воспроизводить очереди сообщений. Это полезно, когда вы еще даже не знаете, что вы хотите делать с данными. Это также полезно для обучения AI.

Как правило, используйте Kafka для автономной обработки потока, используйте очереди сообщений для сообщений клиент-сервер в реальном времени.

Пример использования вариантов из основного :

Kafka: отслеживание активности веб-сайтов, метрики, объединение журналов, обработка потоков, журналы событий и фиксация

RabbitMQ: обмен сообщениями общего назначения ..., часто используемый для того, чтобы веб-серверы могли быстро отвечать на запросы, вместо того, чтобы заставлять выполнять ресурсоемкие процедуры, пока пользователь ожидает результата Используйте, когда вам нужно использовать существующие протоколы, такие как AMQP 0-9-1, STOMP, MQTT, AMQP 1.0

Иногда может быть полезно использовать оба! Например, в случае использования № 2, если бы это был поток данных, скажем, от стимулятора, я бы попросил кардиостимулятора передать данные тактового импульса в очередь сообщений RabbitMQ (используя классный протокол, такой как MQTT), где они сразу же обрабатываются в посмотрим, бьется ли все еще сердце источника. Это может привести в действие приборную панель и систему аварийного реагирования. Очередь сообщений также помещает данные временных рядов в Kafka, чтобы мы могли анализировать данные пульса с течением времени. Например, мы могли бы реализовать алгоритм для обнаружения болезней сердца, замечая тенденции в потоке сердцебиения.