it-swarm.com.de

Traditionelle Nachrichtenbroker und Streaming-Daten

Laut der Kafka Seite :

" 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 " Daten streamen" 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 jeder Teil eines fließenden Datenstroms sinnvoll und verarbeitbar ist, im Gegensatz zu einer Datei, deren Bytes nichts bedeuten, es sei denn, Sie haben alle von ihnen; 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 "Middleware streamen" wie Kafka oder Kinesis für Nicht-Streaming-Daten wie herkömmliche Nachrichtenbroker verwendet werden? Und umgekehrt: Können/sollten traditionelle MQs mögen 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 völlig unterschiedlich und zeitlich oder als Teil eines "Datenstroms" nicht miteinander verbunden. Möglicherweise werden Prüfungs-/Sicherheitsereignisse ausgelöst, wenn Hunderte von Benutzern durch die Anwendung navigieren, auf Schaltflächen klicken und Aktionen ausführen

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 konnte nicht Auch diese beiden Eingaben effizient handhabt.

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 Sie nicht Kafka oder Kinesis) für die Verarbeitung von Ereignisdaten haben 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 einen, der mir hilft, Folgendes zu bestimmen: Ich habe W-Daten mit Z-Eigenschaften. Ich sollte einen traditionellen Nachrichtenbroker verwenden, um damit umzugehen.

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

13
smeeb

Kafka befasst sich mit geordneten Protokollen atomarer Nachrichten. Sie können es so ähnlich wie das pub/sub Modus von Nachrichtenbrokern, aber mit strenger Reihenfolge und der Fähigkeit, den Nachrichtenstrom zu jedem Zeitpunkt in der Vergangenheit wiederzugeben oder zu durchsuchen, der immer noch auf der Festplatte gespeichert ist (was für immer sein könnte).

Kafkas Streaming-Geschmack steht im Gegensatz zu Remote Procedure Call wie Thrift oder HTTP und Batch-Verarbeitung 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 verbraucht 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. (Obwohl es nicht ungewöhnlich ist, Kafka Nachrichten in Parkettdateien auf HDFS zu archivieren und sie als Hive-Tabellen abzufragen).

Fall 1: Kafka bewahrt keine bestimmte zeitliche Beziehung zwischen Produzent und Konsument. Es ist schlecht für das Streamen von Videos geeignet, weil Kafka darf langsamer werden, schneller werden, sich anpassen und starten usw. Für Streaming-Medien möchten wir den Gesamtdurchsatz gegen eine geringe und vor allem stabil Latenz (ansonsten) austauschen bekannt als Low Jitter). Kafka ist auch sehr bemüht, keine Nachricht zu verlieren. Beim Streaming von Videos verwenden wir normalerweise UDP und geben uns damit zufrieden, hier und da einen Frame abzulegen, um das Video am Laufen zu halten. Das SLA bei einem von Kafka unterstützten Prozess beträgt normalerweise Sekunden bis Minuten, wenn es gesund ist, Stunden bis Tage, wenn es gesund ist. Das SLA bei Streaming-Medien ist in zehn Millisekunden angegeben) .

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 verwenden Kafka auf diese Weise bei meinem Arbeitgeber.

Fall: Sie können Kafka für diese Art von Dingen verwenden, und wir tun dies, aber Sie zahlen unnötigen Aufwand, um die Bestellung aufrechtzuerhalten. Da es Ihnen egal ist In Bezug auf die Bestellung könnten Sie wahrscheinlich mehr Leistung aus einem anderen System herausholen. Wenn Ihr Unternehmen bereits einen Kafka Cluster) unterhält, ist es wahrscheinlich am besten, ihn wiederzuverwenden, anstatt die Wartungslast eines anderen Messaging zu übernehmen System.

5
closeparen

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. Z.B. Apache Trident hat angeblich genau einmal Semantik beim Konsumieren aus einem Kafka Stream).
  • 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 im Allgemeinen Kafka 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 Commit-Protokolle

RabbitMQ: Allzwecknachrichten ..., die häufig verwendet werden, um Webservern zu ermöglichen, schnell auf Anforderungen zu reagieren, 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 dazu bringen, Heartbeat-Daten an eine RabbitMQ-Nachrichtenwarteschlange zu senden (unter Verwendung eines coolen Protokolls wie MQTT), 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 Herzschlagdaten im Laufe der Zeit analysieren können. Beispielsweise könnten wir einen Algorithmus implementieren, um Herzerkrankungen zu erkennen, indem wir Trends im Herzschlagstrom erkennen .

5
Samuel