Courtiers de messages traditionnels et données en streaming

Question

" Kakfa est utilisé pour créer des pipelines de données en temps réel et des applications de streaming."

En cherchant sur Internet partout, j'ai trouvé la définition généralement acceptée suivante de ce qu'est " stream data":

Les données de flux sont des données qui circulent de manière contiguë d'une source à une destination sur un réseau; et
Les données de flux ne sont pas de nature atomique, ce qui signifie que toute partie d'un flux de données fluide est significative et traitable, contrairement à un fichier dont les octets ne le font pas. ne signifie rien sauf si vous les avez tous; et
Les données de flux peuvent être démarrées/arrêtées à tout moment; et
Les consommateurs peuvent attacher et détacher à volonté un flux de données et n'en traiter que les parties qu'ils souhaitent

Maintenant, si tout ce que j'ai dit ci-dessus est incorrect, incomplet ou totalement faux, veuillez commencer par me corriger! En supposant que je suis plus ou moins sur la bonne voie, alors ...

Maintenant que je comprends ce que sont les "données en streaming", je comprends ce que Kafka et Kinesis veulent dire quand ils se présentent comme des middleware de traitement/courtage pour les applications avec des données en streaming. Mais cela a piqué mes intérêts: peut/devrait "diffuser un middleware" comme Kafka ou Kinesis être utilisé pour des données non-streaming, comme les courtiers de messages traditionnels? Et vice versa: peut/devrait traditionnel MQ comme RabbitMQ, ActiveMQ, Apollo, etc. être utilisé pour diffuser des données?

Prenons un exemple où une application enverra son barrage constant de back-end de messages JSON qui doivent être traités, et le traitement est assez complexe (validation, transformations sur les données, filtrage, agrégations, etc.):

Cas n ° 1: les messages sont chacun des cadres d'un film; c'est un message JSON par image vidéo contenant les données d'image et certaines métadonnées de support
Cas n ° 2: Les messages sont des données chronologiques, peut-être le rythme cardiaque de quelqu'un en fonction du temps. Ainsi, le message n ° 1 est envoyé représentant mon rythme cardiaque à t = 1, le message n ° 2 contient mon rythme cardiaque à t = 2, etc.
Cas n ° 3: Les données sont complètement disparates et non liées dans le temps ou dans le cadre d'un "flux de données". Peut-être des événements d'audit/de sécurité qui se déclenchent lorsque des centaines d'utilisateurs naviguent sur les boutons de l'application et prennent des mesures

Sur la base de la facturation de Kafka/Kinesis et de ma compréhension de ce que sont les "données en streaming", elles semblent être des candidats évidents pour les cas n ° 1 (données vidéo contiguës) et n ° 2 (données de séries chronologiques contiguës). Cependant, je ne vois aucune raison pour laquelle un courtier de messages traditionnel comme RabbitMQ ne pourrait pas gère également ces deux entrées de manière efficace.

Et avec le cas # 3, nous ne recevons qu'un événement qui s'est produit et nous devons traiter une réaction à cet événement. Donc, pour moi, cela signifie avoir besoin d'un courtier traditionnel comme RabbitMQ. Mais il n'y a également aucune raison pour laquelle vous ne pourriez pas non plus avoir Kafka ou Kinesis gérer le traitement des données d'événement.

Donc, fondamentalement, je cherche à établir une rubrique qui dit: J'ai des données X avec des caractéristiques Y. Je devrais utiliser un processeur de flux comme Kafka/Kinesis pour le gérer. Ou, inversement, celui qui m'aide à déterminer: J'ai des données W avec des caractéristiques Z. Je devrais utiliser un courtier de messages traditionnel pour le gérer.

Je demande donc: Quels facteurs sur les données (ou autrement) aident à orienter la décision entre le processeur de flux ou le courtier de messages, car les deux peuvent gérer les données en streaming et les deux peuvent gérer les messages (non en streaming) données?

closeparen · Accepted Answer

Kafka traite des journaux ordonnés de messages atomiques. Vous pouvez le voir un peu comme le pub/sub mode des courtiers de messages, mais avec un ordre strict et la possibilité de relire ou de rechercher le flux de messages à tout moment dans le passé qui est toujours conservé sur le disque (ce qui pourrait durer éternellement).

La saveur du streaming de Kafka est opposée à appel de procédure distante comme Thrift ou HTTP, et à traitement par lots comme dans l'écosystème Hadoop. Contrairement à RPC, les composants communiquent de manière asynchrone: des heures ou des jours peuvent s'écouler entre l'envoi d'un message et le réveil du destinataire et son action. Il peut y avoir de nombreux destinataires à différents moments, ou peut-être que personne ne prendra jamais la peine de consommer un message. Plusieurs producteurs pourraient produire sur le même sujet à l'insu des consommateurs. Kafka ne sait pas si vous êtes abonné ou si un message a été consommé. Un message est simplement enregistré dans le journal, où toute personne intéressée peut le lire.

