Apache Flink verwendet Watermarks, um Fortschritt in der Ereigniszeit zu signalisieren. Cisco beschreibt dagegen einen eigenen Puffer, der Ereignisse innerhalb jeder Verbindungssitzung nach ihrer Ereigniszeit sortiert. Beide Ansätze betreffen die Ereigniszeit, erfüllen aber unterschiedliche Aufgaben.
Warum Cisco Ereignisse neu ordnet
Ciscos Pipeline liest Verbindungsereignisse aus Kafka. Eine Verbindung kann aus mehreren Schritten bestehen, etwa auth, assoc, dhcp und dns. Treffen solche Ereignisse in anderer Reihenfolge ein, als sie stattgefunden haben, kann die ursprüngliche Verarbeitung laut Cisco erfolgreiche Verbindungen fälschlich melden.
Cisco zufolge griff die ursprüngliche Variante bei jedem Ereignis auf RocksDB zu und registrierte einen Timer. Das trug zum Engpass im Verarbeitungspfad bei. Die neue Variante sammelt die Ereignisse einer Sitzung zunächst, statt jeden eingehenden Datensatz sofort in der Reihenfolge seines Eintreffens auszuwerten.
Ereigniszeit und Watermarks in Flink
Ereigniszeit bezeichnet den Zeitpunkt, an dem ein Ereignis stattgefunden hat. Verarbeitungszeit ist dagegen die Systemzeit der Maschine, die es verarbeitet. Bei ungeordnet eintreffenden Daten können diese Zeitangaben auseinanderliegen.
Eine Watermark signalisiert Flink Fortschritt in der Ereigniszeit. Operatoren können damit entscheiden, wann sie zeitabhängige Berechnungen weiterführen. Flink beschreibt Watermarks also als Fortschrittssignale; sie sind nicht selbst der Sortierpuffer, den Cisco für einzelne Sitzungen schildert. Die Flink-Dokumentation zu Zeit und Watermarks erläutert diese Zeitbegriffe.
So arbeitet Ciscos Sitzungs-Puffer
Cisco beschreibt eine KeyedProcessFunction, die Ereignisse je Sitzung in einer HashMap hält und sie anhand ihrer Ereigniszeit sortiert, bevor die Ereigniskette ausgewertet wird. Damit richtet sich die Reihenfolge nach dem Zeitpunkt des jeweiligen Schritts und nicht danach, wann der Datensatz eintrifft.
Der Puffer liegt laut Cisco auf dem JVM-Heap und außerhalb des von Flink verwalteten Zustands. Bei Checkpoints kopiert Cisco seinen Inhalt deshalb in ListState; nach einem Neustart wird der Puffer daraus wiederhergestellt. Die Flink-Dokumentation zu Zuständen beschreibt ListState als Zustandsart, deren Werte an den jeweiligen Schlüssel gebunden sind.
Ein wiederhergestellter Anwendungszustand allein garantiert noch keine Exactly-once-Ausgabe vom Anfang bis zur Senke. Cisco weist darauf hin, dass auch die Senke wiederholte Ausgaben korrekt behandeln muss.
Speichergrenzen und berichteter Betrieb
Für den Puffer nennt Cisco mehrere Schutzmaßnahmen: eine selbst festgelegte Leerlaufzeit von drei Minuten, zusammengefasste Timer, kompakte POJOs und das einmalige Parsen von Feldern bei der Aufnahme. Nach drei Minuten Inaktivität kann der Puffer für eine Sitzung entfernt werden.
Cisco berichtet, die neue Variante fünf Monate lang parallel zur ursprünglichen Verarbeitung mit Produktionsdaten betrieben zu haben. Während dieses Vergleichs blieb die ursprüngliche Variante zunächst Standard. Für die eigene Netzwerkverbindungs-Pipeline gibt Cisco eine Verarbeitung von 200.000 Nachrichten pro Sekunde an. Diese Rate bezieht sich auf Ciscos Einsatzfall; sie beschreibt keine allgemeine Flink-Leistung.
