Event-Time vs. Processing-Time warum Out-of-Order-Daten Signale verfaelschen.

In einer Trading-Pipeline, die Marktdaten in Echtzeit verarbeitet, gilt eine stillschweigende Annahme: Daten kommen in der Reihenfolge an, in der sie entstanden sind. Diese Annahme ist falsch — und der Irrtum ist teuer. Ticks reisen über Netzwerke, durch Message-Queues, über Vendor-Aggregatoren; sie kommen verspätet, doppelt oder schlicht durcheinander an. Eine Pipeline, die jeden Event in der Reihenfolge seiner Ankunft verarbeitet, berechnet aus dieser falschen Reihenfolge falsche Indikatoren, falsche Signale und am Ende falsche Orders. Der Unterschied zwischen Event-Time (wann ein Tick am Markt entstand) und Processing-Time (wann Ihr System ihn sah) ist deshalb kein akademisches Detail, sondern eine der häufigsten stillen Fehlerquellen in Live-Systemen. Dieser Beitrag erklärt, woher Out-of-Order-Daten kommen, wie Watermarks die wahre Reihenfolge wiederherstellen, welcher Kompromiss zwischen Korrektheit und Latenz dabei unvermeidlich ist — und wo die Methode an ihre Grenzen stößt.

Warum Events selten in der richtigen Reihenfolge ankommen.

Jeder Marktdaten-Tick trägt zwei Zeitpunkte in sich, auch wenn man oft nur einen sieht. Der eine ist der Moment, in dem das Ereignis am Markt entstand — der Match an der Börse, die Quote-Änderung. Der andere ist der Moment, in dem Ihre Verarbeitung den Tick zum ersten Mal in die Hand bekommt. Zwischen beiden liegt ein Weg über Netzwerk-Hops, Vendor-Gateways, Load-Balancer und Message-Broker, und dieser Weg ist nicht für jeden Tick gleich lang.

Die Folge: Ein Tick mit Zeitstempel 12:00:00.250 kann nach einem Tick mit 12:00:00.300 bei Ihnen eintreffen. Eine naive Pipeline, die Events in Ankunftsreihenfolge verarbeitet, sieht eine Welt, in der die Zeit kurz rückwärts läuft. Typische Ursachen sind Paketverlust mit Retransmit, Lastspitzen in einer Queue, Failover zwischen Feed-Handlern, oder schlicht zwei Datenquellen mit unterschiedlicher Latenz, die zusammengeführt werden.

Solange man nur einen Kurs anzeigt, fällt das kaum auf. Sobald man aber zeitabhängige Aggregate berechnet — eine rollierende Volatilität, einen VWAP, ein Bar-Close — entscheidet die Reihenfolge über das Ergebnis. Und ein falsches Aggregat erzeugt ein falsches Signal.

Der Unterschied zwischen Event-Time und Processing-Time.

Processing-Time ist die bequeme Wahl: Man nimmt die Systemuhr im Moment der Verarbeitung. Das ist trivial zu implementieren, immer monoton steigend und unabhängig von der Datenquelle. Der Preis ist, dass die Ergebnisse nicht reproduzierbar sind — derselbe Datenstrom liefert bei einem zweiten Lauf andere Aggregate, weil die Latenzen anders ausfallen. Für einen Backtest ist das fatal, für ein Live-System gefährlich.

Event-Time nimmt stattdessen den Zeitstempel, den der Tick selbst trägt. Damit wird die Verarbeitung deterministisch: Ein Fünf-Sekunden-Bar enthält genau die Ticks, deren Event-Zeit in dieses Fenster fällt — egal, wann sie ankamen, egal, in welcher Reihenfolge. Live-Pipeline und Backtest rechnen identisch, was die Reproduzierbarkeit überhaupt erst ermöglicht.

Der Haken: Event-Time zwingt das System, mit unvollständigen Fenstern umzugehen. Wenn der 12:00:05-Bar abgeschlossen werden soll, muss das System entscheiden, wie lange es noch auf verspätete Ticks für dieses Fenster wartet. Genau hier kommen Watermarks ins Spiel.

Wie Watermarks die Reihenfolge wiederherstellen.

Ein Watermark ist eine fortlaufende Aussage des Systems an sich selbst: „Bis zur Event-Zeit T habe ich vermutlich alle Daten gesehen.“ Es ist eine bewusste, kalkulierte Wette darauf, wie spät ein Tick maximal eintreffen darf, bevor man ihn als verloren abschreibt. Solange das Watermark noch nicht über das Ende eines Fensters hinausgewandert ist, bleibt das Fenster offen und kann verspätete Ticks aufnehmen. Wandert es darüber hinweg, wird das Fenster geschlossen und das Aggregat finalisiert.

Praktisch setzt man Watermarks meist als „aktuelles Event-Time-Maximum minus erlaubte Verspätung“. Bei liquiden Futures mag eine erlaubte Verspätung von wenigen hundert Millisekunden genügen; bei aggregierten Vendor-Feeds oder dünn gehandelten Instrumenten können es mehrere Sekunden sein. Die Zahl ist kein Naturgesetz, sondern eine Designentscheidung, die man aus den tatsächlich gemessenen Verspätungs-Verteilungen ableiten sollte — nicht raten.

Wichtig: Ein Watermark ist eine Heuristik, keine Garantie. Es wird immer Ticks geben, die noch später kommen. Für die muss es eine klare Regel geben, statt dass sie still das Ergebnis verfälschen.

Der unvermeidliche Kompromiss zwischen Korrektheit und Latenz.

