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

13

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

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

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

smeeb
источник

Ответы:

5

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

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

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

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

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

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

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

closeparen
источник
1
Спасибо @closeparen (+1) - я понимаю большинство твоих слов, за одним большим исключением. В вашем абзаце, начинающемся с предложения « вкус потоковой передачи Кафки выступает против ... », я склонен думать, что я мог бы заменить большинство экземпляров слова «Кафка» на «RabbitMQ», и предложение было бы верным. Для RabbitMQ: производители могут отправлять сообщения, а потребитель - обрабатывать их и обрабатывать их часами / днями позже. Потребители могут присоединиться к очереди в любое удобное для них время, и поэтому для RabbitMQ в разные моменты времени может быть много разных получателей.
Смееб
1
Думайте о Кафке как о движке баз данных со своеобразной лог-ориентированной структурой. Производители дописывают, потребители читают. Чтение никак не влияет на состояние Кафки. Потребитель может поддерживать нарастающий курсор для создания семантики, идентичной RabbitMQ pub / sub, и это распространенный вариант использования, но это не единственный вариант использования.
closeparen
1
Думайте о RabbitMQ как о распределенной версии структуры данных очереди в памяти. Как только вы вытаскиваете что-то из очереди, оно больше не в очереди. Конечно, у вас может быть топология, в которой она реплицируется в другие очереди для удобства других потребителей, но вы, как правило, не сможете сказать «дайте мне сообщение, которое я обработал 500 сообщений назад», или «запустить очередь B как копию». очереди А, откуда вчера была очередь А. "
closeparen
2
Система, основанная на Кафке, прощает. Если вам не нравится, как ведет себя ваша программа, вы можете нажать изменение кода и затем перемотать его ввод. Вы можете остановить потребителя RabbitMQ, не затрагивая производителей, но вы не сможете вернуться к прошлому.
closeparen
1
Аааа: лампочка: спасибо (+1 за все 3)! Так что это определенно убедительный случай для Кафки: способность пересмотреть прошлое. Я предполагаю, что должен быть какой-то верхний предел или усечение происходит правильно? В противном случае память Кафки всегда будет расти. Даже если данные перетекут на диск, файлы, в которых хранятся данные темы, очень быстро заполнят диск, да?
Смееб
5

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

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

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

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

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

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

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

Самуил
источник
1
Спасибо @Samuel (+1) - это прекрасный ответ и помогает немного лучше разобраться в контексте. На самом деле у меня есть несколько вопросов для вас (если вы не возражаете), но все они зависят от одного начального разъяснения, которое мне нужно: когда вы говорите: « Вы можете применять функции к потокам. Вы можете преобразовать поток». фактически не потребляя его ... ", эти функции / преобразования выполняются на Kafka , или они должны потребляться сначала, прежде чем потоки будут обработаны с помощью функций / преобразований?
Смееб
1
Значение, у вас есть KafkaProducer, Kafkaи KafkaConsumer. Допустим, KafkaProducerживет внутри Java-приложения, и KafkaConsumerоно работает на каком-то Ruby-приложении / бэкэнде. KafkaProducerотправляет Message1в Кафку, которая должна быть преобразована через Function1. Где живет Function1код? На Кафке (собственно) или внутри KafkaConsumer(в приложении Ruby)?
Смееб
2
Вы не можете выполнять функции или выполнять какую-либо обработку в самой Kafka. Apache Spark Streaming и Apache Storm - это две среды распределенной потоковой обработки, которые могут использовать Kafka. Они работают за пределами Кафки и подключаются к ней, как будто это база данных. Фреймворки предоставляют полезные функции, такие как разбиение, агрегация, управление окнами и т. Д. Вы можете реализовать базовые функции в своем клиенте Ruby, но я бы настоятельно рекомендовал одну из фреймворков. spark.apache.org/streaming storm.apache.org/releases/2.0.0-SNAPSHOT/Trident-tutorial.html
Самуил,
1
Хорошо, спасибо и еще раз +1 - это было бы чертовски круто, хотя, если бы Кафка мог сам обрабатывать потоки! Поэтому, чтобы сыграть в защиту дьявола, вы не могли бы просто заставить потребителя RabbitMQ извлекать сообщения из очереди, агрегировать их на основе метки времени (или на самом деле любых других критериев / атрибутов) и выполнять те же функции окна и преобразования в данные, которые Spark Streaming или Storm предоставляют?
Смееб
1
Да, я думаю, вы можете сделать это с RabbitMQ, потому что у RabbitMQ есть гарантии порядка сообщений. Возможно, вы не сможете сделать это с каждой очередью сообщений. И это было бы сложно построить. Например, что если ваш потребитель RabbitMQ, который агрегирует, падает? С Kafka вы можете отслеживать, где в потоке вы обрабатывали, так что вы можете запустить своего потребителя в том месте, где вы остановились
Самуил