Real-Time Feature Store Architektur für MLOps: Vergleich 2026

TL;DR: Feature Stores trennen Feature-Engineering von Training und Serving — der Schlüssel gegen Training-Serving-Skew. Dual-Store-Pattern: Offline (Delta, BigQuery) fürs Training, Online (Redis, DynamoDB) für Sub-10ms-Serving. 2026-Landschaft: Databricks+Tecton (nach 900M$-Akquisition), Feast (OSS), SageMaker FS, Vertex AI FS.

Dein Modell scort 95 % im Notebook. In Produktion degradiert es still auf 78 % — und drei Wochen lang merkt es niemand. Der Übeltäter ist nicht das Modell. Es sind die Features.

Real-Time-Feature-Stores lösen das härteste Infrastruktur-Problem in produktiver ML: konsistente, frische Features mit niedriger Latenz servieren, während Training- und Serving-Pipelines synchron bleiben. Wer mehr als nur Batch-Modelle baut, kann diesen Layer nicht überspringen.

TL;DR für busy Architects

• Ein Feature-Store trennt Feature-Engineering von Modell-Training und Modell-Serving — schafft einen wiederverwendbaren, governed Feature-Layer
• Das Kern-Architektur-Pattern: Dual-Store-Design — Offline-Store fürs Training (spaltenbasiert, hoher Throughput) und Online-Store für Inference (Key-Value, niedrige Latenz)
• Training-Serving-Skew — der #1-Silent-Killer von ML-Systemen — wird eliminiert, indem Features einmal berechnet und konsistent serviert werden
• Nach Databricks' Tecton-Akquisition (~900M $, Aug 2025) hat sich der Feature-Store-Markt um Databricks/Tecton, Feast (OSS), SageMaker Feature Store und Vertex AI Feature Store konsolidiert
• Die Wahl hängt vom Cloud-Commitment, Latenz-Anforderungen und ob du Streaming-Transformationen brauchst

Warum Feature Stores existieren: Das Problem

Die meisten ML-Teams starten gleich: ein Data Scientist schreibt Feature-Logik im Notebook, trainiert ein Modell, übergibt. Das Engineering-Team schreibt die Logik in einer Serving-Sprache neu. Jetzt hast du zwei Implementierungen desselben Features — eine in Python/Pandas, eine in Java/Go/SQL.

Sie driften. Still.

Das ist Training-Serving-Skew, und es ist für mehr produktive ML-Failures verantwortlich als schlechte Modelle. Ein Feature-Store eliminiert das, indem er zur Single Source of Truth für Feature-Berechnung, -Speicherung und -Abruf wird.

Jenseits der Skew-Vermeidung lösen Feature-Stores drei weitere Architekturprobleme:

Kern-Architektur: Das Dual-Store-Pattern

Jeder produktive Feature-Store folgt demselben fundamentalen Pattern — unabhängig vom Vendor. Das Pattern zu verstehen ist wichtiger als die Tool-Wahl.

graph TB
    subgraph Sources["Data Sources"]
        S1["Transactional DB"]
        S2["Event Stream"]
        S3["Data Lake"]
    end

    subgraph Compute["Feature Engineering"]
        B["Batch Pipeline<br/>(Spark, SQL)"]
        ST["Stream Pipeline<br/>(Flink, Spark Streaming)"]
        RT["On-Demand<br/>Transform"]
    end

    subgraph Store["Feature Store"]
        OFF["Offline Store<br/>(Delta Lake, Parquet, BigQuery)"]
        ON["Online Store<br/>(Redis, DynamoDB, Bigtable)"]
        REG["Feature Registry<br/>& Catalog"]
    end

    subgraph Consumers["Consumers"]
        TR["Model Training"]
        INF["Real-Time Inference"]
        AN["Analytics & Monitoring"]
    end

    S1 --> B
    S2 --> ST
    S3 --> B
    S2 --> RT

    B --> OFF
    ST --> ON
    ST --> OFF
    B -->|"materialization"| ON
    RT -->|"request-time"| INF

    OFF --> TR
    ON --> INF
    REG --> TR
    REG --> INF
    OFF --> AN

① Data-Sources füttern Roh-Events und -Records in den Feature-Engineering-Layer.

② Feature-Engineering berechnet Features in drei Patterns: Batch, Streaming und On-Demand.

③ Der Dual-Store ist der architektonische Kern. Offline-Store (Delta, Parquet) bedient Training mit Point-in-Time-korrekten Historiendaten. Online-Store (Redis, DynamoDB) bedient Inference mit den neuesten Feature-Werten in Sub-10-ms-Latenz.

