Feature Stores und die ML-Data-Supply-Chain: was CDOs wirklich verstehen müssen

Das Konzept klingt trügerisch einfach. Ein Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen → ist ein System, das berechnete Data Features für Machine-Learning-Modelle speichert und ausliefert. In dieser Definition steckt aber ein Problem, das in Unternehmen wie Uber, LinkedIn und Airbnb im letzten Jahrzehnt still und leise enorme Engineering-Zeit verschlungen hat und über das Organisationen, die ML 2026 im großen MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßstab ausrollen, weiterhin stolpern.

Die Verwirrung rund um Feature Stores läuft meist in zwei Richtungen. Manche Teams halten sie für eine aufgemotzte Datenbank und fragen sich, wozu sie überhaupt ein eigenes System brauchen. Andere überkonstruieren vom ersten Tag an und bauen eine Infrastruktur, die sie weder befüllen noch steuern kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen. Das Konzept richtig zu verstehen, bevor über die Einführung entschieden wird, ist der Punkt, an dem sich der CDO seinen Platz am Tisch verdient.

Warum das speziell für CDOs relevant ist

Die Kernverantwortung des CDO besteht darin, dass Daten von der Rohdatenerfassung bis zum Business Value zuverlässig und zu vertretbaren Kosten fließen. Im ML-Kontext versteckt sich der größte Teil dieser Kosten in der Lücke zwischen Rohdaten und Modell-Input.

Betrachten Sie, was ohne Feature Store passiert. Ein Data Scientist baut ein Churn-Modell und berechnet ein Feature namens "Tage seit letzter Transaktion". Drei Monate später baut ein Fraud-Team ein eigenes Modell und berechnet etwas fast Identisches: "Aktualität der Kaufaktivität". Beide Teams haben ihre eigene Transformationslogik geschrieben, mit ziemlicher Sicherheit mit feinen Unterschieden im Umgang mit Nullwerten, Zeitzonen oder Lookback-Fenstern. Wenn diese Modelle in Produktion gehen, muss das Engineering-Team beide Transformations-Pipelines in einer anderen Sprache nachbauen und erzeugt dabei oft eine dritte Version derselben Berechnung. Das nennt man mitunterTraining-Serving-Skew: Die Feature-Werte, die ein Modell im Training sieht, unterscheiden sich von denen zum Inferenzzeitpunkt, und das Modell liefert stillschweigend schlechtere Ergebnisse, ohne dass anfangs jemand weiß, warum.

Ein Feature Store zentralisiert diese Transformationslogik. ErErThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → sitzt zwischen Ihren Rohdaten und Ihren Modellen und erzwingt Konsistenz über Trainings- und Serving-Kontext hinweg. Für einen CDO, der dutzende ML-Use-Cases verantwortet, ist der kumulative Effekt, diesen Skew zu beseitigen und Features teamübergreifend wiederzuverwenden statt sie neu zu berechnen, sowohl bei der Zuverlässigkeit als auch bei den Kosten erheblich.

Wie ein Feature Store tatsächlich funktioniert

Ein Feature Store hat drei Hauptkomponenten, und wer jede davon versteht, löst den größten Teil der Verwirrung auf.

Erstens gibt es die Feature Registry. Das ist im Kern ein Katalog definierter Transformationen: "Tage seit letzter Transaktion" wird einmal definiert, mit Logik, Owner und Metadaten. Jedes Team, das dieses Feature braucht, holt es aus der Registry, statt eine eigene Version zu schreiben.

Zweitens gibt es den Offline Store, typischerweise ein Data WarehouseData WarehouseA central repository that consolidates data from many source systems into a structured, query-optimized store designed for analytics, reporting, and business intelligence.Vollständige Definition ansehen → oder eine LakehouseLakehouseA hybrid architecture combining the flexibility of a data lake with the analytical capabilities of a data warehouse, on a single storage layer.Vollständige Definition ansehen →-Partition. Hier werden historische Feature-Werte für das Modelltraining abgelegt. Wenn ein Data Scientist ein Modell auf sechs Monaten Kundenverhalten trainieren will, fragt er den Offline Store nach Point-in-Time-korrekten Feature-Werten ab. Point-in-Time-Korrektheit ist entscheidend: Der Store muss den Wert zurückgeben, der zu einem bestimmten vergangenen Zeitstempel verfügbar gewesen wäre, nicht den rückwirkend mit später eingetroffenen Daten berechneten Wert. Ohne das trainieren Modelle auf Informationen, die sie zum Entscheidungszeitpunkt nicht hatten, und sie scheitern in Produktion.

