Feature Store auf Databricks: Wiederverwendbare Features und konsistente Modellinputs
Die Kernaussagen auf einen Blick.
- Der Databricks Feature Store umfasst heute zwei zentrale Bereiche: Feature Engineering in Unity Catalog dient der zentralen Verwaltung von Feature-Tabellen für Training und Batch-Inferenz.
- Der Lakebase-basierte Online Feature Store stellt ausgewählte Features für latenzkritische Online-Anwendungen bereit.
- Feature-Tabellen werden als Delta-Tabellen in Unity Catalog mit definiertem Primärschlüssel verwaltet. Über die Feature-Engineering-API können Modelle mit den verwendeten Feature-Tabellen und Lookup-Schlüsseln verknüpft werden.
- Die ältere Online-Tables-Variante wird für bestehende Workloads weiterhin unterstützt, ist für neue Implementierungen jedoch nicht mehr der bevorzugte Ansatz. Für neue latenzkritische Anwendungen sollte der aktuelle Lakebase-basierte Online Feature Store geprüft werden.
- Für neue ML-Anwendungen bietet sich Feature Engineering in Unity Catalog als zentrale Grundlage an. Ein Online Store sollte nur eingesetzt werden, wenn die Anwendung tatsächlich niedrige und verbindliche Antwortzeiten benötigt.
Inhaltsverzeichnis
Euer Modell trainiert auf Zahlen, die es produktiv nie sieht
Mehrere Teams berechnen denselben Customer Lifetime Value mit unterschiedlichen Definitionen. Das Marketing berücksichtigt beispielsweise die vergangenen 24 Monate, ein Risikomodell verwendet 36 Monate und das Churn-Modell nutzt eine weitere Variante mit quartalsweiser Aggregation und abweichenden Filtern. Diese Unterschiede wurden häufig nicht bewusst fachlich entschieden. Die Berechnungslogik verteilt sich auf mehrere Notebooks, Pipelines und Transformationsmodelle, weil die einzelnen Anwendungsfälle schnell umgesetzt werden mussten.
Das Churn-Modell wird mit einer bestimmten Feature-Definition trainiert. Im produktiven Scoring verwendet die Anwendung jedoch eine abweichende Berechnung, weil die Feature-Logik aus einem älteren Notebook übernommen wurde. Einige Zeit später verschlechtert sich die Modellqualität im produktiven Betrieb deutlich. Die Abweichung zwischen Trainings- und Inferenzfeatures wird nicht unmittelbar erkannt, weil die Modellmetriken im Eval-Notebook gut aussehen. Erst eine Analyse der produktiven Eingabedaten macht sichtbar, dass sich Feature-Werte und Verteilungen gegenüber dem Trainingsstand verändert haben.
Zwei Fragen bleiben dabei häufig offen. Welches Team ist für die fachliche und technische Definition eines Features verantwortlich, und wer bewertet spätere Änderungen? Wie wird verhindert, dass ein weiteres Modell erneut eine eigene Variante derselben Kennzahl entwickelt? Ohne zentrale Feature-Verwaltung und klare Verantwortlichkeiten entstehen mehrfach implementierte und nur lokal dokumentierte Berechnungen. Qualitätsprobleme werden dann regelmäßig als Drift sichtbar, obwohl die eigentliche Ursache uneinheitliche Feature-Logik ist.
Was ist der Databricks Feature Store?
Der Databricks Feature Store unterstützt die zentrale Definition, Verwaltung und Bereitstellung von ML-Features. Er hilft dabei, für Training und Inferenz dieselben Feature-Quellen und Lookup-Definitionen zu verwenden. Über die Feature-Engineering-API werden Modelle mit konkreten Feature-Tabellen und Schlüsseln verknüpft. Für latenzkritische Anwendungen kann zusätzlich ein Online Store eingesetzt werden.
Databricks unterscheidet zwischen der älteren workspacegebundenen Variante und Feature Engineering in Unity Catalog. Der Workspace Feature Store ist die frühere, an einen einzelnen Workspace gebundene Lösung und bietet nicht dieselbe Integration in Unity Catalog wie die aktuelle Variante. Für neue Implementierungen wird in der Regel Feature Engineering in Unity Catalog verwendet. Feature-Tabellen werden als reguläre Delta-Tabellen in Unity Catalog mit definierten Schlüsseln verwaltet. Dadurch lassen sich Owner, Berechtigungen und Datenherkunft mit den üblichen Unity-Catalog-Mechanismen verwalten.
Der Feature Store schafft eine gemeinsame Sicht darauf, welche Features existieren, woher sie stammen und wer sie pflegt. Er übernimmt weder das eigentliche Modelltraining noch die Modellversionierung. Modelle entstehen weiter in MLflow, der Modell-Lebenszyklus läuft über die Mosaic AI Model Registry, die Inferenz über Model Serving. Wie diese Schichten zusammenspielen, zeigen wir im Überblick zu Artificial Intelligence auf Databricks.
Architektonisch sitzt der Feature Store als entkoppelnde Schicht zwischen Featurization und den beiden Lese-Pfaden: Training liest die Features per Offline-Lookup aus den UC-Delta-Tabellen, Serving per Online-Lookup aus dem Lakebase-Store. Beide Pfade greifen auf dieselbe Feature-Definition zurück.
Eine entkoppelnde Schicht zwischen Featurization und den beiden Lese-Pfaden: Training und Serving.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Feature-Tabellen in Unity Catalog
Technisch basiert eine Feature-Tabelle auf einer Delta-Tabelle in Unity Catalog mit definiertem Primärschlüssel. Der Schlüssel identifiziert die fachliche Entität, etwa einen Kunden, ein Produkt oder einen Vertrag. Für historische oder zeitabhängige Features kann zusätzlich eine Zeitspalte verwendet werden. Der wesentliche Unterschied zu einer gewöhnlichen Delta-Tabelle liegt in der Feature-Metadaten- und Client-Integration. Ein eindeutiger Lookup-Schlüssel ist definiert, und der Feature Engineering Client kann die Tabelle gezielt für Training und Serving referenzieren.
Erst durch die Nutzung der Feature-Engineering-API wird die Tabelle in den Modellprozess eingebunden. FeatureEngineeringClient.create_table(...) registriert eine Tabelle als Feature-Tabelle. Ein FeatureLookup beschreibt Quelle, Lookup-Schlüssel und benötigte Feature-Spalten. create_training_set(...) verbindet den Label-Datensatz mit den definierten Feature-Lookups und dokumentiert dabei, welche Features aus welchem Snapshot stammen.
Ein Teil der Lineage kann automatisch erfasst werden, wenn Tabellen und Modellprozess entsprechend integriert sind. Unity Catalog kann darstellen, aus welchen Quelltabellen eine Feature-Tabelle aufgebaut wurde und welche Modelle oder Endpoints davon abhängen. Diese Informationen unterstützen Audits, Fehleranalysen und geplante Änderungen. Sie helfen auch bei einem Refactoring: Eine geänderte Feature-Berechnung zeigt in der Lineage, welche Modelle davon betroffen sind.
Eine Delta-Tabelle ohne Feature-Engineering-Integration wird nicht automatisch als Modell-Feature-Quelle behandelt. Sie hat dann keine Modell-Bindung und keine Auto-Lookup-Logik. Der Mehrwert entsteht vor allem durch die Verbindung mit MLflow, Model Registry und Model Serving.
Wie Training und Serving dieselben Features nutzen
Der wichtigste Nutzen liegt in der dokumentierten Verbindung zwischen Modell und Feature-Quelle. Die Tabelle allein verhindert noch keine Inkonsistenzen. Wird ein Trainingsset über die Feature-Engineering-API erstellt, kann die Lookup-Konfiguration beim Modell-Logging mitgespeichert werden. Für jedes Feature bleibt dokumentiert, aus welcher Tabelle und über welchen Schlüssel es bezogen wurde.
Beim Scoring kann dieselbe Lookup-Konfiguration erneut verwendet werden. Die Anwendung übermittelt in einem Online-Szenario gegebenenfalls nur die benötigten Entitätsschlüssel (customer_id). Model Serving kann die im Modellartefakt hinterlegten Feature-Bindungen auslesen, holt die Features aus den hinterlegten UC-Tabellen oder dem zugehörigen Online Store. Dadurch lässt sich für Training und Inferenz dieselbe Feature-Definition verwenden. Das reduziert das Risiko von Train/Serve-Skew deutlich, ersetzt aber weiterhin Tests, Versionierung und saubere Datenprozesse.
Wer Feature-Logik zusätzlich in der Anwendung implementiert, erhöht das Risiko abweichender Berechnungen. Eine dokumentierte Feature-Bindung ist eine wichtige Voraussetzung dafür, dass Modellversion, Trainingsdaten und Inferenzinputs nachvollziehbar zusammenpassen. Wie der Modell-Lebenszyklus diese Spur weiterführt, klären wir im Überblick zu Mosaic AI Model Registry auf Databricks.
Wie liefert der Online Store Features in Echtzeit?
Offline-Features werden als Delta-Tabellen in Unity Catalog gespeichert. Für Batch-Scoring oder regelmäßige Modellläufe reichen diese Tabellen häufig aus. Bei synchronen Anwendungen kann die Antwortzeit des Feature-Lookups dagegen entscheidend sein. Anwendungen wie Personalisierung, Fraud Detection oder interaktive Services benötigen häufig deutlich niedrigere und planbare Latenzen. Wie sich Features, Model Serving und Streaming-Pfade in einer Echtzeit-Architektur ergänzen, klären wir im Überblick zu Real-Time-ML auf Databricks.
Databricks hat die Online-Feature-Schicht in mehreren Stufen weiterentwickelt. Die früheren Online Tables gelten als ältere Variante für bestehende Workloads. Für neue Implementierungen verweist Databricks auf den Databricks Online Feature Store, powered by Lakebase: eine verwaltete, Postgres-kompatible OLTP-Datenbank, die in der Data Intelligence Platform sitzt und nativ an Unity Catalog gebunden ist. Der genaue Reifegrad und die Verfügbarkeit von Lakebase sollten für die jeweilige Cloud, Region und Produktvariante aktuell geprüft werden. Neue Online-Store-Instanzen werden in der Regel als Lakebase-Autoscaling-Projekte angelegt; bestehende Provisioned-Instanzen werden im Lauf der Plattform-Migration angeglichen (Microsoft Learn: Migrate from online tables).
Ein Online Store kann über die vorgesehene API oder Benutzeroberfläche angelegt werden. Anschließend wird eine Feature-Tabelle publiziert und synchronisiert (Databricks Docs: Online Feature Stores). Für die Synchronisation stehen unterschiedliche Betriebsarten zur Verfügung: getaktete Synchronisation für regelmäßige inkrementelle Aktualisierungen, kontinuierliche Synchronisation für geringe Verzögerungen und eine vollständige Übertragung eines Tabellenstands. Inkrementelle und kontinuierliche Modi können zusätzliche Voraussetzungen wie Change Data Feed benötigen. Views, Materialized Views und Iceberg-Tabellen können nur im Snapshot-Modus gespiegelt werden (Databricks Docs: Synced Tables).
Bei korrekt registrierten Modellen kann die Anwendung denselben Inferenzendpoint weiterverwenden. Modelle, die mit aktuellen Versionen von databricks-feature-engineering und einer kompatiblen Databricks-Runtime registriert wurden, tragen die Feature-Lineage im MLflow-Artefakt. Bei der Inferenz löst der Endpoint die Lookups über Unity Catalog gegen den passenden Online Store auf. Für bestehende Endpoints können Konfigurationsänderungen (etwa das Setzen der Umgebungsvariable FEATURE_SOURCE=DATABRICKS_ONLINE_STORE) und ein erneutes Deployment erforderlich sein.
Ein Online Feature Store ist vor allem dann sinnvoll, wenn mehrere Voraussetzungen erfüllt sind. Es gibt eine produktive Anwendung mit verbindlicher niedriger Antwortzeit. Die benötigten Features können vorab berechnet und regelmäßig aktualisiert werden. Eine vollständige Echtzeit-Berechnung pro Aufruf ist ausdrücklich nicht der Anwendungsfall. Die zusätzlichen Kosten und Betriebsaufgaben für Synchronisation und Kapazität sind wirtschaftlich vertretbar. Ohne diese Anforderungen reicht die direkte Nutzung von Unity-Catalog-Feature-Tabellen häufig aus.
Der Online Store übernimmt die Bereitstellung, nicht zwingend die unmittelbare Berechnung eines Features aus einem neuen Ereignis. Wenn ein Feature aus einem Streaming-Ereignis (Klick, Transaktion) unmittelbar berechnet werden muss, gehört eine Streaming-Pipeline davor: Spark Structured Streaming, Lakeflow Declarative Pipelines (vormals Delta Live Tables) oder eine externe Engine, die das Feature in die UC-Tabelle schreibt, von der der Online Store es einliest. Zwischen Ereignis, Berechnung, Synchronisation und Lookup bleibt eine technisch bedingte Verzögerung.
| Feature-Schicht | Latenz-Klasse | Typische Anwendung | Voraussetzung |
|---|---|---|---|
| UC-Feature-Tabelle (Delta) | Sekunden bis Minuten | Batch-Scoring, regelmäßige Modell-Läufe | Primärschlüssel + Feature-Engineering-Client |
| Online Feature Store auf Lakebase | niedrige Latenzen je nach Region, Last und Konfiguration | Echtzeit-Empfehlung, Fraud Detection, Chatbot mit Feature-Lookup | Lakebase-Online-Store-Instanz, aktivierter Sync, CDF auf der Quelle |
| Feature Serving Endpoint | niedrige Latenzen je nach Region, Last und Konfiguration | Features als REST-API für Anwendungen, auch ohne Modell | Endpoint auf Lakebase-Online-Store |
| Legacy Online Table | niedrige Latenzen je nach Region, Last und Konfiguration | bestehende Workloads, schrittweise Migration auf Lakebase | bestehende Konfiguration, kein Default mehr für neue Projekte |
Niedrige Latenzen können je nach Region, Last und Konfiguration erreichbar sein; konkrete SLAs sollten für den eigenen Workload gemessen werden.
Die Tabelle ist eine Orientierung. Verfügbarkeit pro Cloud und Region, konkrete Latenzkorridore und Preismodelle sollten vor der produktiven Aktivierung in der aktuellen Databricks-Doku geprüft werden, weil sich diese Punkte zwischen Azure, AWS und GCP unterscheiden können.
Wann auf Lakebase migrieren?
Für neue Projekte sollte der aktuell von Databricks empfohlene Online-Store-Pfad verwendet werden. Legacy Online Tables bleiben für bestehende Anwendungen relevant, sind aber nicht mehr die bevorzugte Grundlage neuer Projekte. Ob der Lakebase-basierte Online Feature Store in der eigenen Region vollständig verfügbar und allgemein freigegeben ist, sollte vor Projektbeginn geprüft werden (Databricks Docs: Online Feature Stores). Externe Online Stores wie Cosmos DB oder DynamoDB benötigen häufig zusätzliche Synchronisations-, Berechtigungs- und Governance-Prozesse. Eine native Databricks-Integration kann diese zusätzlichen Schnittstellen reduzieren.
Für bestehende Workloads sollte die Migration schrittweise erfolgen.
Zielinstanz einrichten
Store passend dimensionieren, häufig sinnvoll als ein gemeinsamer Store für mehrere Feature-Tabellen pro Workspace statt einer Instanz pro Projekt.
Feature-Tabellen synchronisieren
Die benötigten Feature-Tabellen publizieren, etwa über publish_table(...).
Endpoints umstellen
Modell- oder Feature-Serving-Endpoints auf die neue Quelle umstellen, zum Beispiel über die Umgebungsvariable FEATURE_SOURCE=DATABRICKS_ONLINE_STORE.
Parallelbetrieb auswerten
Erst nach einem kontrollierten Parallelbetrieb und fachlichen Vergleich die alte Lösung entfernen.
Die Kosten richten sich nach der bereitgestellten Kapazität und dem aktuellen Abrechnungsmodell. Konkrete Kapazitätsstufen und Preise sollten direkt in der aktuellen Dokumentation geprüft werden. Databricks empfiehlt, einen gemeinsamen Online Store pro Workspace über mehrere Feature-Tabellen zu nutzen, statt eine eigene Instanz pro Projekt aufzusetzen (Microsoft Learn: Migrate from online tables).
Für neue Online-Feature-Anwendungen sollte Lakebase als bevorzugte Option bewertet werden. Bestehende Workloads auf Legacy-Online-Tables bleiben kurzfristig nutzbar, sollten aber für die nächste größere Anpassung in Richtung Lakebase überführt werden. Für Batch-Scoring und Backfills ist in der Regel kein zusätzlicher Online Store erforderlich.
Wie stellt man Features als API bereit?
Features werden nicht nur von ML-Modellen, sondern auch von klassischen Anwendungen und Services benötigt. Eine personalisierte Web-Anwendung braucht die letzten drei Bestellungen eines Kunden, eine Risiko-Engine die aktuelle Bonitätsklasse, ein Service-Portal die Vertragsstufe. All das sind Features, die im Lakehouse leben und über die UC-Schicht verfügbar sind. Bei verbindlich niedrigen Antwortzeiten ist eine direkte SQL-Abfrage auf Delta-Tabellen häufig nicht geeignet.
Feature Serving Endpoints ermöglichen den Abruf ausgewählter Features über eine REST-Schnittstelle, gespeist aus dem Lakebase-Online-Store (oder einem bestehenden Legacy-Online-Table). Die aufrufende Anwendung übermittelt den jeweiligen Lookup-Schlüssel und erhält die zugehörigen Feature-Werte. Die Schnittstelle kann unabhängig von einem bestimmten ML-Modell verwendet werden; derselbe Endpoint kann mehrere Anwendungen bedienen, mit derselben Governance- und Logging-Schicht wie ein Model-Serving-Endpoint.
Ein Feature-Serving-Endpoint ist besonders sinnvoll, wenn mehrere Anwendungen dieselben Feature-Werte konsistent verwenden sollen. Eine Bonitätsklasse, die in vier Anwendungen identisch sein muss, ist ein Kandidat für Feature Serving. Features, die ausschließlich von einem Modell benötigt werden, können weiterhin direkt über dessen MLflow-Bindung bezogen werden.
Wie greift der Feature Store in MLflow?
Feature Store, MLflow und Model Registry übernehmen unterschiedliche Aufgaben im Modelllebenszyklus. Der Feature Store verwaltet Feature-Quellen, MLflow dokumentiert Runs und Artefakte, die Registry versioniert Modelle. Diese Zuständigkeiten sollten klar getrennt sein. Fehlt eine davon, entstehen Lücken bei Reproduzierbarkeit, Bereitstellung oder Governance.
MLflow
Trackt jeden Trainings-Lauf: Parameter, Metriken, Code-Version, Artefakte. Über die Feature-Engineering-Client-API kommt die Bindung an die verwendeten Feature-Tabellen hinzu.
Mosaic AI Model Registry
Verwaltet den Modell-Lebenszyklus im Unity Catalog: Versionen, Aliase, Berechtigungen, Übergänge zwischen Staging-Phasen. Die gespeicherte Feature-Konfiguration bleibt Teil des Modellartefakts.
Model Serving
Liest die hinterlegten Feature-Lookups aus und erzeugt die Vorhersage. Die Anwendung hinter dem Endpoint kennt die Feature-Konfiguration nicht und muss sie nicht kennen.
Wie die Endpoint-Topologie aussieht und welche Klassen (Custom Model, Foundation Model API, External Model) den Inferenz-Pfad tragen, klären wir im Überblick zu Model Serving auf Databricks.
Der Prozess funktioniert zuverlässig, wenn Feature-Definition, Modellregistrierung und Serving konsistent konfiguriert sind. Ein Modell, das im Trainings-Notebook Features selbst berechnet, lässt sich nicht sauber im Model Registry versionieren. Eine Feature-Tabelle ohne Owner ist im Audit eine Leerstelle. Ein Endpoint, der die Online-Tabelle ignoriert, gibt die Latenz-Garantie auf. Die Komponenten müssen technisch und organisatorisch aufeinander abgestimmt sein.
Wie wird Feature-Drift sichtbar?
Veränderte Feature-Verteilungen gehören zu den häufigen Ursachen für Qualitätsprobleme im produktiven Betrieb. Eingaben verschieben sich: Kundenverhalten ändert sich, ein Geschäftsbereich wird umstrukturiert, ein Quellsystem ändert sein Schema. Das Modell wurde auf einem früheren Datenstand entwickelt, während die aktuellen Eingaben möglicherweise außerhalb dieses Bereichs liegen.
Ohne Monitoring wird die Veränderung häufig erst durch sinkende Modellqualität oder fachliche Auffälligkeiten sichtbar. Feature-Tabellen sind eine geeignete Datenbasis für die regelmäßige Analyse von Verteilungen. Die Features liegen als Delta-Tabellen vor, die Verteilung pro Zeitfenster lässt sich aggregieren und vergleichen.
Lakehouse Monitoring kann statistische Kennzahlen und Driftvergleiche direkt auf Feature-Tabellen in Unity Catalog berechnen, mit Alerts auf Schiefe und Drift gegen ein Baseline-Fenster. Was sich davon auf Feature-Tabellen besonders lohnt und welche Schwellen tragen, klären wir im Überblick zu Lakehouse Monitoring auf Databricks.
Ein Drift-Alert ist zunächst nur ein Hinweis und noch keine fachliche Entscheidung. Er wirkt nur, wenn jemand verantwortlich ist, einen Alert zu prüfen und gegebenenfalls das Modell neu zu trainieren. Ohne verantwortliches Team und festgelegte Folgeaktionen bleiben Warnungen unbearbeitet.
Owner, Lineage und Governance der Features
Feature-Tabellen werden als Objekte in Unity Catalog verwaltet. Damit können Eigentümerschaft, Zugriffsrechte und Datenherkunft dokumentiert werden. Diese Informationen unterstützen eine nachvollziehbare Modell- und Datenprüfung.
Der Owner sollte eine klar benannte Person, Gruppe oder technische Verantwortung sein. Diese Rolle verantwortet die Feature-Berechnung, begleitet Schema-Änderungen und reagiert auf Drift-Alerts. Ohne Ownership sammeln sich veraltete oder unklare Feature-Tabellen an: niemand räumt auf, niemand traut sich, etwas zu ändern, weil unklar ist, welche Modelle abhängen.
Lineage bildet die technischen Abhängigkeiten zwischen Quellen, Feature-Tabellen, Modellen und Endpoints ab. Für regulatorische oder interne Prüfungen ist dies eine wichtige technische Grundlage, ersetzt aber keine rechtliche und fachliche Dokumentation. Je nach Integration kann die Nachverfolgbarkeit bis auf Tabellen- oder Spaltenebene reichen. Wie sich die AI-Governance-Schicht auf den Feature-Tabellen aufsetzt, klären wir im Überblick zu AI-Governance auf Databricks.
Der Weg zur sauberen Ownership führt über drei Schritte.
Verantwortliche Gruppe vor Go-Live
Bereits vor der ersten produktiven Nutzung wird eine verantwortliche Gruppe für die Feature-Tabelle festgelegt.
Versionierte Freigabe
Änderungen an Schema und Berechnung werden versioniert und nachvollziehbar freigegeben.
Adressierte Warnungen
Warnungen gehen an das tatsächlich verantwortliche Team, nicht nur in ein allgemeines Postfach.
Wann braucht es Feast oder Tecton?
Externe Feature Stores sind vor allem relevant, wenn Daten, Training und Serving auf mehreren Plattformen betrieben werden. Feast ist eine verbreitete Open-Source-Lösung mit verschiedenen Offline- und Online-Store-Integrationen. Tecton bietet eine kommerzielle Plattform mit zusätzlichen Funktionen für Online- und Streaming-Features. Aussagen zu Produktintegration und Roadmap sollten anhand aktueller offizieller Informationen bewertet werden, etwa über das Databricks-Blog zur Feature-Store-Strategie.
Drei Situationen sprechen besonders für eine externe Lösung.
Multi-Platform-Deployment
Modelle laufen auf SageMaker, Vertex AI, Kubernetes oder anderen Plattformen und sollen dieselbe Feature-Definition wie die Databricks-Modelle nutzen.
Harte Streaming-Berechnung
Features müssen unmittelbar aus Streaming-Ereignissen berechnet und bereitgestellt werden.
Bestehende Investition
Die Organisation betreibt bereits einen etablierten externen Feature Store, der nicht ohne Weiteres ersetzbar ist.
Der Nachteil ist eine zusätzliche Governance- und Integrationsgrenze. Die Lineage liegt entweder in Unity Catalog oder im externen Feature Store, in beiden gleichzeitig wird sie selten konsistent. Prüfungen, Berechtigungen und Ownership werden dadurch komplexer. Wenn keine dieser Anforderungen vorliegt, ist eine native Unity-Catalog-Lösung häufig einfacher zu betreiben.
Was der Feature Store nicht ist
Der Feature Store ist nur ein Bestandteil einer vollständigen ML-Plattform. Seine Aufgabe liegt in der Verwaltung und Bereitstellung von Features.
Kein Modell-Katalog
Modellversionen und Freigaben werden in der Model Registry verwaltet. Die Bindung läuft über MLflow.
Kein Vector Store für RAG
Embeddings und Retrieval-Indizes für RAG gehören in Vector Search oder einen anderen Vektorspeicher. Der Feature Store hostet strukturierte, niedrig-dimensionale Features für klassisches ML und ML-gestützte Anwendungen.
Kein Trainings-Stack
Das eigentliche Training erfolgt in ML-Frameworks, Workflows oder Mosaic AI Training. Der Feature Store stellt die Eingaben bereit, betreibt aber kein Training.
Kein Ersatz für saubere Datenarchitektur
Der Feature Store ersetzt keine saubere Modellierung und Qualität der Quelldaten. Er macht die Qualitätsverantwortung sichtbarer, löst sie aber nicht automatisch.
Vertiefend: Vector Search für Embeddings und Retrieval, Mosaic AI Training für den eigentlichen Trainings-Stack.
Wie diese Schichten im Lakehouse zusammen produktiv tragen, klären wir im Überblick zu Artificial Intelligence auf Databricks.
Grenzen
Der Databricks Feature Store unterstützt konsistente Feature-Nutzung und Wiederverwendung. Für Training, Serving, Monitoring und Governance werden weiterhin weitere Komponenten benötigt.
Online Store ist keine Streaming-Berechnung
Der Online Store übernimmt die Bereitstellung synchronisierter Features, nicht die eigentliche Streaming-Berechnung. Für ein Feature aus dem aktuellen Klick-Ereignis muss eine Streaming-Pipeline davor sitzen, die die Feature-Tabelle füllt. Die Verzögerung zwischen Ereignis, Berechnung und Verfügbarkeit muss in der Architektur berücksichtigt werden.
Regionale Verfügbarkeit prüfen
Verfügbarkeit und Funktionsumfang unterscheiden sich möglicherweise nach Cloud, Region und Produktstand. Vor der produktiven Nutzung sollten die aktuelle Dokumentation und gegebenenfalls das Account-Team herangezogen werden.
Migration der Legacy Online Tables
Bestehende Legacy-Workloads sollten mit einem eigenen Migrations- und Testplan modernisiert werden: Online Store anlegen, Feature-Tabelle publizieren, Endpoint mit gesetzter FEATURE_SOURCE-Umgebungsvariable neu deployen. Ein Parallelbetrieb mit Ergebnis- und Latenzvergleich reduziert das Umstellungsrisiko.
Mehr Abhängigkeiten durch geteilte Features
Änderungen an gemeinsam genutzten Features benötigen Versionierung, Tests und eine Migrationsstrategie. Der zusätzliche Abstimmungsaufwand ist eine Folge der bewussten Wiederverwendung und verändert die Geschwindigkeit, mit der Features iteriert werden können.
Workspace-Feature-Store-Migration
Bestehende Workspace-Feature-Store-Workloads verursachen während der Migration zusätzlichen Betriebsaufwand. Neue Projekte sollten die aktuell empfohlene Unity-Catalog-Variante verwenden. Sie ist der einzige Pfad, der auf längere Sicht von Databricks weiterentwickelt wird.
Plattformübergreifendes Serving braucht mehr Governance
Wenn Modelle auf Vertex AI, SageMaker oder eigenen Kubernetes-Clustern laufen sollen, kommt ein externer Feature Store wie Feast oder Tecton ins Spiel. Die Governance-Frage verdoppelt sich; die Entscheidung gehört auf die Ebene der Plattform-Strategie.
Der Feature Store verbessert die Konsistenz der Feature-Nutzung. Die grundsätzliche Entscheidung über Daten-, Trainings- und Serving-Plattform bleibt davon getrennt. Sobald Wiederverwendung über mehrere Modelle das Ziel ist, lohnt sich der Aufbau. Eine frühe Standardisierung reduziert spätere Mehrfachimplementierungen und aufwendige Bereinigungen.
Fazit
Der Databricks Feature Store verbindet Feature-Definitionen mit Training, Batch-Scoring und Online-Inferenz.
Feature Engineering in Unity Catalog verwaltet Features als reguläre Delta-Tabellen mit Owner, Berechtigungen und Lineage. Über die Feature-Engineering-API werden Modelle mit den verwendeten Tabellen, Schlüsseln und Feature-Spalten verknüpft. Dadurch wird das Risiko unterschiedlicher Feature-Definitionen zwischen Training und Serving deutlich reduziert und hängt weniger von manueller Abstimmung einzelner Teams ab.
Der Lakebase-basierte Online Feature Store ergänzt diese Architektur um schnelle Feature-Lookups für interaktive Anwendungen. Bestehende Legacy Online Tables sollten bei größeren Anpassungen auf eine Migration geprüft werden. Feature Serving Endpoints stellen Features als REST-API für Anwendungen bereit, die kein ML-Modell hosten. Feature Store, MLflow und Model Registry können gemeinsam einen nachvollziehbaren Weg von den Trainingsdaten bis zur produktiven Modellversion abbilden, mit Lineage durch alle Stufen.
Drei Entscheidungen sind für einen stabilen Betrieb besonders wichtig. Feature Engineering in Unity Catalog kann als gemeinsame Grundlage für neue ML-Anwendungen dienen. Ein Online Store sollte nur bei nachgewiesenem Bedarf an niedrigen Antwortzeiten eingesetzt werden. Für jede produktive Feature-Tabelle sollte vor der ersten Modellbindung eine eindeutig verantwortliche Gruppe festgelegt werden.
Ein sinnvoller Einstieg sieht folgendermaßen aus: Vor dem nächsten produktiven Modell werden zentrale Feature-Tabellen, Owner und Lookup-Definitionen in Unity Catalog festgelegt. Neue Modelle werden mit diesen Feature-Quellen über die Feature-Engineering-API registriert. Erst auf Basis konkreter Latenz-, Streaming- und Plattformanforderungen wird über Online Stores oder externe Feature Stores entschieden. Eine zentrale Feature-Definition ist bereits beim ersten produktiven Modell hilfreich. Die zusätzliche Online-Bereitstellung lohnt sich dagegen erst, wenn niedrige und messbare Antwortzeiten tatsächlich benötigt werden.
Vor dem nächsten produktiven Modell werden zentrale Feature-Tabellen, Owner und Lookup-Definitionen in Unity Catalog festgelegt.
FAQ
Der Databricks Feature Store ist die Schicht, die ML-Features wiederverwendbar zwischen Trainings- und Inferenz-Pfad bereitstellt. Heute besteht er aus Feature Engineering in Unity Catalog (Default für die Offline-Welt) und dem Online Feature Store auf Lakebase für Niedriglatenz-Lookups. Feature-Tabellen sind UC-Delta-Tabellen mit Primärschlüssel. Die Feature-Engineering-Client-API bindet Modelle bei der MLflow-Registrierung an konkrete Tabellen, damit Training und Inferenz dieselbe Definition nutzen.
