Es gibt eine Frage, die in jedem Workshop früher oder später kommt: „Brauchen wir diese Komplexität wirklich?" Gemeint ist die bitemporale Historisierung – zwei Zeitlinien statt einer, ein paar Spalten mehr, mehr Logik beim Laden. Die Frage ist berechtigt.
Ich will sie hier nicht mit acht Gründen erschlagen, sondern an einem einzigen durchgehen, bei dem ziemlich schnell klar wird, worum es geht: Late Arriving Data. Ein Fall, den jedes Data-Team schon erlebt hat – oft, ohne ihn beim Namen zu nennen.
Wer Yerodin, Philomena, Diego und Amal noch nicht kennt: Sie sind fiktive Figuren aus dem FastChangeCo-Universum, mit dem ich reale Herausforderungen aus Projekten und Coachings greifbar mache.
Dieser Artikel ist Teil 1 einer vierteiligen Serie über bitemporale Daten in der Praxis. Er bündelt zwei der acht Gründe aus dem Hub-Artikel „8 Gründe, warum man bitemporale Daten benötigt" zu einem fachlichen Schwerpunkt: Late Arrivals und nachträgliche Korrekturen.
Die Kernthese: Sobald Daten nicht in der Reihenfolge ankommen, in der sie real passiert sind, kippt ohne bitemporale Historisierung die Datenqualität – leise und unbemerkt.
Bei FastChangeCo fängt es mit einer Reklamation an. Philomena Pavlovic, Business Analyst und Application Developer, bekommt eine genervte Nachricht aus dem Marketing: Eine Versandkampagne ist zu großen Teilen zurückgekommen. Massenhaft Bounces auf eine Verteilerliste – und das, obwohl die Adressen laut System gerade erst aktualisiert wurden.
Philomena nimmt das mit ins Daten-Meeting. Yerodin van Dusseldorp, Controller, schaut sich den Datenfluss an und stutzt. Die neuen Adressen sind drin – aber irgendwie auch die alten. Und für einige Kunden steht in der Liste eine Adresse, von der niemand mehr weiß, woher sie kommt.
Philomena formuliert genau die Frage, die du dir an dieser Stelle wahrscheinlich auch stellst: „Müssen wir da jetzt wirklich eine zweite Zeitebene einziehen? Ist das nicht ein Sonderfall, den wir einmal von Hand ausbügeln?" Diego Pasión, der das Datenteam als Coach begleitet, schüttelt den Kopf. „Schau dir mal an, wann diese Daten in welcher Reihenfolge reingekommen sind. Dann sieht das weniger nach Sonderfall aus."
Das Ideal: Daten in der richtigen Reihenfolge
In analytischen Systemen gehen wir stillschweigend von einem Idealfall aus: Daten kommen in der Reihenfolge bei uns an, in der sie real passiert sind. Stell dir die Kasse im Supermarkt vor. Ich bezahle, meine Transaktion landet im Warehouse. Der Kunde nach mir bezahlt, seine Transaktion landet danach. Eine saubere, zeitlich korrekte Abfolge dessen, was in der Realität geschehen ist. So lange das gilt, reicht eine Zeitlinie völlig aus – wir schreiben einfach fort: neuer Stand, neue Zeile, fertig.
Nur hält dieser Idealfall der Praxis nicht stand. Zwischen operativem System und Warehouse liegen heute Schichten, Schnittstellen, Bussysteme – und so ein Bus garantiert dir keine Reihenfolge. Die eine Message feiert irgendwo noch eine Weile eine Party mit anderen Messages und kommt dann drei Stunden später an als die, die eigentlich vor ihr dran gewesen wäre. Du kannst dir noch so sicher sein, dass das in deinem System nicht passiert – ich habe es in jedem System erlebt, in dem mir ein Admin genau das versichert hat.
Wenn die Korrektur vor dem Original ankommt
Was Philomena im Marketing-Meeting beschrieben hat, hat einen Namen: Late Arriving Data. Zu spät ankommende Daten. Ein klassisches Beispiel macht den Mechanismus greifbar.
Eine Kundin pflegt im Self-Service-Portal von FastChangeCo ihre neue E-Mail-Adresse ein und schickt das Formular ab. Kurz danach merkt sie: Tippfehler. Zehn Minuten später korrigiert sie die Adresse. Aus ihrer Sicht ist alles in Ordnung – die korrigierte Adresse ist die gültige.
Im Warehouse passiert nun etwas Unangenehmes. Über den Umweg durch die Integrationsschicht kommt die Korrektur zuerst an, die fehlerhafte Erst-Eingabe trudelt verspätet danach ein. Das System sieht zwei Änderungen und kann nicht beurteilen, welche fachlich die richtige war. Es greift zur einzigen Regel, die es ohne zweite Zeitlinie hat: Die zuletzt gelieferten Daten sind die aktuellen.
Damit gewinnt die falsche Adresse – sie ist ja zuletzt angekommen. Genau diese Adresse landet in der Versandliste, und hier schließt sich der Kreis zu Philomenas Bounces. Der Report sieht korrekt aus. Er ist es nicht.
Der Wechselkurs-Zahlendreher
Der zweite Fall ist subtiler und tut beim Controlling weh. FastChangeCo verkauft in mehreren Ländern und Währungen. Für die Bilanz muss alles in Euro umgerechnet werden – du brauchst also tagesbasierte Wechselkurse.
Nimm an, in einem dieser Kurse steckt für einen einzigen Tag ein Zahlendreher. Aus 1.000 US-Dollar werden dann statt 900 Euro plötzlich 1.100 Euro. Für einen Tag. Das klingt klein, aber in der Bilanz hat es Wirkung – und es fällt erst Wochen später auf.
Jetzt korrigierst du den Kurs. Und der Punkt ist: Diese Korrektur muss sich exakt an dem einen Tag einsortieren, an dem der Fehler galt. Der naheliegende Reflex lautet, den fehlerhaften Kurs zu löschen und den richtigen einzutragen. Kann man machen. Nur erklärt später niemand mehr, warum ein Bericht von damals andere Zahlen zeigt als der von heute – eine Frage, die eine interne Governance oder eine Aufsicht ziemlich sicher irgendwann stellt. Wie man diese Nachvollziehbarkeit zum Vorteil dreht, ist das Thema von Teil 4.
Warum eine Zeitlinie das Dilemma nicht löst
Beide Fälle zeigen dasselbe Dilemma, und es lässt sich mit einer Zeitlinie nicht auflösen.
Hast du gar keine Historisierung, gelten die zuletzt angekommenen Daten als die aktuellen – auch wenn es die falschen waren, die eigentlich hätten überschrieben werden sollen. Hast du eine einfache, unitemporale Historisierung, sieht es so aus, als wären die eigentlich richtigen Daten nachträglich von den verspätet eingetroffenen falschen korrigiert worden. Beides willst du nicht in deinen Systemen. In beiden Varianten verfälscht die reine Ankunftsreihenfolge dein Ergebnis.
Zwei Zeitlinien lösen es
An dieser Stelle wird Diego im Meeting konkret. „Das Problem ist nicht, dass die Daten verspätet kommen. Das Problem ist, dass ihr nur eine Zeitlinie habt und sie zwei Fragen gleichzeitig beantworten soll." Und das sind zwei verschiedene Fragen: Wann haben wir von einem Wert erfahren? Und: Wann war er in der Realität gültig?
Bitemporale Historisierung trennt das in zwei Zeitlinien. Die Assertion Timeline (technisch) hält fest, wann ein Datensatz bei uns im Warehouse gelandet ist. Die State Timeline (fachlich) hält fest, ab wann er in der Realität galt. Für die korrigierte und die fehlerhafte E-Mail-Adresse heißt das:
| Inscription Timestamp (Assertion Timeline, technisch) | State Timestamp (State Timeline, fachlich) | E-Mail-Adresse |
|---|---|---|
| 12.05., 14:02 Uhr | vor 12.05., 14:25 Uhr | fehlerhafte Adresse |
| 12.05., 13:58 Uhr | ab 12.05., 14:25 Uhr | korrigierte Adresse |
Die Korrektur ist technisch zuerst angekommen – steht aber fachlich korrekt als der spätere, aktuell gültige Stand da. Die Versandliste zieht jetzt zuverlässig die richtige Adresse. Philomenas Bounces hören auf.
Und es gibt eine zweite Belohnung, die Yerodin sofort sieht. Sein historischer Quartalsbericht bleibt stabil: Zieht er den Q3-Report Monate später noch einmal, zeigt er dieselben Zahlen wie beim Quartalsabschluss – weil die Assertion Timeline nicht mehr von späteren Korrekturen überschrieben wird. „Dann sieht mein Report von damals also auch in einem Jahr noch genauso aus", sagt er. Genau so.
Wie genau das in der Implementierung aussieht – inklusive der SQL-Patterns für End-Dating und Insert-Only – ist ein Modul im Temporal Data Training.
Was sich in der Implementierung ändert
An der grundlegenden Tabellenstruktur ändert sich weniger, als viele befürchten – es ist immer noch ein Warehouse. Zwei Dinge solltest du als Engineer aber kennen.
Das erste ist End-Dating statt Update. Du überschreibst eine bestehende Zeile nicht. Du beendest ihre fachliche Gültigkeitsperiode und schreibst den neuen Stand als eigene Zeile dazu. Damit bleibt jede Version sichtbar, statt von der nächsten verdeckt zu werden.
Das zweite ist die Insert-Only-Logik. Deine temporale Tabelle wächst nur, sie verändert vorhandene Zeilen nicht. Eine Korrektur wie der Adresswechsel führt nicht zu einem Update, sondern zu mehreren neuen Zeilen – je nachdem, wie sich die fachlichen Zeitperioden überlappen.
Womit das nächste Stichwort fällt: Überlappung. Wie sich Zeitperioden zueinander verhalten können, beschreibt die sogenannte Allen Relationship – und sie ist das Herzstück von Teil 2 dieser Serie.
Drei Fragen, mit denen du dein Projekt prüfst
Bevor du entscheidest, ob dich Late Arrivals betreffen, lohnen sich drei nüchterne Fragen an die eigene Architektur.
Erstens: Liegen zwischen euren Quellsystemen und dem Warehouse asynchrone Strecken – Bussysteme, Queues, Schnittstellen, die keine Reihenfolge garantieren? Wenn ja, ist die Frage nicht ob, sondern wann.
Zweitens: Wie geht ihr heute mit Korrekturen um? Wird der alte Wert überschrieben, oder entsteht eine neue Version? Ein Überschreiben ist das deutlichste Symptom dafür, dass Historie verloren geht.
Drittens: Bleiben eure historischen Reports stabil, wenn man sie Monate später noch einmal zieht? Wenn der Bericht vom letzten Quartal heute andere Zahlen zeigt – dann hast du das Problem bereits, du hast es nur noch nicht benannt.
Amal fasst es für das Team zusammen: „Für uns heißt das konkret – wenn so eine Korrektur reinkommt, überschreiben wir die alte Zeile nicht. Wir sortieren sie über die State Timeline an die richtige Stelle ein. Dann stimmt der Report wieder mit der Realität überein, egal in welcher Reihenfolge die Daten ankommen."
Über diese Serie: Dies ist Teil 1 von 4 unserer Serie „Bitemporale Daten in der Praxis", die vom konkreten Engineering-Schmerz bis zur strategischen Entscheidung führt. Den Überblick über alle vier Schwerpunkte gibt der Hub-Artikel „8 Gründe, warum man bitemporale Daten benötigt". Teil 2 nimmt sich den technischen Kern vor: Zeitreisen im Data Warehouse und die Allen Relationship.
Late Arrivals im eigenen Projekt?
Im Temporal Data Training zeige ich anhand realer Wechselkurs- und E-Mail-Korrekturen, wie bitemporale Historisierung Late Arrivals sauber einsortiert – ohne deine Reports zu verfälschen. Das Training wird gerade neu aufgezeichnet.
→ In die Warteliste eintragen (mit Early-Bird-Vorteil als Serien-Leser)
Akutes Late-Arrival-Problem im laufenden Projekt? Manchmal hilft ein kurzes Coaching schneller als ein ganzes Training: temporal.tedamoh.com/coaching
Damit ist die erste Frage beantwortet. Late Arrivals sind kein Sonderfall, den man von Hand ausbügelt – sie sind der Normalfall in jeder Architektur mit asynchronen Strecken, und der Grund, warum eine Zeitlinie nicht reicht.
Heute ging es um das Was und das Warum. Das Wie folgt in Teil 2: Wenn zwei Zeitlinien sauber ineinandergreifen sollen, müssen ihre Zeitperioden in eine klare Beziehung zueinander gebracht werden – mit allen Fällen, in denen sie sich überlappen, berühren oder einschließen. Genau diese Mechanik schauen wir uns als Nächstes an.
So long,
Dirk