④ Consumers ziehen Features konsistent aus beiden Stores — Training-Jobs aus Offline, Inference-Services aus Online, Monitoring aus beiden.

Offline-Store: für Training optimiert

Der Offline-Store hält die volle Feature-Historie. Beantwortet die Frage: "Was waren die Features dieses Users am 12. März um 15:47?"

Diese Point-in-Time-Korrektheit ist für valides Modell-Training nicht verhandelbar. Ohne sie leaken Zukunfts-Infos in Trainingsdaten (Label-Leakage), und dein Modell performt im Backtest unrealistisch gut, fällt in Produktion aber um.

Technologie-Optionen:

• Delta Lake / Iceberg — am besten für Lakehouse-Architekturen. Time-Travel eingebaut. Native Spark-Integration.
• BigQuery — starke Wahl für GCP-native Teams. Partitionierte Tabellen mit Snapshot-Semantik.
• S3 + Parquet + Athena — Budget-Option für AWS. Mehr Glue-Code für Time-Travel nötig.

Online-Store: fürs Serving optimiert

Der Online-Store hält nur die neuesten Feature-Werte pro Entität. Beantwortet: "Was sind die Features dieses Users jetzt?"

Latenz-Ziele: p99 < 10 ms für die meisten Real-Time-ML-Use-Cases (Fraud-Detection, Recommendations, Pricing).

Technologie-Optionen:

• Redis / Valkey — niedrigste Latenz, höchste Kosten pro GB. Am besten für Small/Medium-Feature-Sets.
• DynamoDB — AWS-native, Auto-Scaling, vorhersehbarer Preis bei Scale. Gut für große Feature-Sets.
• Bigtable — GCP-native, exzellent für Wide-Rows mit vielen Features pro Entität.
• Cassandra — Multi-Cloud, OSS. Höherer Operations-Aufwand, aber kein Vendor-Lock.

Drei Feature-Freshness-Patterns

Nicht jedes Feature braucht Sub-Sekunden-Aktualität. Das richtige Pattern pro Feature zu wählen, ist die einflussreichste Architektur-Entscheidung.

Pattern 1: Batch-Features (Minuten bis Stunden)

Berechnet auf Schedule (stündlich, täglich). Beispiele: 30-Tage-Purchase-Count, Avg-Session-Duration, Credit-Score.

Architektur: Spark/SQL-Job → schreibt in Offline-Store → Materialization-Job kopiert neueste Werte in Online-Store.

Wann nutzen: Features, die sich langsam ändern, wo Staleness von Stunden okay ist. Deckt 70–80 % der Features in den meisten Systemen.

Pattern 2: Streaming-Features (Sekunden bis Minuten)

Kontinuierlich aus Event-Streams berechnet. Beispiele: Rolling-5-Min-Click-Count, Realtime-Cart-Value, Session-Event-Count.

Architektur: Kafka/Kinesis → Flink/Spark Streaming → schreibt simultan in Offline und Online.

Wann nutzen: Features aus aktivem User-Verhalten. Fraud-Detection, Realtime-Personalisierung, Dynamic Pricing.

Pattern 3: On-Demand-Features (Request-Zeit)

Zur Inference-Zeit berechnet, nicht pre-materialisiert. Beispiele: Time-since-last-Event, Geo-Distance User-Merchant, Request-spezifische Embeddings.

Architektur: Feature-Logik läuft im Serving-Layer beim Prediction-Request. Results können gecached werden, aber nicht langfristig gespeichert.

Wann nutzen: Features, die vom Request-Kontext abhängen, sich zu schnell für Pre-Computation ändern oder zu viele Entity-Kombinationen für Storage haben.

Pragmatischer Ansatz: Mit Batch für alles anfangen. Auf Streaming hochstufen, nur wenn Staleness messbar Modell-Performance hurt. On-Demand nur, wenn Pre-Computation unmöglich ist.

Feature-Store-Vergleich: 2026-Landschaft

Die Databricks-Tecton-Akquisition (August 2025) hat den Markt deutlich umgeformt.

Databricks Feature Store (+ Tecton)

Nach der Tecton-Akquisition für ca. 900M $ hat Databricks Tectons Real-Time-Feature-Serving in die Lakehouse-Plattform integriert. Features sind jetzt First-Class-Citizens in Unity Catalog, Lineage wird neben Tabellen und Models in MLflow getrackt.

Stärken:

