Feature Stores und die ML-Datenlieferkette: was CDOs wirklich verstehen müssen

Das Konzept klingt technisch genug, dass viele CDOs es komplett an die ML-Engineering-Teams delegieren. Das ist ein Fehler. Ein Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen → ist die Infrastrukturschicht, die steuert, wie Rohdaten in Inputs für Machine-Learning-Modelle umgewandelt werden, und die Entscheidung, wie diese Schicht gebaut oder eingekauft wird, bestimmt Geschwindigkeit, Kosten und Zuverlässigkeit jedes ML-Produkts in Ihrer Organisation. Wer das falsch anlegt, bremst nicht nur Data Scientists. Es entstehen unsichtbare Schulden, die sich über jedes Modell in Produktion aufaddieren.

Warum das speziell für die CDO-Rolle zählt

Die meisten ML-Fehlschläge sind keine Modellfehler. Das Modell ist selten das schwache Glied. Was produktive ML-Systeme kaputt macht, sind die Daten, die sie speisen: Features, die im Training anders berechnet werden als im Serving, Features, die veralten, weil es keine Ownership gibt, Features, die von drei verschiedenen Teams neu gebaut werden, weil keines von den anderen wusste.

Ubers Michelangelo-Plattform, ab etwa 2015 entwickelt und im Engineering-Blog des Unternehmens ausführlich dokumentiert, war eines der ersten internen Systeme, das Feature-Berechnung als Problem einer gemeinsamen Infrastruktur behandelte. Die Kernbeobachtung war einfach: Dasselbe Feature (etwa die durchschnittliche Fahrtdauer eines Fahrgasts in den letzten 30 Tagen) wurde von mehreren Teams unabhängig berechnet, mit inkonsistenter Logik und ohne Garantie für Konsistenz zwischen Offline-Training und Online-Serving. Die Doppelarbeit war teuer; die Inkonsistenz war gefährlich.

Für einen CDO ist das zuerst ein Governance- und Effizienzproblem und erst danach ein Technologieproblem. Feature Stores bringen Disziplin in einen Teil der ML-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen →, der ansonsten fast völlig ungemanagt ist. Sie schaffen ein Register von Features mit dokumentierter Ownership, Lineage und Wiederverwendungsmustern. Dieses Register ist genau das Artefakt, das Datenstrategie mit Geschäftsergebnissen verbindet: Sie sehen, welche Features wichtig sind, welche Teams sie besitzen und was mit vier nachgelagerten Modellen passiert, wenn sich eine Quelltabelle ändert.

Wie es tatsächlich funktioniert: die Mechanik

Ein Feature Store hat zwei Kernkomponenten, die unterschiedliche zeitliche Probleme lösen.

Der Offline Store hält historische Feature-Werte, typischerweise in einem spaltenorientierten Format wie Parquet auf Object Storage oder in einem 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 →. Hier werden Trainingsdaten zusammengestellt. Ein Data Scientist, der ein Fraud-Detection-Modell baut, braucht die Feature-Werte, die zum Zeitpunkt der Transaktion galten, nicht die heutigen Werte. Das nennt man Point-in-Time-Korrektheit, und sie ist eine der häufigsten Ursachen für Training-Serving-Skew, wenn Teams ihre eigenen Ad-hoc-Pipelines bauen. Falsch gemacht, entsteht ein Modell, das in der Offline-Evaluation stark aussieht und in Produktion leise versagt.

Der Online Store ist ein Key-Value-Store mit niedriger Latenz (Redis ist die häufigste Wahl), der die aktuellsten Feature-Werte hält und sie Modellen zum Inferenzzeitpunkt liefert, typischerweise in unter 10 Millisekunden. Wenn ein Nutzer einen Recommendation-Endpoint aufruft, berechnet die Serving-Schicht die Features nicht neu. Sie holt vormaterialisierte Werte aus dem Online Store.

Die Koordination zwischen diesen beiden Stores, sie konsistent zu halten und die Logik der Feature-Berechnung gemeinsam zu nutzen, ist genau das, was der Feature Store managt.

