In Samza und Kafka Streams wird die Datenstromverarbeitung in einer Sequenz / Grafik (in Samza "Datenflussgraph" und in Kafka Streams "Topologie" genannt) von Verarbeitungsschritten (in Samza "und" Prozessor "genannt) ausgeführt. in Kafka-Bächen). Ich werde diese beiden Begriffe im weiteren Verlauf dieser Frage als workflow und worker bezeichnen.
Nehmen wir an, wir haben einen sehr einfachen Workflow, bestehend aus einem Arbeiter A, der Sensormessungen verbraucht und alle Werte unter 50 filtert, gefolgt von einem Arbeiter B, der die restlichen Messungen empfängt und alle Werte über 80 filtert.
Eingabe (Kakfa-Thema X) - & gt; (Arbeiter A) - & gt; (Arbeiter B) - & gt; Ausgabe (Kafka-Thema Y)
Wenn ich verstanden habe
richtig, sowohl Samza als auch Kafka Streams verwenden das Thema Partitionierungskonzept zum Replizieren des Workflows / Workers und damit die Parallelisierung der Verarbeitung für Skalierbarkeitszwecke.
Aber:
Samza repliziert jeden Worker (d. h. Job) separat für mehrere Aufgaben (einen für jede Partition im Eingabestrom). Das heißt, eine Aufgabe ist ein Replikat eines Worker des Workflows.
Kafka Streams repliziert den gesamten Workflow (d. h. die Topologie) auf einmal auf mehrere Aufgaben (einen für jede Partition im Eingabestrom). Das heißt, eine Aufgabe ist eine Replik des gesamten Workflows.
Das bringt mich zu meinen Fragen:
Angenommen, es gibt nur eine Partition: Stimmt es, dass es nicht möglich ist, die Worker (A) und (B) auf zwei verschiedenen Rechnern in Kafka Streams zu verteilen, während dies in Samza möglich ist? (Oder mit anderen Worten: Ist es in Kafka Streams unmöglich, eine einzelne Aufgabe (d. H. Ein Topologie-Replikat) auf zwei Maschinen aufzuteilen, unabhängig davon, ob mehrere Partitionen vorhanden sind oder nicht.)
Wie kommunizieren zwei aufeinanderfolgende Prozessoren in einer Topologie von Kafka Streams (in derselben Task)? (Ich weiß, dass in Samza die gesamte Kommunikation zwischen zwei nachfolgenden Arbeitern (dh Jobs) mit Kafka-Themen gemacht wird, aber da man in Kafka-Streams explizit im Code "markieren" muss, welche Streams als Kafka-Themen veröffentlicht werden müssen, kann dies nicht sei hier der Fall.)
Stimmt es, dass Samza auch alle Intermediate-Streams automatisch als Kafka-Themen publiziert (und damit potentiellen Kunden zur Verfügung stellt), während Kafka Streams nur jene Intermediate- und Final-Streams veröffentlicht, die man explizit markiert (mit addSink in die Low-Level-API und to oder through in DSL)?
(Ich bin mir bewusst, dass Samza auch andere Nachrichtenwarteschlangen als Kafka verwenden kann, aber das ist nicht wirklich relevant für meine Fragen.)
Als Erstes können Sie in Samza- und Kafka-Streams wählen, ob Sie ein Zwischenthema zwischen diesen beiden Aufgaben (Prozessoren) haben wollen oder nicht, d. h. die Topologie kann entweder:
seinEingabe (Kakfa-Thema X) - & gt; (Arbeiter A) - & gt; (Arbeiter B) - & gt; Ausgabe (Kafka-Thema Y)
oder:
Eingabe (Kakfa-Thema X) - & gt; (Arbeiter A) - & gt; Zwischenstufe (Kafka-Thema Z) - & gt; (Arbeiter B) - & gt; Ausgabe (Kafka-Thema Y)
In beiden Samza- oder Kafka-Streams müssen Sie im ersten Fall Worker A und B gemeinsam bereitstellen, während Sie im letzteren Fall Worker A oder B nicht zusammen bereitstellen können, da entweder Framework-Aufgaben nur über Zwischenthemen kommunizieren und Es gibt keine TCP-basierten Kommunikationskanäle.
In Samza müssen Sie für den ersten Fall Ihre beiden Filter wie in einer Aufgabe codieren, und für den letzteren Fall müssen Sie das Eingabe- und Ausgabethema für jede der Aufgaben angeben, z. Für Worker Ein Eingang ist X und Ausgang ist Z, für Arbeit B Eingang ist Z und Ausgang ist Y, und Sie können die eingesetzten Arbeiter unabhängig starten / stoppen.
In Kafka Streams können Sie diese Prozessoren für den ersten Fall einfach "verketten" wie
stream1.filter (..). filter (..)
und als Ergebnis, wie Lucas erwähnt, wird jedes Ergebnis des ersten Filters sofort an den zweiten Filter übergeben (Sie können sich vorstellen, dass jeder Eingabedatensatz von Topic X die Topologie in der Tiefenreihenfolge durchläuft und es keine Pufferung gibt zwischen irgendwelchen direkt verbundenen Prozessoren);
Und für den letzteren Fall können Sie angeben, dass der Zwischenstrom in einem anderen Thema "materialisiert" werden soll, d. h .:
stream1.filter (..). through ("topicZ"). filter (..)
und jedes Ergebnis des ersten Filters wird an das Thema Z gesendet, das dann an den zweiten Filterprozessor weitergeleitet wird. In diesem Fall können diese beiden Filter möglicherweise auf verschiedenen Hosts oder verschiedenen Threads innerhalb desselben Hosts bereitgestellt werden.
Tags und Links apache-kafka apache-kafka-streams