Traditionelle Nachrichtenbroker und Streaming-Daten

Laut der Kafka-Site :

" Kakfa wird zum Erstellen von Echtzeit-Datenpipelines und Streaming-Apps verwendet. "

Ich habe weit und breit im Internet gesucht und die folgende allgemein akzeptierte Definition von " Stream-Daten " gefunden:

• Stream-Daten sind Daten, die über ein Netzwerk zusammenhängend von einer Quelle zu einem Ziel fließen. und
• Stream-Daten sind nicht atomarer Natur, was bedeutet, dass ein Teil eines fließenden Datenstroms sinnvoll und verarbeitbar ist, im Gegensatz zu einer Datei, deren Bytes nichts bedeuten, es sei denn, Sie haben alle. und
• Stream-Daten können jederzeit gestartet / gestoppt werden. und
• Verbraucher können nach Belieben einen Datenstrom anhängen und von diesem trennen und nur die Teile verarbeiten, die sie möchten

Wenn etwas, was ich oben gesagt habe, falsch, unvollständig oder völlig falsch ist, korrigieren Sie mich bitte zunächst! Angenommen, ich bin mehr oder weniger auf dem richtigen Weg, dann ...

Jetzt, da ich verstehe, was "Streaming-Daten" sind, verstehe ich, was Kafka und Kinesis bedeuten, wenn sie sich selbst als Verarbeitungs- / Vermittlungs-Middleware für Anwendungen mit Streaming-Daten in Rechnung stellen. Aber es hat meine Interessen geweckt: Kann / sollte "Stream-Middleware" wie Kafka oder Kinesis für Nicht-Streaming-Daten wie herkömmliche Nachrichtenbroker verwendet werden? Und umgekehrt: Können / sollten herkömmliche MQs wie RabbitMQ, ActiveMQ, Apollo usw. zum Streamen von Daten verwendet werden?

Nehmen wir ein Beispiel, in dem eine Anwendung ihr Backend mit einer konstanten Flut von JSON-Nachrichten sendet, die verarbeitet werden müssen, und die Verarbeitung ziemlich komplex ist (Validierung, Transformation der Daten, Filterung, Aggregation usw.):

• Fall 1: Die Nachrichten sind jeweils Frames eines Films. Dies ist eine JSON-Nachricht pro Videorahmen, die die Rahmendaten und einige unterstützende Metadaten enthält
• Fall 2: Die Nachrichten sind Zeitreihendaten, möglicherweise der Herzschlag einer Person als Funktion der Zeit. Es wird also Nachricht Nr. 1 gesendet, die meinen Herzschlag bei t = 1 darstellt, Nachricht Nr. 2 enthält meinen Herzschlag bei t = 2 usw.
• Fall 3: Die Daten sind zeitlich oder als Teil eines "Datenstroms" völlig unterschiedlich und nicht miteinander verbunden. Möglicherweise werden Prüfungs- / Sicherheitsereignisse ausgelöst, wenn Hunderte von Benutzern durch die Anwendung navigieren, auf Schaltflächen klicken und Maßnahmen ergreifen

Basierend auf der Abrechnung von Kafka / Kinesis und meinem Verständnis von "Streaming-Daten" scheinen sie offensichtliche Kandidaten für die Fälle Nr. 1 (zusammenhängende Videodaten) und Nr. 2 (zusammenhängende Zeitreihendaten) zu sein. Ich sehe jedoch keinen Grund, warum ein traditioneller Nachrichtenbroker wie RabbitMQ diese beiden Eingaben nicht effizient verarbeiten kann.

In Fall 3 erhalten wir nur ein Ereignis, das aufgetreten ist, und wir müssen eine Reaktion auf dieses Ereignis verarbeiten. Für mich bedeutet dies, dass ich einen traditionellen Broker wie RabbitMQ brauche. Es gibt aber auch keinen Grund, warum Kafka oder Kinesis die Verarbeitung von Ereignisdaten nicht übernehmen könnten.

Im Grunde möchte ich eine Rubrik erstellen , die besagt: Ich habe X-Daten mit Y-Eigenschaften. Ich sollte einen Stream-Prozessor wie Kafka / Kinesis verwenden, um damit umzugehen. Oder umgekehrt eine, die mir hilft festzustellen: Ich habe W-Daten mit Z-Eigenschaften. Ich sollte einen traditionellen Nachrichtenbroker verwenden, um damit umzugehen.

Also frage ich: Welche Faktoren über die Daten (oder auf andere Weise) helfen dabei, die Entscheidung zwischen Stream-Prozessor oder Nachrichtenbroker zu steuern, da beide Streaming-Daten und beide (Nicht-Streaming-) Nachrichtendaten verarbeiten können?

Kafka befasst sich mit geordneten Protokollen atomarer Nachrichten. Sie können es wie den pub/subModus von Nachrichtenbrokern anzeigen, jedoch mit strenger Reihenfolge und der Möglichkeit, den Nachrichtenstrom zu jedem Zeitpunkt in der Vergangenheit, der noch auf der Festplatte gespeichert ist (was für immer sein könnte), wiederzugeben oder zu durchsuchen.

