Zum Hauptinhalt springen

Feature Store

Zweck

Der Feature Store stellt versionierte, wiederverwendbare Features für Training und Serving bereit. Er ist der verbindliche Übergabepunkt zwischen Warehouse und Modell-Lifecycle und erzwingt Konsistenz von Feature-Definition, DQ-Status und Lineage.

⋮⋮⋮

BPMN-Kontext

  • IDs: CallActivity_FeaturePipeline
  • Input-Bezug: DQ-freigegebene Warehouse-Datensätze inkl. Contract-/Schema-Version.
  • Entscheidungsbezug: Veröffentlichung nur bei erfüllten Feature-DQ- und Drift-Grenzen.
  • Output-Bezug: Versionierter Feature-Snapshot für Training, Backtesting und Online-Serving.

Feature Contract (Pflicht)

Jede Feature-Gruppe wird mit einem Feature Contract veröffentlicht:

FeldBeschreibung
feature_set_idEindeutige ID der Feature-Gruppe
feature_definitionsName, Formel, Datentyp, Einheiten, erlaubte Nullwerte
offline_online_parityNachweis identischer Berechnungslogik
source_lineageReferenz auf Warehouse-Datasets + Versionen
dq_profileSchwellwerte für Missingness, Outlier, Drift
ownerVerantwortliche Rolle für Wartung und Freigaben

Versionierung

  • Neue Features oder semantische Änderungen erzeugen eine neue feature_set_version.
  • Historische Versionen bleiben für Reproduzierbarkeit von Backtests und Model Audits verfügbar.
  • Trainingsläufe müssen feature_set_id und exakte feature_set_version referenzieren.
  • Rollback erfolgt über veröffentlichte Vorgängerversion, nicht über ad-hoc Hotfix ohne Version.

DQ-Übergabe an Training/Scoring

  1. Warehouse-Input wird gegen Feature-Contract validiert.
  2. Feature-DQ (Verteilung, Nullanteil, Drift gegen Baseline) wird berechnet.
  3. Nur publishable-Snapshots werden in Registry/Store freigegeben.
  4. Abweichungen werden mit Grundcode und Entscheidung protokolliert.

Incident-Verknüpfung

  • Kritische Feature-DQ-Verletzungen erzeugen ein Incident-Ticket mit Impact auf abhängige Modelle.
  • Incident enthält mindestens: feature_set_version, betroffene Modelle, letzte gesunde Version, Recovery-Plan.
  • Nach Incident wird der Contract oder die DQ-Baseline angepasst und als neue Version dokumentiert.

Anforderungen

  • Reproduzierbarkeit nach Datum und Version.
  • Nachvollziehbare Lineage vom Feature bis zur Quelle.
  • Einheitliche Contracts für domänenübergreifende Wiederverwendung.

Siehe auch: Warehouse, Label Construction, Glossary, Traceability Matrix.