Feature Store

Ein Feature Store ist ein zentraler Speicher für die Eingabewerte von Machine-Learning-Modellen (kurz Features, also aus Rohdaten abgeleitete Kennzahlen wie „Bestellungen der letzten 30 Tage"). Er kombiniert einen Offline-Speicher für das Modell-Training mit einem Online-Speicher für schnelle Antworten im Live-Betrieb (Inferenz, das Anwenden des trainierten Modells) und einen Katalog (Registry), der jedes Feature mit Name, Besitzer und Version beschreibt.

Was ist ein Feature Store?

Ein Feature Store ist die Speicher- und Katalog-Ebene einer ML-Architektur (Machine Learning, also Systeme, die aus Daten Muster lernen). Er führt zwei Aufgaben zusammen: die Ablage berechneter Feature-Werte in zwei Geschwindigkeits-Klassen und die zentrale Verwaltung ihrer Beschreibungs-Daten (Metadaten). Ein Feature ist eine aus Rohdaten abgeleitete Eingabegröße für ein Modell, etwa die Summe der Bestellungen eines Kunden in den letzten 30 Tagen, die durchschnittliche Session-Dauer (Dauer eines Nutzer-Besuchs) der vergangenen Woche oder ein in eine Zahl übersetzter Kategorie-Wert (Encoding). Diese Werte werden aus Rohdaten berechnet und müssen sowohl im Training als auch im späteren produktiven Einsatz des Modells verfügbar sein, und dort exakt dieselbe Bedeutung tragen.

Die Referenzarchitektur eines Feature Store besteht aus drei Schichten. Der Offline-Store hält historische Feature-Werte in einem analytischen Format, typisch als Delta-Tabelle, Iceberg-Tabelle oder Parquet-Datei auf Object Storage. Er dient dem Training (Zugriff auf lange Zeitreihen) und der Batch-Inferenz. Der Online-Store hält die aktuellen Feature-Werte in einem Low-Latency-Store, typisch Redis, DynamoDB, Cassandra oder eine integrierte Komponente wie [Databricks Lakebase](https://www.databricks.com/product/lakebase). Er liefert Feature-Werte im einstelligen Millisekunden-Bereich an einen Scoring-Service aus. Die Registry verwaltet Metadaten pro Feature: Name, Owner, Schema, Datentyp, Versionsnummer, Feature-Definition (als Code oder SQL) und Freshness-Angaben. Die Registry macht Features auffindbar, wiederverwendbar und auditierbar.

Der Begriff hat sich als Antwort auf drei wiederkehrende Probleme in produktiven ML-Setups etabliert. Erstens Train-Serve-Skew: dieselbe Kennzahl wird im Trainings-Notebook und im Produktions-Service unterschiedlich berechnet, das Modell fällt im Betrieb ab. Zweitens redundante Feature-Entwicklung: mehrere Teams bauen ähnliche Features (Nutzer-Aktivitätsscore, Kunden-Segment, Session-Wert) neu, weil es keine zentrale Registry gibt. Drittens fehlende Point-in-Time-Korrektheit: historische Trainings-Datensätze lassen sich nicht reproduzierbar erzeugen, weil kein Zugriff auf die zum damaligen Zeitpunkt gültigen Feature-Werte existiert. Der Feature Store adressiert diese Punkte über die gemeinsame Speicher- und Registry-Schicht.

Die konzeptionelle Grundlage geht auf Ubers interne ML-Plattform [Michelangelo](https://www.uber.com/blog/michelangelo-machine-learning-platform/) (2017) zurück. Heute existieren Feature Stores als Open-Source-Framework ([Feast](https://feast.dev/)), als managed SaaS (Tecton, Hopsworks) und als plattformintegrierte Komponente in Lakehouse- und Cloud-Ökosystemen: Databricks Feature Engineering in Unity Catalog kombiniert mit dem Lakebase Online Feature Store, Vertex AI Feature Store, SageMaker Feature Store.

Abgrenzung zu Feature Platform, Feature Engineering und Data Warehouse

Der Begriff „Feature Store" wird in der Praxis oft synonym mit „Feature Platform" verwendet und mit „Feature Engineering" vermischt. Die Abgrenzung sitzt an klaren funktionalen Grenzen.

Der Unterschied zwischen Feature Store und Feature Platform ist der zwischen Speicherkomponente und End-to-End-Framework. Der Feature Store ist die Persistenz- und Registry-Schicht. Die Feature Platform enthält den Feature Store als Teilkomponente und ergänzt ihn um eine Compute-Engine (Batch- und Streaming-Berechnung von Features), eine Feature-Serving-API (Millisekunden-Auslieferung per REST oder gRPC), Point-in-Time-Join-Funktionalität und ein Feature-Monitoring. Die Databricks-Terminologie führt diese Trennung nicht scharf durch und subsumiert beide Ebenen unter „Feature Store" plus „Feature Engineering in Unity Catalog".

Feature Engineering ist die methodische Aktivität, aussagekräftige Merkmale aus Rohdaten abzuleiten (Aggregationen, Encodings, Fenster-Operationen, Interaktions-Features). Der Feature Store ist die Infrastruktur-Komponente, die das Ergebnis dieser Aktivität persistiert, versioniert und ausliefert. Feature Engineering findet vor dem Feature Store statt (in einem Notebook, einer Pipeline oder einer Feature-Definition), der Feature Store hält das Ergebnis vor.

Gegenüber einem Data Warehouse hat der Feature Store ML-spezifische Semantik. Ein Warehouse dient dem SQL-basierten Zugriff auf modellierte Business-Daten (Fact-/Dimension-Tabellen, dimensionale Modellierung); Konsumenten sind BI-Tools und analytische Abfragen. Der Feature Store liefert dagegen Feature-Vektoren an ML-Modelle, hält einen Online-Zwilling für Low-Latency-Inferenz vor und garantiert Point-in-Time-Korrektheit über einen Zeitstempel pro Feature-Wert. Ein Warehouse kann als Rohdatenquelle für die Feature-Berechnung dienen, ersetzt den Feature Store aber nicht.

Beispiel: Online- und Offline-Speicher für ein Churn-Modell

Ein B2B-SaaS-Unternehmen betreibt ein Churn-Modell für Bestandskunden. Das Modell konsumiert 25 Features pro Kunde: Nutzungs-Aggregate über 7, 30 und 90 Tage, Ticketvolumen aus dem Support-System, Verhältnis geöffneter Support-Tickets zu Aufträgen, Anzahl Tage seit letztem Sales-Kontakt und kategorische Kunden-Attribute (Branche, Vertragstyp) per Target-Encoding.

Der Feature Store organisiert diese 25 Features in einer zentralen Registry innerhalb von Unity Catalog. Jedes Feature hat einen Owner, ein Schema, eine Versionsnummer und eine deklarative Definition in Python oder SQL. Ein täglicher Batch-Job berechnet die Feature-Werte aus Silber- und Gold-Tabellen und schreibt sie in eine Delta-Tabelle im Offline-Store, gekeyed auf Kundenkonto-ID plus Referenzdatum. Diese Tabelle ist die Quelle für das Training: Beim Aufbau eines Trainings-Datensatzes führt der Feature Store einen Point-in-Time-Join durch, sodass für jede historische Beobachtung die zum damaligen Datum gültigen Feature-Werte gezogen werden statt der heutigen.

Für ein tagesaktuelles Scoring der aktiven Kunden reicht der Offline-Store. Sollte das Unternehmen später auf Session-basiertes Scoring umstellen (Alarm bei sinkender Nutzung innerhalb einer laufenden Session), kommt ein Online-Store hinzu: Ausgewählte Features werden aus der Delta-Tabelle in einen Lakebase Online Feature Store repliziert und stehen dem Scoring-Service in Millisekunden per Feature-Serving-API bereit. Die Feature-Definitionen bleiben dieselben; nur das Auslieferungs-Ziel ändert sich, sodass Training und Inferenz auf identische Werte zugreifen.