• Tiefste Integration mit Delta Lake, Unity Catalog und MLflow
• Tectons Streaming-Transformation-Engine jetzt eingebaut
• Single-Governance-Layer für Daten und Features
• Batch + Streaming + On-Demand alle nativ unterstützt

Trade-offs:

• Databricks-Lock-in — Features leben im Lakehouse-Ökosystem
• Pricing kann für Streaming-Features (Always-on-Compute) steep werden [PRICING-CHECK]
• Kleinere Community als Feast für Custom-Extensions

Am besten für: Teams schon auf Databricks, die fully-managed, integrierte Feature-Plattform wollen.

Feast (Open Source)

Feast bleibt der führende OSS-Feature-Store. Provider-agnostisch — du bringst eigenen Offline-Store (BigQuery, Snowflake, Redshift, File-basiert) und Online-Store (Redis, DynamoDB, SQLite, Postgres).

Stärken:

• Cloud-agnostisch — läuft überall, kein Vendor-Lock-in
• Starke Community, breites Provider-Ökosystem
• Einfaches Deployment (pip install, keine dedizierte Infrastruktur)
• Gut für Teams mit bestehenden Feature-Pipelines

Trade-offs:

• Keine eingebauten Streaming-Transformationen — du managest Flink/Spark Streaming separat
• Feature-Berechnung ist deine Verantwortung; Feast handelt Storage und Serving
• Monitoring und Observability brauchen zusätzliches Tooling
• Enterprise-Support begrenzt (kein Backing-Company seit Tecton-Akquisition)

Am besten für: Multi-Cloud-Teams, Organisationen, die volle Kontrolle wollen, Teams mit bestehenden Feature-Pipelines.

SageMaker Feature Store (AWS)

Eng mit SageMaker-ML-Plattform integriert. Online- und Offline-Stores mit Auto-Sync.

Stärken:

• Native AWS-Integration (IAM, S3, Glue, Athena)
• Automatisches Offline-Online-Sync
• Feature-Groups mit Schema-Enforcement
• SageMaker-Pipelines-Integration für End-to-End-MLOps

Trade-offs:

• Nur AWS — kein Multi-Cloud-Story
• Streaming-Support begrenzter als Databricks/Tecton
• Online-Store-Latenz höher als Redis-basierte Alternativen (~10–20 ms p99) [VERIFY]
• Weniger flexibel als Feast für Custom-Backends

Am besten für: All-in-AWS-Teams mit SageMaker für Training und Deployment.

Vertex AI Feature Store (GCP)

Googles managed Feature-Store, integriert mit Vertex AI und BigQuery.

Stärken:

• Native BigQuery-Integration als Offline-Store
• Bigtable-backed Online-Serving (niedrige Latenz bei Scale)
• Feature-Monitoring mit Drift-Detection eingebaut
• Starke Integration mit Vertex-AI-Pipelines

Trade-offs:

• Nur GCP
• Streaming-Support weniger reif als Databricks
• Pricing-Komplexität — mehrere Meter (Storage, Serving, Sync) [PRICING-CHECK]
• Kleineres Ökosystem als Feast oder Databricks

Am besten für: GCP-native Teams mit Vertex AI für ML-Workflows.

Vergleichs-Matrix

Entscheidungs-Framework

Skipp die Feature-Matrix — so entscheidest du wirklich.

Brauchst du überhaupt einen Feature-Store?

Nein, wenn:

• Du < 5 Modelle in Produktion hast
• Alle Modelle Batch-Features mit täglicher Freshness nutzen
• Ein einzelnes Team alle ML besitzt — kein Feature-Sharing nötig
• Du pre-Product-Market-Fit bist und wöchentlich Modelle iterierst

Ja, wenn:

• Mehrere Teams dieselben Features brauchen
• Du Real-Time-Features (Sub-Minuten-Freshness) brauchst
• Training-Serving-Skew schon Produktions-Incidents verursacht hat
• Du jenseits 10+ produktiver Modelle skalierst

Welcher?

START
  |
  +-- Schon auf Databricks?      -> Databricks Feature Store (post-Tecton)
  |
  +-- All-in AWS SageMaker?      -> SageMaker Feature Store
  |
  +-- All-in GCP Vertex AI?      -> Vertex AI Feature Store
  |
  +-- Multi-Cloud / volle Kontrolle? -> Feast
  |
  +-- Streaming-Transforms + nicht Databricks? -> Feast + Flink (self-managed)

