Externe Systemabfragen während Kafka Stream-Verarbeitung

Question

Ich versuche, eine Streaming-Architektur für Streaming-Analysen zu entwerfen. Anforderungen:

• RT und NRT-Streaming-Dateneingang
• Stream-Prozessoren eine Finanzanalyse
• RT und NRT Analyse Ausgabestrom
• Referenzdatenanfragen während der Stream-Verarbeitung

Umsetzung I‘ Ich erkunde Kafka und Kafka Streams für Stream-Verarbeitung und RT/NRT-Echtzeit-Messaging. Meine Frage ist: Ich muss einige Abfrage zu externen Systemen (Info Provider, MongoDB etc etc) während der Stream-Verarbeitung durchführen. Diese Abfragen können basierend auf den externen Systemeigenschaften sowohl synchrone als auch asynchrone Anfrageantworten sein.

Ich habe gelesen this post zu erklären, wie man KStream und KTable während der Verarbeitung beitreten und es ist sehr interessant, aber in diesem Szenario KTable ist nicht abhängig von Eingabeparametern von der KStream, es ist nur eine Streaming-Darstellung einer Tabelle.

Ich muss das externe System foreach KStream Nachricht abfragen, übergibt einige Nachrichtenfelder als Abfrageparameter und bereichern die Streaming-Nachricht mit Abfrageergebnis, dann veröffentlichen Sie die angereicherte Nachricht zu einem Ausgabethema. Gibt es ein konsolidiertes Paradigma, um diese Stream-Verarbeitung zu entwerfen? Gibt es eine bestimmte Technologie, die ich besser verwenden soll? Denken Sie daran, dass Abfragen synchron und asynchron sein können.

Ich möchte auch Wrapper für diese externen Systeme entwerfen und eine Art verteilter RPC implementieren, der über eine Kafka Stream-Verarbeitung aufgerufen werden kann. Können Sie irgendeine Technologie/Rahmen vorschlagen? Ich dachte über Akka-Akteure nach, die Query-Responder verteilen, aber ich kann nicht verstehen, ob Akka gut zu dem Request-Response-Paradigma passt.

Dank

Answer 1

über das anfragende Muster zu externen Systemen, gibt es mehrere Möglichkeiten haben Sie:

1. Empfehlung: Verwenden Kafka Connect Ihre Daten aus externen Systemen in Kafka importieren und diese Themen lesen als KTable s, um die KStream-KTable Lookup Join zu tun.
2. Sie können Ihren eigenen benutzerdefinierten Lookup-Join innerhalb Ihres UDF-Codes implementieren. Abhängig von den Details können Sie KStream Methoden #mapValues(), #map() oder niedrigere Methoden wie #transform() oder #process() verwenden. Daher öffnen Sie manuell eine Verbindung zu Ihrem externen System und geben eine Suchabfrage für jeden von Ihnen verarbeiteten Datensatz aus.
   • Sync-Lookups: Wenn Sie sync Anrufe an externe Systeme tun, ist es nichts anderes müssen Sie überlegen, (Sie können #mapValues() beispielsweise verwenden, um dies zu implementieren)
   • async lookpus: an externe für async Anrufe Systeme, es ist schwieriger, recht zu bekommen (und Sie sollten sehr vorsichtig sein - es ist kein empfohlenes Muster, weil es im Moment keine Bibliotheksunterstützung gibt).Zuerst, müssen Sie sich an alle Async-Aufrufe erinnern, die Sie zuverlässig ausgeben (dh Sie müssen einen Status anhängen und jede Anforderung in den Status schreiben, bevor Sie sie starten). Sekunde, bei jedem Callback müssen Sie das Ergebnis irgendwie puffern und später verarbeiten, wenn derselbe Operator, der die Anfrage absetzt, erneut aufgerufen wird (es ist nicht möglich, ein Downstream-Ergebnis in einem asynchronen Callback-Handler zu erzeugen, sondern nur innerhalb von UDF-Code). Nach dem Downstream-Emit können Sie die Anforderung aus dem Status entfernen. Dritte, müssen Sie in der Wiederherstellung nach einem Fehlerfall Ihren Status auf nicht abgeschlossene Anforderungen überprüfen und diese Anforderung erneut ausgeben. Bedenken Sie auch, dass diese Art der Async-Verarbeitung einige interne Streams-Annahmen wie die garantierte Verarbeitungsreihenfolge in Bezug auf Datensatz-Topic-Offsets durchbricht.

Vergleichen Sie diese Frage über das Scheitern in Strömen hinsichtlich Handhabung Commits zum Ausgleich: How to handle error and don't commit when use Kafka Streams DSL