Erstellung von Feature-Pipelines

Was macht Erstellung von Feature-Pipelines?

Wann verwenden

• Entwicklung von Features für ML-Modelle aus Warehouse-/Stream-Daten.
• Vermeidung von Label-Leakage und Train/Serve-Skew.
• Einrichtung eines Feature Stores, Online-Serving oder historischer Backfills.
• NICHT verwenden für allgemeine Modellierung/Aggregation (verwende dbt/Spark-Skills), es sei denn, es dient ML-Features.

Workflow

- [ ] Definiere jedes Feature mit einem Entity-Key und einem Ereigniszeitstempel
- [ ] Erstelle Trainingsdatensätze mit point-in-time-korrekten Joins (zum Zeitpunkt des Labels)
- [ ] Teile EINE Definition für offline (Training) und online (Serving)
- [ ] Lege Frische/Materialisierung für Online-Features fest
- [ ] Führe idempotente Backfills historischer Features für das Training durch

1. Point-in-time-Korrektheit. Verknüpfe Features zum Zeitstempel jedes Labels – verwende nur Daten, die vor dem Vorhersagezeitpunkt bekannt waren. Dies verhindert Label-Leakage, den schädlichsten Feature-Bug.
2. Offline/Online-Parität. Berechne ein Feature auf die gleiche Weise für Training (offline, Batch) und Serving (online, niedrige Latenz). Unterschiedliche Logik führt zu Train/Serve-Skew und stiller Produktionsverschlechterung.
3. Frische. Online-Features müssen nach einem Zeitplan materialisiert werden, der die Toleranz des Modells gegenüber Veralterung erfüllt.
4. Idempotente Backfills. Die Neuberechnung historischer Features muss wiederholbar sein (siehe designing-backfills-and-replays).

Muster

Point-in-time (as-of)-Join – wähle den neuesten Feature-Wert strikt vor jedem Label-Ereignis:

SELECT l.entity_id, l.label_ts, f.value AS feature
FROM labels l
LEFT JOIN features f
  ON f.entity_id = l.entity_id
 AND f.event_ts <= l.label_ts          -- nur vergangene Daten; kein Leakage
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY l.entity_id, l.label_ts ORDER BY f.event_ts DESC) = 1;

Einzelne Definition, zwei Pfade – definiere das Feature einmal (z. B. Feast FeatureView); materialisiere es in einem Offline-Store für Training und einem Online-Store für Serving, sodass beide identische Logik verwenden.

Frische + Materialisierung – plane die Materialisierung online; überwache die Feature-Frische wie jedes Dataset-SLA (implementing-pipeline-observability).

Häufige Fallstricke

• Label-Leakage – das Verknüpfen von Features, die nach dem Label-Zeitpunkt berechnet wurden, überhöht Offline-Metriken und bricht in der Produktion zusammen; verwende immer as-of-Joins.
• Train/Serve-Skew – getrennte Offline- und Online-Implementierungen driften auseinander; teile eine Definition.
• Veraltete Online-Features – das Modell serviert auf alten Werten; setze und überwache die Frische.
• Nicht reproduzierbare Backfills – inkonsistente Trainingshistorie; mache die Feature-Neuberechnung idempotent.
• Fehlende Entity-/Zeitstempel-Schlüssel – Features können nicht korrekt über die Zeit verknüpft werden; erfordere beide.
• Unversionierte Features – stille Neudefinition bricht die Modellvergleichbarkeit; versioniere Feature-Definitionen.