Das präzise Handhaben von Zeit in Streaming-Daten ist eine der grundlegenden Herausforderungen bei der Entwicklung moderner verteilter Systeme. Während Sequenznummern als logische Zeit bereits seit Langem etabliert sind, gewinnt die physische Zeit, also die genauere Erfassung des Zeitpunkts eines Ereignisses gemessen in Millisekunden seit dem 1. Januar 1970, zunehmend an Bedeutung. Diese Form der Zeit, auch als Unix-Epoche bekannt, bleibt auch in Zukunft eine zentrale Referenzgröße für zeitbasierte Anwendungen und Datenspeicherung. Insbesondere mit dem Aufkommen von Cloud-nativen Streaming-Plattformen wie S2 wird die effiziente Zeithandhabung relevanter denn je. Hierbei geht es nicht nur um das Aufzeichnen von Zeitstempeln, sondern auch um deren flexible Auswertung und den Umgang mit den Besonderheiten verteilter Systeme.
Traditionell wurden in der internen Entwicklung von S2 Zeitstempel als Header in Datenpaketen propagiert, was zwar praktikabel schien, sich aber in realitätsnahen Szenarien als unzureichend herausstellte. Denn Anwendungen benötigen verlässliche und leicht zugängliche physische Zeitstempel, um etwa Fahrzeugbewegungen oder Sensordaten langfristig nachvollziehbar zu machen. Die Speicherung von Zeitstempeln in jedem Datensatz allein reicht jedoch nicht aus, wenn eine effiziente Nutzung dieser Zeitinformationen fehlt. Eine typische Abfragestrategie ist das lineare Durchsuchen von Daten ab einem bestimmten Zeitpunkt, was bei kostengünstiger Speicherung direkt aus dem Stream attraktiv ist, ohne auf zusätzliche indizierte Datenbanken zurückgreifen zu müssen. Dabei hilft eine wichtige Eigenschaft: Monotonie der Zeit. Das bedeutet, jeder neue Datensatz besitzt eine Zeit, die entweder gleich bleibt oder gegenüber dem vorherigen Datensatz fortschreitet.
Ist diese Voraussetzung erfüllt, können Streams wie S2 ohne weitere sekundäre Indexstrukturen auskommen, da die zeitsortierte Anordnung bereits von Natur aus gegeben ist. Die technische Grundlage für das effiziente Suchen an einem bestimmten Zeitpunkt ähnelt dem Navigieren durch Sequenznummern. Die Backend-Implementierung nutzt hierzu eine Art verteilte Skip-Liste, die Metadaten, Objektspeicher und Zwischenspeicher für aktuelle Schreibvorgänge durchquert. Doch in verteilten Systemen ist Zeit nicht immer eindeutig. Unterschiedliche Geräte und Server besitzen eigene Uhren, die durch Netzwerklatenzen und Synchronisationsabweichungen variieren können. Daraus ergibt sich eine wichtige Frage: Welche Zeit wird als gültig betrachtet, die clientseitig angegebene oder die serverseitige Ankunftszeit?
Zusätzlich erschwert wird die Situation bei Anwendungen, die den tatsächlichen Ereigniszeitpunkt wichtiger finden als den Zeitpunkt des Schreibens in den Stream – beispielsweise Fitness-Tracker, die Daten erst beim erneuten Online-Gehen übertragen. Ein Blick auf bestehende Streaming-Systeme zeigt unterschiedliche Herangehensweisen. Amazon Kinesis versieht Datensätze mit einer ApproximateArrivalTimestamp, welche zur Leseanwahl genutzt werden kann. Eigene clientseitige Zeitstempel kommen nur als Dateninhalt vor, ohne spezielle Indizierung. Apache Pulsar differenziert zwischen brokerseitigem PublishTime und optionalem EventTime des Clients, erlaubt aber nur eine Suche mit dem PublishTime. Kafka hingegen bietet eine duale Timestamp-Strategie: CreateTime, der clientdefinierte Zeitstempel, und LogAppendTime, die vom Broker vergeben wird. Fehlt beim Client die Angabe, ersetzt Kafka CreateTime durch LogAppendTime.
Zeitstempel unterstützen bei Kafka auch die Datenaufbewahrung, wodurch spezielle Einstellungen für das Clamping sinnvoll sein können. Für S2 wurde letztlich ein pragmatischer Mittelweg gewählt. Standardmäßig wird die Ankunftszeit beim Stream-Server als monotone Zeit in Millisekunden seit der Unix-Epoche genutzt. Um die Monotonie sicherzustellen, führt das Backend eine Nachverfolgung des jeweils höchsten Zeitstempels je Stream. Sollte ein neuer Zeitstempel geringer ausfallen – eine typische Verteilungsproblemematik – wird dieser automatisch auf den zuletzt höchsten Wert angepasst. Dadurch entsteht eine gefühlte Zeitkurve, die niemals rückwärts läuft. Dabei sind identische Zeitstempel bei aufeinanderfolgenden Einträgen erlaubt, was Abweichungen im Millisekundenbereich kompensiert. Das System nimmt Eingangszeiten entgegen, zum Beispiel die Werte 42, 44, 42, 50, 50, 48, 55, und korrigiert sie so zu 42, 44, 44, 50, 50, 50, 55.
Ein durchdachtes Feature ist die Option, clientseitige Zeitstempel zu erlauben und sogar bevorzugt einzusetzen, denn gerade bei Anwendungen mit Offline-Szenarien oder nachträglichen Datenimporten sind exakte Eventzeiten entscheidend. Dabei hilft ein konfigurierbarer Modus für die Zeitstempelverwendung, der als „timestamping. mode“ in der Stream-Konfiguration einstellbar ist. Tres Modusoptionen ermöglichen individuelle Anpassungen: client-prefer setzt clientseitige Zeitstempel bevorzugt ein, fallback auf die Serverzeit ist möglich; client-require erwartet zwingend eine clientseitige Zeitangabe und lehnt fehlende ab; arrival ignoriert clientseitige Angaben vollständig und nutzt ausschließlich die Server-Ankunftszeit. Um extreme Abweichungen zu vermeiden, wirkt die Ankunftszeit standardmäßig als obere Grenze bei der Zeitstempelvergabe. Diese Schutzfunktion kann mit der Einstellung „timestamping.
uncapped“ deaktiviert werden, um die volle Bandbreite der 64-Bit Zeitwerte zu nutzen – dabei behält die Monotonieanpassung aber ihre Gültigkeit, damit keinerlei Rückwärtsbewegungen in der Zeit entstehen können. Bei Schreibvorgängen gibt das System Rückmeldung in Form von Zeitstempelbereichen, die den ersten und letzten Zeitstempel des Batch enthalten. So erfahren Nutzer, ob eine Korrektur der Zeitstempel vorgenommen wurde – bei Bedarf kann auch das Verwerfen von Schreibvorgängen mit unzulässigen Zeitstempeln eingerichtet werden. Durch diese rigorose Monotoniekontrolle bleibt der Datenstrom kosteneffektiv und erlaubt komfortables effizientes Lesen entlang der Zeitachse, sei es nach Ankunftszeit oder nach der eigenen Eventzeit. In der Praxis zeigt sich dadurch ein großer Vorteil der S2-Architektur: Anwendungen können sowohl logische Reihenfolgen als auch reale Zeiten nutzen, ohne aufwendig externe Indexstrukturen warten oder betreiben zu müssen.
Dies erleichtert insbesondere Szenarien wie Langzeitarchivierung von Bewegungsdaten, IoT-Datenaufzeichnung oder Echtzeitanalysen. Zudem schaffen sie die Basis für komplexe Zeitreihenanalysen, die bei statischen oder ungenau indizierten Systemen kaum möglich sind. Der Ansatz von S2, mit seinen flexiblen Zeitstempelmodi und der automatischen Monotoniekontrolle, ist zudem ein Musterbeispiel für den Umgang mit den intrinsischen Herausforderungen verteilter Systeme, in denen Zeiten verschiedenster Ursprungseinheiten zusammenlaufen. Die Balance zwischen Server-Wahrheit und Client-Flexibilität setzt dabei Maßstäbe. Es wird spannend zu beobachten, wie Nutzer und Entwickler diese Möglichkeiten weiter ausreizen und welche neuen Anwendungen durch präzise und effiziente Zeitstempel in Streaming-Daten in Zukunft entstehen.
Zeit ist und bleibt ein fundamentaler Pfeiler digitaler Systeme – mit Technologien wie S2 ist es möglich, sie nicht nur zu messen, sondern auch schlau und praktisch handhabbar zu machen.
