Feature Store: Schlüsselinfrastruktur für ML in der Produktion¶

Die meisten ML-Projekte scheitern nicht an einem schlechten Modell, sondern an schlechten Daten in der Produktion. Feature Store löst genau dieses Problem — es ist die Infrastruktur, die sicherstellt, dass Ihr Modell in der Produktion dieselbe Qualität der Features erhält wie beim Training.

Was ist ein Feature Store¶

Ein Feature Store ist ein zentrales Repository und eine Serving-Schicht für ML-Features. Er dient als Brücke zwischen Data Engineering und Data Science.

Kernprobleme, die er löst:

• Training-Serving Skew — Das Modell in der Produktion erhält anders berechnete Features als beim Training
• Feature-Wiederverwendung — Jedes Team berechnet dieselben Features von Grund auf und unterschiedlich
• Point-in-Time-Korrektheit — Beim Training müssen Sie Features von genau diesem Zeitpunkt verwenden, nicht zukünftige Daten
• Online/Offline-Konsistenz — Batch-Features für Training und Echtzeit-Features für Serving müssen identisch sein

Feature-Store-Architektur¶

Ein moderner Feature Store hat zwei Hauptschichten:

Offline Store (Batch)¶

Historische Daten für das Modelltraining. Typischerweise auf einem Data Lake (S3/ADLS + Parquet/Delta Lake).

Raw Data → Feature Pipeline (Spark/dbt) → Offline Store → Training Dataset

Schlüsseleigenschaft: Point-in-Time Joins. Beim Training eines Modells mit Daten aus dem Januar müssen die Features den Werten vom Januar entsprechen — nicht den aktuellen.

Online Store (Echtzeit)¶

Latenzarmes Serving für Produktions-Inference. Typischerweise Redis, DynamoDB oder Cassandra.

Event Stream → Streaming Pipeline (Flink/Spark) → Online Store → Model Serving

Latenz unter 10 ms ist Standard. Für Echtzeit-ML (Betrugserkennung, Empfehlungen, dynamische Preisgestaltung) ist dies entscheidend.

Materialisierung¶

Der Synchronisierungsprozess zwischen Offline und Online Store. Der Feature Store macht automatisch:

1. Berechnet Features aus Rohdaten (Batch und Streaming)
2. Speichert sie im Offline Store mit Zeitstempeln
3. Materialisiert die neuesten Werte in den Online Store
4. Versioniert Schemas und Transformationen

Wichtigste Tools 2026¶

Open-Source¶

Feast — der am weitesten verbreitete Open-Source Feature Store. Python-first, unterstützt AWS, GCP, Azure und On-Prem. Registry in Git (Feature-Definitionen als Code), Offline Store via BigQuery/Redshift/Spark, Online Store via Redis/DynamoDB.

# Feature Store: Schlüsselinfrastruktur für ML in der Produktion
from feast import FeatureView, Entity, Field
from feast.types import Float32, Int64

customer = Entity(name="customer_id", join_keys=["customer_id"])

customer_features = FeatureView(
    name="customer_features",
    entities=[customer],
    schema=[
        Field(name="total_orders_30d", dtype=Int64),
        Field(name="avg_order_value_30d", dtype=Float32),
        Field(name="days_since_last_order", dtype=Int64),
        Field(name="churn_risk_score", dtype=Float32),
    ],
    source=customer_data_source,
    online=True,
    ttl=timedelta(hours=24),
)

Hopsworks — eine vollständige ML-Plattform mit integriertem Feature Store. Stark bei Echtzeit-Features (Streaming-Transformationen).

Managed¶

Tecton — Enterprise-Grade, von den Machern von Ubers Michelangelo. Am besten für Echtzeit-Features.

Databricks Feature Store — native Integration mit Unity Catalog und MLflow.

Wann brauchen Sie einen Feature Store¶

JA — Die Investition zahlt sich aus¶

• Mehrere ML-Modelle in Produktion (>3), die ähnliche Features teilen
• Echtzeit-Inference mit Latenzanforderungen <100 ms
• Mehrere Teams, die mit ML arbeiten und Feature Engineering duplizieren
• Regulierte Umgebung, die Audit Trail und Reproduzierbarkeit erfordert

NEIN — Der Overhead lohnt sich nicht¶

• Sie haben 1-2 Modelle mit Batch-Inference
• Kleines Team, in dem Kommunikation ausreicht
• Experiment- und PoC-Phase
• Features ändern sich nicht und sind einfach

Feature Store im tschechischen Kontext¶

Für tschechische Unternehmen mit 5-50 ML-Modellen empfehlen wir:

Starter-Setup (bis 10 Modelle): - Feast + Redis (Online) + PostgreSQL/S3 (Offline) - Feature-Definitionen in einem Git-Monorepo - CI/CD-Pipeline für Feature-Materialisierung - Gesamtkosten: ~200-500 $/Monat für Infrastruktur

Enterprise-Setup (10+ Modelle): - Feast oder Tecton + dediziertes Streaming (Kafka + Flink) - Delta Lake als Offline Store - Zentraler Feature-Katalog mit Ownership und Dokumentation - Kosten: 2.000-10.000 $/Monat

Monitoring und Observability¶

Ein Feature Store ohne Monitoring ist wie eine Datenbank ohne Backups. Verfolgen Sie:

• Freshness — Sind Features aktuell? Materialisierungs-Lag
• Completeness — Wie viele Null-Werte? Missing Rate pro Feature
• Distribution Drift — Hat sich die Verteilung geändert? PSI (Population Stability Index)
• Latenz — Online Serving p50/p95/p99
• Usage — Welche Features werden von wem genutzt, welche sind tot

Fazit¶

Ein Feature Store ist kein Luxus — er ist eine Notwendigkeit für Unternehmen, die ML zuverlässig in der Produktion betreiben wollen. Starten Sie mit Feast und Redis, richten Sie eine grundlegende Pipeline ein und erweitern Sie nach Bedarf.

Das Wichtigste ist, mit einem Feature-Katalog zu beginnen — einer Liste aller Features mit Dokumentation, Verantwortlichem und Quelle. Auch ohne vollständigen Feature Store spart Ihnen das Dutzende Stunden duplizierter Arbeit.

---

CORE SYSTEMS hilft tschechischen Unternehmen beim Aufbau von ML-Infrastruktur vom Feature Store bis zum Model Serving. Kontaktieren Sie uns für eine Beratung.