Contrairement au traitement par lots, vous êtes intéressé par les messages uniques, pas seulement par des collections géantes de messages. (Bien qu'il ne soit pas rare d'archiver des messages Kafka dans des fichiers Parquet sur HDFS et de les interroger en tant que tables Hive).

Cas 1: Kafka ne préserve aucune relation temporelle particulière entre le producteur et le consommateur. Il ne convient pas pour le streaming vidéo car Kafka est autorisé à ralentir, à accélérer, à bouger par à-coups, etc. Pour le streaming multimédia, nous voulons échanger le débit global en échange de faible et, plus important encore, stable latence (autrement connue sous le nom de faible gigue). Kafka prend également beaucoup de peine à ne jamais perdre un message. Avec la vidéo en streaming, nous utilisons généralement UDP et nous nous contentons de supprimer une image ici et là pour garder la vidéo en cours d'exécution. Le SLA sur un processus soutenu par Kafka est généralement de quelques secondes à quelques minutes lorsqu'il est sain, de quelques heures à plusieurs jours lorsqu'il est sain. Le SLA = sur les médias en streaming est en dizaines de millisecondes.

Netflix pourrait utiliser Kafka pour déplacer des images dans un système interne qui transcode des téraoctets de vidéo par heure et les enregistre sur le disque, mais pas pour les envoyer à votre écran.

Cas 2: Absolument. Nous utilisons Kafka de cette façon chez mon employeur.

Cas: Vous pouvez utiliser Kafka pour ce genre de chose, et nous le faisons, mais vous payez des frais généraux inutiles pour préserver l'ordre. Puisque vous ne vous souciez pas à propos de l'ordre, vous pouvez probablement extraire des performances supplémentaires d'un autre système. Si votre entreprise gère déjà un cluster Kafka, cependant, il est probablement préférable de le réutiliser plutôt que de supporter la charge de maintenance d'une autre messagerie. système.

Samuel · Answer

Kafka/Kinesis est modélisé comme un flux. Un flux a des propriétés différentes de celles des messages.

Les flux ont un contexte pour eux. Ils ont de l'ordre. Vous pouvez appliquer des fonctions de fenêtre sur les flux. Bien que chaque élément d'un flux soit significatif, il peut l'être davantage avec le contexte qui l'entoure
Parce que les flux ont de l'ordre, vous pouvez l'utiliser pour faire certaines déclarations sur la sémantique du traitement. Par exemple. Apache Trident a soi-disant une sémantique exacte lorsqu'il consomme à partir d'un flux Kafka.
Vous pouvez appliquer des fonctions aux flux. Vous pouvez transformer un flux sans le consommer réellement. Vous pouvez paresseusement consommer un flux. Vous pouvez ignorer des parties d'un flux.
Vous pouvez intrinsèquement rejouer des flux dans Kafka, mais vous ne pouvez pas (sans logiciel supplémentaire) relire les files d'attente de messages. Ceci est utile lorsque vous ne savez même pas encore ce que vous voulez faire avec les données. Il est également utile pour entraîner l'IA.

Généralement, utilisez Kafka pour le traitement de flux hors ligne, utilisez les files d'attente de messages pour les messages client-serveur en temps réel.

Exemples de cas d'utilisation de pivot :

Kafka: suivi de l'activité du site Web, mesures, agrégation de journaux, traitement de flux, sourcing d'événements et journaux de validation

RabbitMQ: messagerie à usage général ..., souvent utilisé pour permettre aux serveurs Web de répondre rapidement aux demandes au lieu d'être obligé d'effectuer des procédures gourmandes en ressources pendant que l'utilisateur attend le résultat. À utiliser lorsque vous devez utiliser des protocoles existants comme AMQP 0-9-1, STOMP, MQTT, AMQP 1.0

Il peut parfois être utile d'utiliser les deux! Par exemple, dans le cas d'utilisation n ° 2, s'il s'agissait d'un flux de données provenant d'un stimulateur cardiaque, je demanderais à ce dernier de transmettre des données de pulsation à une file d'attente de messages RabbitMQ (en utilisant un protocole sympa comme MQTT) où il est immédiatement traité pour voir si le cœur de la source bat toujours. Cela pourrait alimenter un tableau de bord et un système d'intervention d'urgence. La file d'attente de messages déposerait également les données de série chronologique dans Kafka afin que nous puissions analyser les données de battement de cœur au fil du temps. Par exemple, nous pourrions implémenter un algorithme pour détecter les maladies cardiaques en notant les tendances dans le flux de battements de cœur .