Hier liegt der Kern der ganzen Sache, und es gibt keine kostenlose Lösung. Je länger man auf verspätete Ticks wartet, desto vollständiger und korrekter ist das Fenster — und desto später kommt das Signal. Je kürzer man wartet, desto schneller ist man, aber desto mehr Late-Events verpasst man.

Für eine Strategie, die im Sekunden- oder Minutentakt handelt, ist ein Wartepuffer von ein paar hundert Millisekunden meist irrelevant und die zusätzliche Korrektheit jeden Cent wert. Für eine latenzkritische Strategie, die um einzelne Millisekunden konkurriert, kann derselbe Puffer den ganzen Edge auffressen. Es gibt also keine universell richtige Einstellung — es gibt nur die für Ihre Haltedauer und Ihren Signalcharakter passende.

Ein pragmatischer Mittelweg, den manche Systeme fahren: ein vorläufiges Ergebnis bei Fensterende ausgeben und es später, wenn doch noch Late-Events eintreffen, korrigieren. Das funktioniert für Reporting und Risikoaggregation gut, ist aber für direkte Order-Entscheidungen heikel — eine Order lässt sich nicht nachträglich „korrigieren“, wenn sie schon im Markt ist.

Umgang mit Late Events, die zu spät kommen.

Egal wie großzügig das Watermark gesetzt ist, irgendwann trifft ein Tick ein, dessen Fenster bereits geschlossen wurde. Die schlechteste Reaktion ist, ihn still ins nächste, falsche Fenster zu schieben — das verfälscht zwei Aggregate auf einmal. Sinnvoll sind im Wesentlichen drei sauberere Optionen:

• Verwerfen mit Zählung: Den Late-Event ignorieren, aber den Vorfall protokollieren und als Metrik führen. Steigt die Rate verworfener Events, ist das ein Frühwarnsignal für ein Feed- oder Netzwerkproblem.
• Seitenkanal: Late-Events in einen separaten Strom umleiten, der für Reconciliation und Reporting genutzt wird, aber nie für Live-Signale.
• Korrektur mit Versionierung: Das betroffene Aggregat neu berechnen und als korrigierte Version markieren — nur dort, wo nachgelagerte Konsumenten mit Korrekturen umgehen können.

Entscheidend ist, dass die Politik explizit und gemessen ist. Ein System, das Late-Events einfach „irgendwie“ verarbeitet, lügt leise — und niemand merkt es, bis das PnL nicht mehr zur Backtest-Erwartung passt.

Wo die Methode an Grenzen stößt.

Event-Time-Verarbeitung setzt voraus, dass die Zeitstempel der Daten vertrauenswürdig sind. Das ist nicht selbstverständlich. Manche Vendoren stempeln Ticks erst beim Empfang in ihrer Infrastruktur, nicht zur tatsächlichen Markt-Entstehung — dann ist die „Event-Time“ in Wahrheit schon eine Processing-Time eines fremden Systems, und Ihre Korrektheitsannahmen wackeln. Wer Event-Time ernst meint, muss zuerst klären, was der Zeitstempel im Feed eigentlich bedeutet.

Zweitens lösen Watermarks das Problem nicht, sie verschieben es nur auf eine kalibrierbare Wette. Bei stark schwankender Latenz — etwa zu Eröffnungs- oder Schluss-Auktionen, bei Nachrichten-Spikes — kann eine fixe erlaubte Verspätung gleichzeitig zu kurz (zu viele Drops) und zu lang (zu viel Latenz) sein. Adaptive Watermarks helfen, sind aber komplexer und selbst eine Fehlerquelle.

Drittens: Für niederfrequente Strategien auf Tages- oder Stundenbasis ist der ganze Aufwand oft übertrieben. Dort genügt es, am Tagesende sauber zu sortieren und zu deduplizieren. Event-Time-Maschinerie lohnt sich vor allem dort, wo in kurzen Fenstern aggregiert und in Echtzeit gehandelt wird.

Ein pragmatischer Einstieg.

Man muss nicht sofort ein vollständiges Stream-Processing-Framework einführen, um den Großteil des Schadens zu vermeiden. Ein realistischer Pfad in drei Schritten:

Erstens: messen, bevor man baut. Über einige Handelstage die Verteilung der Verspätungen zwischen Event-Time und Ankunft pro Instrument aufzeichnen. Das zeigt, ob das Problem überhaupt relevant ist und wie groß ein Wartepuffer realistisch sein müsste. Häufig stellt sich heraus, dass 99 Prozent der Ticks innerhalb weniger Millisekunden ankommen und nur eine kleine Schwanz-Verteilung Probleme macht — das verändert die Designentscheidung.

Zweitens: deterministische Aggregation auf Event-Time umstellen, mit einem konservativen, gemessen begründeten Watermark, und Late-Events zählen statt still verarbeiten. Schon das beseitigt die meisten verfälschten Signale.

Drittens: erst wenn Volumen und Latenzanforderungen es erzwingen, auf etablierte Stream-Engines mit eingebauter Watermark-Semantik wechseln. Die Reihenfolge zählt: zuerst das Problem verstehen und messen, dann die passende, nicht die größtmögliche Technik wählen.

Sie vermuten, dass Out-of-Order-Daten Ihre Live-Signale verfälschen, wissen aber nicht, wie groß der Effekt ist? Unverbindlich anfragen — wir messen gemeinsam die Verspätungs-Verteilung Ihrer Feeds und legen eine Event-Time-Strategie fest, die zu Ihrer Haltedauer passt, statt blind ein Framework einzuführen.