← Alle Insights
MLOps · 9 Min · Juli 2032

Feature Stores für Quant-Trading: Daten-Infrastruktur, die skaliert.

Eine Strategie mit drei Features kommt mit einem Notebook aus. Bei fünfzehn Strategien, die über Wochen, Monate und verschiedene Modelle dieselben rollierenden Volatilitäten, Order-Flow-Imbalances und Macro-Daten brauchen, wird Daten-Logistik zum Engpass. Feature Stores sind die Antwort, die das ML-Team von Uber 2017 erfunden hat — und die auch in kleinen Quant-Setups Sinn ergibt, sobald die Strategie-Zahl wächst.

Was ein Feature Store leistet.

Ein Feature Store ist eine zentrale Schicht, die drei Dinge bündelt:

Die entscheidende Eigenschaft: Offline und Online sehen dieselbe Definition. Wer ein Feature offline ändert (etwa die Lookback-Fenster-Länge), muss bewusst beide Stores migrieren. Das eliminiert die häufigste Quelle stiller Bugs in ML-Pipelines: Training-Serving-Skew.

Die etablierten Tools 2032:

Online- vs. Offline-Serving.

Beim Backtest will ich tausende Feature-Werte über Jahre für hunderte Symbole holen. Latenz ist egal, Durchsatz und Joinability zählen. Beim Live-Modell will ich für ein einzelnes Symbol den aktuellsten Wert in <10 ms — Durchsatz egal, Latenz alles.

Feature Stores lösen das mit zwei separaten Engines: 

# Offline (Backtest, Training): Parquet auf S3 / Snowflake
historical_features = store.get_historical_features(
    entity_df=order_timestamps,
    features=[
        "vol_features:realized_vol_5min",
        "vol_features:realized_vol_1d",
        "flow_features:order_imbalance_30s",
        "macro_features:vix_close",
    ],
).to_df()

# Online (Live): Redis-Lookup mit ~2 ms p99
online_features = store.get_online_features(
    entity_rows=[{"symbol": "MSFT"}],
    features=[
        "vol_features:realized_vol_5min",
        "flow_features:order_imbalance_30s",
    ],
).to_dict()

Beide Aufrufe nutzen dieselbe Feature-Definition aus dem Registry. Wenn die Berechnung von realized_vol_5min sich ändert, fliegt sie als neue Version durch beide Pipelines.

Time-Travel Joins: warum Backtests sonst lügen.

Das größte Bug-Risiko im Quant-Backtest ist Lookahead-Bias: ein Feature in der Trainings-Tabelle, das zur Order-Zeit noch nicht verfügbar war. Klassisches Beispiel: Closing-Price-Feature in einer Intraday-Strategie — der Wert existiert erst nach Marktschluss, im Backtest aber ist er für 14:00 schon da.

Feature Stores lösen das mit Point-in-Time-Joins. Jeder Feature-Wert hat einen event_timestamp (Zeitpunkt des realen Beobachtens) und einen created_timestamp (Zeitpunkt, zu dem er materialisiert wurde). Beim Join gegen eine Order-Tabelle holt der Store nur Werte, deren event_timestamp ≤ order_timestamp ist — und respektiert Datenverfügbarkeits-Latenzen (etwa: VIX-Tagesschluss erst um 16:15 verfügbar). 

from feast import FeatureView, Field
from feast.types import Float32
from datetime import timedelta

vol_features_fv = FeatureView(
    name="vol_features",
    entities=[symbol_entity],
    ttl=timedelta(days=7),
    schema=[
        Field(name="realized_vol_5min", dtype=Float32),
        Field(name="realized_vol_1d",   dtype=Float32),
    ],
    source=vol_features_source,
    # delivery_lag: Daten sind erst N Sekunden nach event_time real verfügbar
    online=True,
)

Feature Drift Detection.

Features verschieben sich. Vola-Regimes ändern sich, Liquidität ändert sich, Cross-Asset-Korrelationen ändern sich. Wenn Ihr Modell auf Daten trainiert wurde, die heute nicht mehr representativ sind, sinkt die Predictive Power, ohne dass es im Trade-Log offensichtlich wäre.

Feature Stores ermöglichen systematische Drift-Detection, weil sie alle Feature-Werte historisch halten. Typische Metriken:

Drift-Checks laufen als Nightly-Job über den Offline-Store und schreiben in einen Monitoring-Channel. Feast-Erweiterungen wie great_expectations-Integration oder Tecton's eingebautes Monitoring erleichtern das.

Eigene Lösung oder Managed Service?

Die ehrliche Antwort hängt von der Team-Größe und vom Strategie-Reuse ab. Eine grobe Heuristik aus meiner Beratungspraxis:

Was ich nicht empfehle: einen Feature Store „auf Vorrat" einführen, bevor mehrere Strategien existieren, die wirklich dieselben Features teilen. Vorher ist es Over-Engineering.

Konkretes Setup: Feast + TimescaleDB + Redis.

Mein Standard-Setup für Quant-Mandanten mit 5–15 Strategien: 

# Architektur
- Offline Store:  TimescaleDB (PostgreSQL + Time-Series-Extension)
- Online Store:   Redis (cluster, in-memory)
- Registry:       PostgreSQL
- Compute:        Python-Pipelines (Airflow oder Dagster)
- Stream-Layer:   Kafka oder Redpanda, falls Intraday-Features

# Tägliche Materialisierung
0 5 * * *  feast materialize-incremental $(date -I)

# Verzeichnis-Struktur
features/
  entities.py          # symbol, exchange, strategy_id
  vol_features.py      # realized vol, GARCH, vola-of-vola
  flow_features.py     # OFI, depth-imbalance, volume-burst
  macro_features.py    # VIX, MOVE, DXY, term-structure
  feast_repo.yaml      # Feast-Repo-Konfiguration
  tests/
    test_no_lookahead.py
    test_schema.py

TimescaleDB ist hier der Schlüssel: native Time-Series-Indizes, Compression-Policies, Continuous-Aggregates. Backtests, die früher 20 Minuten gebraucht haben, laufen darauf in 30 Sekunden. Redis hält die letzten paar Stunden warm, p99-Lookup-Latenz zuverlässig unter 5 ms.

Meine Praxis.

Bei einem Mandanten letztes Jahr: 7 Strategien, alle mit überlappenden Vola- und Flow-Features, jede in ihrem eigenen Notebook neu berechnet, jedes Mal leicht anders. Konsequenz: in einem Live-Trade wurde eine 5-Min-Vola berechnet mit 5 statt 6 Bar-Lookback, Strategie verlor 0,4 % am Tag, niemand wusste warum. Drei Tage Suche.

Nach dem Feast-Setup: alle Strategien teilen dieselben Feature-Definitionen, jede Änderung läuft durch Code-Review, jede Version ist im Registry nachvollziehbar. Backtests sind reproduzierbar, weil die Feature-Werte historisch eingefroren sind. Aufwand für den Wechsel: 9 Tage. Ich behaupte: ab etwa 10 ernsthaft betriebenen Strategien ist ein Feature Store keine Option, sondern Hygiene.

Für kleinere Setups bleibt der Pragmatismus: ein gut strukturiertes features/-Verzeichnis mit getesteten Funktionen, Parquet-Cache und Schema-Tests. Aber die Schwelle, ab der ein Feature Store schwarze Zahlen schreibt, kommt schneller, als man denkt.

Sie skalieren Ihre Quant-Pipeline und merken, dass Daten-Logistik der Engpass wird? Erstgespräch buchen — wir entwerfen ein Feature-Store-Setup, das zur Team-Größe passt.