Kafkas Streaming-Geschmack steht im Gegensatz zu Remoteprozeduraufrufen wie Thrift oder HTTP und zur Stapelverarbeitung wie im Hadoop-Ökosystem. Im Gegensatz zu RPC kommunizieren Komponenten asynchron: Stunden oder Tage können zwischen dem Senden einer Nachricht und dem Aufwachen und Eingreifen des Empfängers vergehen. Es kann viele Empfänger zu unterschiedlichen Zeitpunkten geben, oder vielleicht wird sich niemand die Mühe machen, eine Nachricht zu konsumieren. Mehrere Hersteller könnten ohne Kenntnis der Verbraucher zum gleichen Thema produzieren. Kafka weiß nicht, ob Sie abonniert sind oder ob eine Nachricht konsumiert wurde. Eine Nachricht wird einfach in das Protokoll übernommen, wo jeder Interessent sie lesen kann.

Im Gegensatz zur Stapelverarbeitung interessieren Sie sich für einzelne Nachrichten, nicht nur für riesige Sammlungen von Nachrichten. (Es ist jedoch nicht ungewöhnlich, Kafka-Nachrichten in Parkettdateien auf HDFS zu archivieren und als Hive-Tabellen abzufragen.)

Fall 1 : Kafka bewahrt keine besondere zeitliche Beziehung zwischen Erzeuger und Verbraucher. Es ist schlecht für das Streamen von Videos geeignet, da Kafka langsamer werden, schneller werden, sich anpassen und starten kann usw. Für das Streamen von Medien möchten wir den Gesamtdurchsatz gegen eine geringe und vor allem stabile Latenz austauschen (andernfalls) bekannt als Low Jitter). Kafka bemüht sich auch sehr, niemals eine Nachricht zu verlieren. Beim Streaming von Videos verwenden wir normalerweise UDP und geben hier und da einen Frame ab, um das Video am Laufen zu halten. Die SLA bei einem von Kafka unterstützten Prozess beträgt normalerweise Sekunden bis Minuten, wenn sie gesund ist, Stunden bis Tage, wenn sie gesund ist. Die SLA für Streaming-Medien liegt in zehn Millisekunden.

Netflix könnte Kafka verwenden, um Frames in einem internen System zu verschieben, das Terabyte Video pro Stunde transkodiert und auf der Festplatte speichert, aber nicht an Ihren Bildschirm sendet.

Fall 2 : Auf jeden Fall . Wir benutzen Kafka so bei meinem Arbeitgeber.

Fall 3 : Sie können Kafka für solche Dinge verwenden, und wir tun dies, aber Sie zahlen unnötigen Aufwand, um die Bestellung aufrechtzuerhalten. Da Sie sich nicht für Ordnung interessieren, könnten Sie wahrscheinlich mehr Leistung aus einem anderen System herausholen. Wenn Ihr Unternehmen jedoch bereits einen Kafka-Cluster unterhält, ist es wahrscheinlich am besten, ihn wiederzuverwenden, anstatt die Wartungslast eines anderen Messagingsystems zu übernehmen.

Kafka / Kinesis wird als Stream modelliert. Ein Stream hat andere Eigenschaften als Nachrichten.

• Streams haben Kontext zu ihnen. Sie haben Ordnung. Sie können Fensterfunktionen auf Streams anwenden. Obwohl jedes Element in einem Stream aussagekräftig ist, kann es im Kontext um ihn herum aussagekräftiger sein
• Da Streams eine Reihenfolge haben, können Sie damit bestimmte Aussagen über die Semantik der Verarbeitung treffen. ZB hat Apache Trident angeblich genau einmal eine Semantik, wenn er aus einem Kafka-Stream konsumiert.
• Sie können Funktionen auf Streams anwenden. Sie können einen Stream transformieren, ohne ihn tatsächlich zu verbrauchen. Sie können einen Stream träge konsumieren. Sie können Teile eines Streams überspringen.
• Sie können Streams in Kafka von Natur aus wiedergeben, aber Sie können Nachrichtenwarteschlangen nicht (ohne zusätzliche Software) wiedergeben. Dies ist nützlich, wenn Sie noch nicht einmal wissen, was Sie mit den Daten tun möchten. Es ist auch nützlich für das Training der KI.

Verwenden Sie Kafka im Allgemeinen für die Offline-Stream-Verarbeitung und Nachrichtenwarteschlangen für Client-Server-Nachrichten in Echtzeit.

Beispielanwendungsfälle von Pivotal :

Kafka: Verfolgung von Website-Aktivitäten, Metriken, Protokollaggregation, Stream-Verarbeitung, Ereignisbeschaffung und Festschreibungsprotokolle

RabbitMQ: Allzwecknachrichten ..., die häufig verwendet werden, damit Webserver schnell auf Anforderungen reagieren können, anstatt gezwungen zu sein, ressourcenintensive Prozeduren auszuführen, während der Benutzer auf das Ergebnis wartet. Verwenden Sie diese Option, wenn Sie vorhandene Protokolle wie AMQP 0-9-1, STOMP, MQTT, AMQP 1.0 verwenden müssen

Es kann manchmal nützlich sein, beide zu verwenden! Wenn dies beispielsweise in Anwendungsfall 2 ein Datenstrom von einem Schrittmacher wäre, würde ich den Schrittmacher veranlassen, Heartbeat-Daten an eine RabbitMQ-Nachrichtenwarteschlange (unter Verwendung eines coolen Protokolls wie MQTT) zu senden, in die sie sofort verarbeitet werden Sehen Sie, ob das Herz der Quelle noch schlägt. Dies könnte ein Armaturenbrett und ein Notfallreaktionssystem mit Strom versorgen. Die Nachrichtenwarteschlange würde auch die Zeitreihendaten in Kafka ablegen, damit wir die Heartbeat-Daten über die Zeit analysieren können. Zum Beispiel könnten wir einen Algorithmus implementieren, um Herzkrankheiten zu erkennen, indem wir Trends im Herzschlagstrom bemerken.