Wie implementiert man ein 'Side-Input' Pattern in Apache Flink für die Anreicherung von Streams mit statischen Daten?

Die Implementierung eines Side-Input Patterns in Apache Flink erfolgt primär über das Broadcast State Pattern. Da Flink keine native "Side-Input"-Funktion wie Apache Beam besitzt, nutzen wir einen Mechanismus, bei dem ein Stream mit Konfigurations- oder Stammdaten an alle parallelen Instanzen eines Operators repliziert wird.

Der technische Ablauf gliedert sich in folgende Schritte:

1. Definition des State Descriptors: Wir definieren einen MapStateDescriptor, der den Typ des Schlüssels und des Wertes der statischen Daten festlegt. Dieser Descriptor dient als Referenz für den Broadcast-State.
2. Broadcast des Side-Input-Streams: Der Stream, der die statischen Daten enthält, wird mit der Methode .broadcast(descriptor) in einen BroadcastStream umgewandelt.
3. Verbindung der Streams: Der Hauptdatenstrom wird mittels .connect() mit dem Broadcast-Stream verknüpft.
4. Implementierung der BroadcastProcessFunction: Wir setzen eine BroadcastProcessFunction ein, die zwei Kernmethoden implementiert:
   • processBroadcastElement: Hier werden die eintreffenden statischen Daten in den Broadcast-State geschrieben oder aktualisiert.
   • processElement: Hier wird das aktuelle Element des Hauptstreams verarbeitet und die Anreicherung durch Zugriff auf den im State gespeicherten Kontext durchgeführt.

Im Vergleich zu anderen Ansätzen bietet dieses Muster spezifische Vor- und Nachteile:

In Projekten im Bereich Cloud & Digital Workplace setzen wir dieses Muster ein, um beispielsweise Validierungsregeln oder Benutzerprofile in Echtzeit zu aktualisieren, ohne den Streaming-Job stoppen zu müssen. Der Zugriff auf den Broadcast-State erfolgt dabei in konstanter Zeit $O(1)$, was die Latenz des Hauptstreams minimal beeinflusst.

Wir empfehlen den Einsatz von Broadcast State gegenüber lokalen Caches immer dann, wenn die statischen Daten während der Laufzeit aktualisiert werden müssen, da nur dieser Ansatz eine konsistente Zustandsverteilung über alle Worker-Knoten ohne kostspielige Job-Neustarts garantiert.