Drittens gibt es den Online Store, eine Key-Value-Datenbank mit niedriger Latenz (Redis wird hier häufig eingesetzt), die vorberechnete Feature-Werte in Echtzeit während der Inferenz ausliefert. Wenn ein Fraud-Modell eine Transaktion in 50 Millisekunden bewertet, liest es aus diesem Online Store und berechnet die Features nicht von Grund auf neu.

Ein konkretes Beispiel: Uber baute Michelangelo, eine der frühesten internen ML-Plattformen, die einen Feature Store enthielt, um dieselben Rider-Behavior-Features an die Modelle für Nachfrageprognose, ETA und Surge PricingSurge PricingAutomatically adjusting prices in real time based on demand, competition or user behaviour to optimise revenue, margin or conversion.Vollständige Definition ansehen → auszuliefern. Der entscheidende Punkt war nicht nur die Wiederverwendung, sondern die Konsistenz. Dasselbe Feature, auf dieselbe Weise berechnet, im Training wie in der Produktion. Feast, das Open-Source-Projekt, das ursprünglich bei Gojek entwickelt wurde, brachte später eine Variante dieser Architektur zu Teams ohne die Ressourcen für einen Eigenbau. Tecton und Hopsworks gehören zu den kommerziellen Anbietern mit Managed-Versionen, wobei deren Benchmarks und Adoption-Angaben als Anbieterposition und nicht als unabhängige Validierung zu behandeln sind.

Wann er sinnvoll ist und wann nicht

Ein Feature Store ergibt Sinn, wenn mindestens zwei der folgenden Bedingungen zutreffen: Sie haben mehrere ML-Modelle in Produktion, mehr als ein Team erzeugt Features, oder Features müssen in einem Produktivsystem mit niedriger Latenz ausgeliefert werden. Trifft nichts davon zu, zahlen Sie Infrastrukturkosten für eine Zukunftsoption, die Sie vielleicht nie brauchen.

Die ehrlichen Tradeoffs sollte man direkt benennen.

Die operative Komplexität steigt, bevor die Produktivität steigt. Sie haben jetzt ein zusätzliches System zu warten, zu überwachen und Ihrem Data-Governance-Team zu erklären. Early Adopters unterschätzen häufig, wie lange es dauert, bestehende Feature-Logik in den Store zu migrieren und die Disziplin zu etablieren, die verhindert, dass Teams Features einfach weiterhin außerhalb davon berechnen.

Die Governance-Chance ist real, aber nicht automatisch. Eine Feature Registry ist nur so nützlich wie ihre Nutzung. Wenn Ihre Data Scientists sie als optional behandeln oder dem Katalog Ownership-Metadaten fehlen, haben Sie die Infrastrukturkosten ohne den Konsistenzgewinn.

Es gibt auch eine Frage der Reihenfolge. Organisationen, die ihre Data Pipelines oder ihre Model-Deployment-Prozesse noch nicht standardisiert haben, werden feststellen, dass ein Feature Store diese vorgelagerten Lücken offenlegt statt löst. Airbnb hat interne Post-mortems veröffentlicht, in denen festgehalten wird, dass ihre Investitionen in ML-Tooling in dem Maß erfolgreich waren, wie die darunterliegende Dateninfrastruktur ausgereift war.

Wirklich aus zahlen sich Feature Stores in Organisationen, die zehn oder mehr Modelle in Produktion betreiben, mit Features, die über Geschäftsbereiche hinweg geteilt werden. Handelsunternehmen, die gleichzeitig Customer Lifetime ValueCustomer Lifetime ValueLifetime Value: the total revenue (or profit) a customer generates throughout their entire relationship with your business.Vollständige Definition ansehen →, Kaufneigung und Bestandsrisiko bewerten, sind der naheliegende Use Case. Finanzinstitute, die Credit-, Fraud- und AML-Modelle auf überlappenden Kundensignalen betreiben, sind ein weiterer.

Für CDOs, die diese Entscheidung 2026 bewerten, ist der Markt reif genug, dass die Build-or-Buy-Frage eine klarere Antwort hat als vor fünf Jahren. Managed Services von Anbietern wie Tecton reduzieren den operativen Aufwand, bringen aber Abhängigkeits- und Kostenaspekte mit sich, die ein unabhängiges Scoping verdienen statt des Vertrauens auf ROIROIReturn on Investment: the ratio of net profit to the cost of an investment. A 300% ROI means each dollar invested returns $3.Vollständige Definition ansehen →-Rechner der Anbieter.

Der Feature Store ist kein Allheilmittel für ML-Datenqualität, aber er ist die direkteste strukturelle Antwort auf einen der häufigsten Failure Modes im produktiven ML. Bringen Sie zuerst das Training-Serving-Skew-Problem unter Kontrolle, der breitere Nutzen für die Supply Chain folgt dann daraus.