Daten-Snapshots versionieren unveränderliche Parquet-Stände für ehrliche Backtests.

Hinter jedem Backtest steht ein stilles Versprechen: Die Daten, gegen die getestet wird, sind dieselben wie beim letzten Mal. In der Praxis ist dieses Versprechen fast immer gebrochen, ohne dass es jemand merkt. Marktdaten ändern sich rückwirkend — Vendoren korrigieren Fehlprints, fügen verspätet eingegangene Ticks ein, passen historische Kurse an Corporate Actions an. Wer seinen Backtest immer gegen „die aktuelle Datenbank“ laufen lässt, vergleicht heute Äpfel mit den Birnen von gestern und wundert sich, warum dieselbe Strategie plötzlich andere Zahlen liefert. Unveränderliche, versionierte Daten-Snapshots lösen genau dieses Problem: Sie frieren einen Datenstand ein, geben ihm eine eindeutige Kennung und sorgen dafür, dass ein Backtest morgen exakt dasselbe rechnet wie heute. Dieser Beitrag erklärt, warum sich gerade das Parquet-Format dafür eignet, wie eine saubere Snapshot-Architektur aussieht, was sie an Speicher kostet — und wo ihre Grenzen liegen.

Warum sich Daten unter Ihren Füßen verändern.

Die Vorstellung, historische Marktdaten seien fix, ist ein verbreiteter Irrtum. Tatsächlich sind sie ständig in Bewegung — nur leise. Ein Vendor entdeckt einen fehlerhaften Tick und korrigiert ihn rückwirkend. Ein verspätet eingegangener Trade wird nachträglich in den richtigen Zeitraum einsortiert. Ein Aktiensplit zwingt dazu, die gesamte historische Kursreihe neu zu adjustieren. Fundamentaldaten werden nach Bilanz-Restatements überschrieben.

Jede dieser Änderungen ist für sich genommen sinnvoll und korrekt. Das Problem entsteht erst, wenn ein Backtest gegen diese sich verändernde Quelle läuft. Dann ist das Ergebnis nicht mehr eine Funktion allein der Strategie, sondern auch des zufälligen Zeitpunkts, zu dem man die Daten gezogen hat.

Konkret: Sie testen eine Strategie im Januar, bekommen einen Sharpe von 1,4. Im April testen Sie denselben Code, bekommen 1,2 — und verbringen Tage damit, einen Bug in der Strategie zu suchen, der gar nicht existiert. Die Differenz kam allein daher, dass sich der Datenstand zwischen Januar und April verändert hat.

Was ein unveränderlicher Snapshot leistet.

Ein Snapshot ist eine Kopie des Datenstands zu einem bestimmten Zeitpunkt, die danach nie wieder verändert wird — Immutability ist das Kernprinzip. Einmal geschrieben, ist ein Snapshot eingefroren. Korrekturen führen nicht dazu, dass man ihn überschreibt, sondern dazu, dass man einen neuen Snapshot anlegt. Der alte bleibt als Referenz bestehen.

Jeder Snapshot bekommt eine eindeutige Version — ein Zeitstempel, eine fortlaufende Nummer oder, am robustesten, ein Hash über den Inhalt. Ein Backtest referenziert dann nicht „die Daten“, sondern „Snapshot v2026-03-14, Hash abc123“. Damit wird der Datenstand ein expliziter, nachvollziehbarer Teil des Experiments — genau wie der Code-Commit.

Der unmittelbare Gewinn: Reproduzierbarkeit. Egal, wann man den Backtest erneut startet, er läuft gegen denselben eingefrorenen Stand. Eine Abweichung im Ergebnis kann dann nicht mehr an stillen Datenkorrekturen liegen — sie muss eine andere, suchbare Ursache haben. Das allein spart in der Fehlersuche enorm viel Zeit.

Warum gerade Parquet das passende Format ist.

Parquet ist ein spaltenorientiertes, komprimiertes Dateiformat, das sich für Marktdaten-Snapshots aus mehreren Gründen anbietet. Erstens die Spaltenorientierung: Backtests lesen typischerweise wenige Spalten über viele Zeilen — etwa nur Close und Volume über Jahre hinweg. Parquet liest dann nur diese Spalten von der Platte, statt jede Zeile vollständig zu laden, was die Ladezeiten drastisch senkt.

Zweitens die Kompression: Marktdaten sind hochgradig komprimierbar, weil benachbarte Werte sich ähneln. Parquet erreicht oft Kompressionsraten, die den Speicherbedarf gegenüber CSV um den Faktor fünf bis zehn reduzieren — was die scheinbar verschwenderische Idee, viele Snapshots aufzubewahren, überhaupt erst bezahlbar macht.

Drittens das eingebaute Schema: Eine Parquet-Datei trägt ihre Spaltentypen in sich. Ein Float bleibt ein Float, ein Zeitstempel ein Zeitstempel — anders als bei CSV, wo jedes Einlesen die Typen neu erraten muss und dabei Fehler einbaut. Das Schema macht Snapshots selbstbeschreibend und robuster gegen stille Parsing-Fehler.

Eine saubere Snapshot-Architektur.

Eine praxistaugliche Architektur folgt einigen klaren Prinzipien, die zusammen die Garantie ergeben:

• Append-only, nie überschreiben: Ein neuer Datenstand erzeugt einen neuen Snapshot. Bestehende Dateien bleiben unangetastet. So kann ein laufender Backtest nie unter dem ihm zugrunde liegenden Stand wegrutschen.
• Partitionierung nach Zeit und Symbol: Snapshots werden nach Datum und Instrument in Verzeichnisse zerlegt. Das erlaubt es, gezielt nur die benötigten Partitionen zu laden, statt jedes Mal alles.
• Inhalts-Hash als Kennung: Ein Hash über die Daten dient als Version. Identischer Inhalt ergibt denselben Hash — man erkennt sofort, ob sich zwischen zwei Ständen überhaupt etwas geändert hat.
• Manifest pro Snapshot: Eine Metadaten-Datei hält fest, woher die Daten stammen, wann sie gezogen wurden und welche Korrekturen gegenüber dem Vorgänger enthalten sind.

Wer mehr Komfort will, kann etablierte Daten-Versionierungs-Werkzeuge oder Tabellenformate mit eingebauter Zeitreise nutzen. Für viele mittelgroße Setups reicht aber schon eine disziplinierte, manuell gepflegte Parquet-Struktur mit Manifesten — wichtig ist die Disziplin, nicht das teuerste Werkzeug.

Der Speicher-Kompromiss: viele Snapshots kosten Platz.

Der offensichtliche Einwand: Wenn man bei jeder Datenkorrektur einen neuen, vollständigen Snapshot anlegt, explodiert der Speicherbedarf. Das stimmt im naiven Fall — und ist der Grund, warum man die Strategie an die Realität anpassen muss.

In der Praxis ändert sich zwischen zwei Ständen meist nur ein winziger Bruchteil der Daten. Es lohnt sich daher selten, den kompletten historischen Stand jedes Mal neu zu kopieren. Stattdessen schreibt man neue oder korrigierte Partitionen als neue Dateien und lässt unveränderte Partitionen referenziert weiterbestehen. So wächst der Speicher nur mit dem tatsächlich Geänderten, nicht mit der gesamten Historie.

Dazu kommt eine Aufbewahrungspolitik: Nicht jeder Snapshot muss ewig leben. Snapshots, die zu veröffentlichten Ergebnissen oder produktiven Strategien gehören, bewahrt man dauerhaft auf; rein explorative Zwischenstände kann man nach einer Frist verwerfen. Mit Parquet-Kompression und dieser Disziplin bleiben die Kosten für die meisten mittelständischen Setups überschaubar — der Speicher ist selten der Engpass, die Disziplin ist es.

Snapshots im Backtest-Workflow verankern.

Ein Snapshot nützt nur, wenn der Backtest ihn auch tatsächlich referenziert, statt heimlich doch gegen die Live-Datenbank zu laufen. Der saubere Weg: Der Backtest bekommt die Snapshot-Version als Pflichtparameter und verweigert den Start, wenn keine angegeben ist. So kann niemand versehentlich gegen einen beweglichen Stand testen.

Das Ergebnis jedes Laufs wird zusammen mit der verwendeten Snapshot-Version protokolliert. Schaut man später auf eine alte Equity-Kurve, weiß man genau, welcher Datenstand sie erzeugt hat — und kann ihn jederzeit exakt wiederherstellen. Das ist der eigentliche Wert: nicht nur, dass Daten unveränderlich sind, sondern dass jedes Ergebnis eindeutig auf einen benannten Stand zurückführbar ist.

Für den Übergang von Backtest zu Live ist das ebenfalls Gold wert. Wenn die Live-Performance abweicht, kann man fragen: Lief der Live-Handel auf demselben Datenstand wie der Backtest? Mit versionierten Snapshots ist das eine beantwortbare Frage statt einer Vermutung.

Grenzen und ehrliche Vorbehalte.

Snapshots lösen das Reproduzierbarkeitsproblem auf der Datenseite — aber nur dort. Sie ersetzen nicht das Pinnen von Code-Abhängigkeiten oder das Fixieren von Zufalls-Seeds; sie sind ein Baustein, kein Komplettpaket. Ein versionierter Datenstand mit einer driftenden Bibliotheksversion ist nur halb reproduzierbar.

Zweitens lösen Snapshots nicht das Problem des Look-Ahead-Bias innerhalb eines Stands. Ein Snapshot friert ein, was die Daten heute zeigen — aber wenn dieser Stand bereits rückwirkend korrigierte Werte enthält, die zum Handelszeitpunkt noch nicht bekannt waren, testet man weiter gegen Wissen aus der Zukunft. Für echte Punkt-in-der-Zeit-Korrektheit braucht es zusätzlich eine bitemporale Sicht darauf, was wann bekannt war. Snapshot-Versionierung und Point-in-Time-Korrektheit sind verwandt, aber nicht dasselbe.

Drittens ist die Disziplin der Knackpunkt, nicht die Technik. Das beste Snapshot-System nützt nichts, wenn jemand „nur kurz“ am Live-Datenstand testet und das Ergebnis als belastbar verkauft. Die Architektur muss den bequemen Weg zum richtigen Weg machen, sonst wird sie umgangen.

Sie wollen sicherstellen, dass Ihre Backtests gegen einen festen, nachvollziehbaren Datenstand laufen statt gegen ein bewegliches Ziel? Unverbindlich anfragen — wir entwerfen gemeinsam eine schlanke Snapshot-Architektur, die zu Ihrem Datenvolumen passt und sich sauber in Ihren Backtest-Workflow einfügt.