Ehrliche Einschätzung: Bist du auf Databricks, macht die Tecton-Integration es schwer, etwas anderes zu rechtfertigen. Sonst gibt Feast dir am meisten Flexibilität. Die Cloud-nativen Optionen (SageMaker, Vertex AI) sind okay, wenn du voll auf einer Cloud bist und minimalen Operations-Overhead willst.

Architektur-Anti-Patterns

Features im Serving-Pfad neu berechnen

Wenn dein Modell-Endpoint pro Prediction eine SQL-Query gegen dein Warehouse fährt, hast du keinen Feature-Store — du hast ein Latenz-Problem. Pre-Materialisieren in Online-Store.

Getrennte Feature-Logik für Training und Serving

Sobald du features_training.py und features_serving.java hast, hast du eine Skew-Fabrik. Eine Definition, zwei Stores.

Rohdaten im Online-Store

Der Online-Store sollte berechnete Features halten, keine Roh-Events. Roh-Events gehören in deinen Event-Stream oder Data-Lake.

Freshness über-engineeren

Nicht jedes Feature braucht Streaming. Wenn dein "user_lifetime_value" täglich aktualisiert wird und dein Modell damit gut läuft, bau keine Streaming-Pipeline dafür.

Point-in-Time-Joins im Training überspringen

Wenn deine Training-Pipeline Features per Entity-ID joint, ohne Event-Timestamps zu respektieren, sieht dein Modell die Zukunft. Der häufigste und schädlichste Fehler im Feature-Engineering.

Real-World-Architektur: Fraud-Detection

Konkretes Beispiel — wie ein Real-Time-Fraud-Detection-System einen Feature-Store nutzt:

Das Modell bekommt alle fünf Features in einem einzigen API-Call zum Online-Serving-Endpoint. Total-Latenz-Budget: < 15 ms.

Was kommt: Feature Stores und AI-Agenten

Die Databricks-Tecton-Akquisition war nicht nur um ML-Models — explizit auch um AI-Agenten mit Real-Time-Daten zu powern. Während LLM-basierte Agenten zu produktiven Workloads werden, brauchen sie dieselbe Feature-Infrastruktur wie ML-Models: frische Kontext, niedrige Latenz, konsistente Daten.

Erwarte, dass Feature-Stores sich von "ML-Feature-Serving" zu "Real-Time-Context-Serving" entwickeln — bereitstellen jede AI-System (Model oder Agent) mit dem Entity-Level-Kontext, den es für Entscheidungen braucht.

Tools wie Harbinger Explorer helfen, Roh-API-Daten direkt im Browser zu profilen und abzufragen — nützlich für die Discovery-Phase, bevor du Features im Store formalisierst.

FAQ

Wann lohnt sich ein Feature-Store nicht?

Bei < 5 produktiven Modellen, reinen Batch-Features mit täglicher Freshness oder einem Single-Team-Setup. Pre-PMF: Feature-Store ist Premature-Optimization.

Wie verhindere ich Training-Serving-Skew?

Eine Feature-Definition, zwei Stores. Niemals Feature-Logik in Training und Serving separat. Feature-Definitionen versionieren wie Code.

Können Feature-Stores DSGVO-konform laufen?

Ja — Online-Store mit Per-Entity-Daten erlaubt sauberes Lösch-Handling (Right-to-be-Forgotten). Offline-Store mit Time-Travel braucht Retention-Policies. EU-Region für Storage pinnen.

Was kostet ein Feature-Store realistisch?

Feast OSS: nur Infra (Storage + Compute deiner Cloud). Databricks/Tecton: DBU-basiert, kann bei Streaming-Features schnell 5–10k $/Monat erreichen. SageMaker/Vertex: $/GB + Requests, transparenter aber bei Scale teuer.

Brauche ich beide Stores (Online + Offline)?

Nur Online-Store: Training kann nicht point-in-time-korrekt sein. Nur Offline: kann keine Real-Time-Inference. Für produktive ML: beide.

Key Takeaways

Die Dual-Store-Architektur (Offline für Training, Online für Serving) ist das bewährte Pattern. Mit Batch-Features starten, Streaming nur ergänzen, wenn Freshness Modell-Performance messbar verbessert, und On-Demand-Transforms als Last-Resort für Request-abhängige Features.

Nächster Schritt: auditiere deine aktuelle ML-Serving-Pipeline. Wenn Feature-Logik an mehr als einem Ort lebt, hast du ein Skew-Problem — und ein Feature-Store sollte deine nächste Infrastruktur-Investition sein.

Stand: 14. Mai 2026.