Ein konkretes Beispiel: Ein Händler, der ein Modell für Produktempfehlungen baut, braucht ein Feature namens „Kaufhäufigkeit des Kunden in den letzten 14 Tagen“. Im Training wird das aus historischen Transaktionslogs berechnet und zum korrekten historischen Zeitstempel an die Trainingsbeispiele gejoint. In Produktion muss es in Echtzeit verfügbar sein, wenn ein Kunde auf der Homepage landet. Ohne Feature Store werden diese beiden Berechnungen getrennt geschrieben, oft von verschiedenen Personen. Mit einem wird die Transformationslogik einmal definiert. Der Offline Store füllt die Historie per Backfill; der Online Store liefert den heutigen Wert. Entscheidet das Business, die Definition auf ein 21-Tage-Fenster zu ändern, propagiert eine Änderung überall hin.

Managed-Feature-Store-Produkte von Anbietern wie Tecton (eine kommerzielle Plattform, gebaut von früheren Uber-Ingenieuren, wobei das kommerzielle Interesse an dieser Darstellung zu beachten ist) oder Databricks Feature Store (Teil der Databricks 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 → Platform) ergänzen Monitoring, Alerting zur Datenaktualität und Integration mit Tools für Experiment Tracking. Open-Source-Optionen wie Feast bieten die gleiche Kernarchitektur ohne Vendor-Abhängigkeit, brauchen im Betrieb aber mehr Engineering-Kapazität.

Wann man es einsetzt und wann nicht: die ehrlichen Tradeoffs

Ein Feature Store schafft Wert, wenn Sie mehrere Modelle in Produktion haben, mehrere Teams Features beitragen und Online-Inferenz mit niedriger Latenz gebraucht wird. Sind diese drei Bedingungen erfüllt, zahlt sich die Investition in eine gemeinsame Feature-Schicht meist schnell aus. Airbnb, LinkedIn und Twitter haben Engineering-Blogposts veröffentlicht, die beschreiben, welchen operativen Overhead sie durch zentrales Feature-Management beseitigt haben, und diese Posts (jeweils von den eigenen Engineering-Teams, also mit Blick auf den Eigenwerbungscharakter zu lesen) nennen durchgehend Wiederverwendungsraten und den Rückgang von Datenincidents als messbare Gewinne.

Die Gegenposition ist auch real. Hat Ihre Organisation ein oder zwei Modelle und ein einziges Data-Science-Team, ist ein formaler Feature Store Overhead, der Sie ohne echten Nutzen bremst. Das gilt genauso, wenn die meisten Ihrer ML-Use-Cases Batch-Prediction sind, wo Training-Serving-Skew kein Thema ist. Feature-Store-Infrastruktur zu bauen oder zu kaufen, bevor die Nutzung sie rechtfertigt, ist ein häufiger Fehler von Teams, die sich an Uber gemessen haben, ohne Ubers Größe oder Problemvielfalt zu haben.

Es gibt außerdem einen organisatorischen Tradeoff, der selten klar benannt wird: Ein Feature Store funktioniert nur, wenn Teams Features tatsächlich einstellen und wiederverwenden, statt parallel eigene Pipelines zu bauen. Das braucht Incentives, Governance-Regeln und manchmal Durchsetzung. Die Technologie ist der einfache Teil. Drei getrennte Data-Science-Teams dazu zu bringen, sich auf eine gemeinsame Definition von „Kundenzugehörigkeit“ zu einigen, ist die eigentliche Arbeit.

Die Entscheidung des CDO

Die Aufgabe des CDO ist hier nicht, zwischen Feast und Tecton zu wählen. Sie besteht darin, zu entscheiden, ob Feature-Management ein Problem gemeinsamer Infrastruktur oder eine Angelegenheit einzelner Teams ist, und diese Entscheidung dann explizit zu machen und entsprechend zu governen. Ist ML ein wesentlicher Teil des Geschäfts, lautet die Antwort fast immer: gemeinsame Infrastruktur, und der Feature Store ist der operative Ausdruck dieser Entscheidung. Teams, die es als Team-Angelegenheit behandeln, sammeln dieselben technischen Schulden an, mit denen Uber vor einem Jahrzehnt zu 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 →ämpfen hatte, nur ohne Ubers Budget, sie zu beheben.