Beitrag von Prithviraj Bose
In diesem Blog werden wir das Fensterkonzept der zustandsbehafteten Transformationen von Apache Spark diskutieren.
Was ist eine zustandsbehaftete Transformation?
Das Spark-Streaming verwendet eine Mikrobatch-Architektur, bei der die eingehenden Daten in Mikrobatches zusammengefasst werden, die als diskretisierte Streams (DStreams) bezeichnet werden und auch als grundlegende Programmierabstraktion dienen. Die DStreams verfügen intern über Resilient Distributed Datasets (RDD) und als Ergebnis dieses Standards können RDD-Transformationen und -Aktionen durchgeführt werden.
Wenn wir beim Streaming einen Anwendungsfall haben, um Daten stapelübergreifend zu verfolgen, benötigen wir zustandsreiche DStreams.
Beispielsweise können wir die Interaktion eines Benutzers auf einer Website während der Benutzersitzung verfolgen oder einen bestimmten Twitter-Hashtag im Laufe der Zeit verfolgen und sehen, welche Benutzer auf der ganzen Welt darüber sprechen.
Arten staatlicher Transformation.
Es gibt zwei Arten von State-Ful-DStreams: fensterbasierte Verfolgung und vollständige Sitzungsverfolgung.
Für eine zustandsbehaftete Verfolgung sollten alle eingehenden Daten in Schlüssel-Wert-Paare umgewandelt werden, damit die Schlüsselzustände stapelweise verfolgt werden können. Dies ist eine Voraussetzung.
Außerdem sollten wir Checkpointing aktivieren, ein Konzept, das wir in den späteren Blogs diskutieren werden.
> Fensterbasiertes Tracking
Unterschied zwischen Wurf und Wurf in Java
Bei der fensterbasierten Verfolgung werden die eingehenden Stapel in Zeitintervallen gruppiert, d. H. Stapel werden alle 'x' Sekunden gruppiert. Weitere Berechnungen für diese Chargen werden unter Verwendung von Objektträgerintervallen durchgeführt.
Wenn beispielsweise das Fensterintervall = 3 Sekunden und das Folienintervall = 2 Sekunden beträgt, werden alle eingehenden Daten alle 3 Sekunden in Stapeln gruppiert und die Berechnungen für diese Stapel werden alle 2 Sekunden durchgeführt. Alternativ können wir sagen, dass Sie alle 2 Sekunden Berechnungen für die Stapel durchführen, die in den letzten 3 Sekunden angekommen sind.
Im obigen Diagramm sehen wir, dass die eingehenden Stapel alle 3 Zeiteinheiten (Fensterintervall) gruppiert werden und die Berechnungen alle 2 Zeiteinheiten (Folienintervall) durchgeführt werden.
Hinweis: Im Gegensatz zu Apache Flink verfügt Apache Spark nicht über ein Konzept zum Taumeln von Fenstern. Alle Fenster werden verschoben.
FEUER
Eine beliebte API für fensterbasierte Transformationen ist
PairDStreamFunctions.reduceByKeyAndWindow .
Es gibt mehrere überladene Versionen dieser API. Sehen wir uns die Version mit den meisten Parametern an. Nach dieser Erklärung sollte der Rest der überladenen Versionen dieser API selbsterklärend sein.
Rückgabe: Der transformierte DStream [(K, V)]
reductFunc : Die assoziative Reduktionsfunktion.
invReduceFunc : Die Umkehrung der obigen Reduktionsfunktion. Dies ist für eine effiziente Berechnung eingehender und ausgehender Stapel erforderlich. Mit Hilfe dieser Funktion wird der Wert der ausgehenden Chargen vom kumulierten Wert der oben genannten Reduktionsfunktion abgezogen. Wenn wir beispielsweise die Summe der eingehenden Werte für die jeweiligen Schlüssel berechnen, subtrahieren wir für die ausgehenden Stapel die Werte für die jeweiligen Schlüssel (vorausgesetzt, sie sind im aktuellen Stapel vorhanden, sonst ignorieren).
windowDuration : Zeiteinheiten für die Gruppierung der Stapel, dies sollte ein Vielfaches des Stapelintervalls sein.
slideDuration : Zeiteinheiten für die Berechnung, dies sollte ein Vielfaches des Stapelintervalls sein. Partitionen : Der Partitionierer, der zum Speichern des resultierenden DStreams verwendet werden soll. Weitere Informationen zur Partitionierung finden Sie unter Dies .
filterFunc : Funktion zum Herausfiltern abgelaufener Schlüssel-Wert-Paare, d. H. Wenn wir beispielsweise für einige Zeit kein Update für einen Schlüssel erhalten, möchten wir ihn möglicherweise entfernen.
Hier ist ein Programm um die Wörter zu zählen, die aus einem Socket-Stream kommen. Wir haben eine überladene Version der obigen Funktion mit einem Fensterintervall von 4 Sekunden und einem Folienintervall von 2 Sekunden verwendet.
In meinem nächsten Blog werde ich über das vollständige Tracking und Checkpointing von Sitzungen schreiben.
Hast du eine Frage an uns? Bitte erwähnen Sie es in den Kommentaren und wir werden uns bei Ihnen melden.
Zusammenhängende Posts: