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

Der Begriff „Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen →“ fällt in Gesprächen über ML-Architektur, als wäre allen klar, was 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 → bedeutet. Ist es nicht. Manche Teams bezeichnen damit einen einfachen Key-Value-Cache vor einem Modell. Andere meinen eine komplette Data-Platform-Schicht mit Versionierung, Lineage und Serving-Infrastruktur. Diese Unklarheit ist relevant, denn die Entscheidung, einen Feature Store zu bauen, zu kaufen oder ganz darauf zu verzichten, gehört zu den folgenreicheren Punkten einer ML-Platform-Roadmap. Und sie wird meist zu früh, zu spät oder auf Basis von Vendor-Pitches statt des tatsächlichen operativen Bedarfs getroffen.

Warum das speziell für CDOs zählt

Die CDO-Rolle liegt an der Schnittstelle von Data GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen →, Platform-Strategie und ML-Enablement. Feature Stores betreffen alle drei Bereiche direkt.

Wenn Data Scientists in zwei verschiedenen Teams unabhängig voneinander dasselbe Feature entwickeln, etwa den durchschnittlichen Transaktionswert eines Kunden über die letzten 30 Tage, berechnen sie es mit hoher Wahrscheinlichkeit unterschiedlich. Andere Lookback-Fenster, andere Behandlung von Rückerstattungen, andere Zeitzonen-Konventionen. Beide Modelle gehen in Produktion. Achtzehn Monate später kann niemand erklären, warum das Churn-Modell und das Kreditrisiko-Modell bei demselben Kunden zu unterschiedlichen Ergebnissen kommen. Das ist ein Data-Governance-Problem, kein Modellierungsproblem.

Feature Stores sind die strukturelle Antwort darauf. Sie schaffen eine gemeinsame, versionierte und governte Schicht berechneter Features zwischen den Rohdaten und dem Modelltraining oder der Inference. Für einen CDO, der mehrere ML-produzierende Teams verantwortet, ist der Feature Store faktisch der Data Contract zwischen Data Engineering und Data Science. Ob dieser Contract sitzt oder nicht, hat unmittelbare Folgen für Modellkonsistenz, Audit-Fähigkeit und die Kosten des ML-Betriebs im 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.

Der regulatorische Druck kommt hinzu. Unter Frameworks wie dem EU AI Act müssen Hochrisiko-ML-Systeme Trainingsdaten und die Herkunft der Features dokumentieren. Ein ausgereifter Feature Store mit ordentlichem Lineage-Tracking ist einer der saubereren Wege, das operativ zu erfüllen, statt rückwirkend zu improvisieren.

Wie es tatsächlich funktioniert: die Mechanik

Ein Feature Store hat zwei Hauptkomponenten mit unterschiedlichen Aufgaben.

DerOffline Store ist der Ort, an dem Features berechnet und historisch gespeichert werden. Stellen Sie sich eine große, abfragbare Tabelle vorberechneter Werte vor, indexiert nach Entität (eine Kunden-ID, eine Produkt-SKU, ein Gerät) und Zeitstempel. Trainiert ein Data Scientist ein neues Modell, zieht er einen Point-in-Time-korrekten Snapshot aus dem Offline Store. Point-in-Time-Korrektheit ist das entscheidende Detail: Der Store liefert nur Feature-Werte, die zum Zeitpunkt eines historischen Labels verfügbar gewesen wären. Das verhindert, dass die Trainingsdaten versehentlich Informationen aus der Zukunft enthalten. Das ist eine der häufigsten und am seltensten diskutierten Ursachen für nachlassende Modellperformance in Produktion.

Der Online Store ist das Low-Latency-Gegenstück. Läuft ein Modell in Produktion und braucht den aktuellen Feature-Wert für einen bestimmten Kunden, fragt es den Online Store ab, statt neu aus den Rohdaten zu rechnen. Dieser Lookup dauert typischerweise einstellige Millisekunden, etwa über Redis oder DynamoDB. Offline und Online Store werden über eine 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 → synchron gehalten, die periodisch (oder in Echtzeit) neue Feature-Werte in beide schreibt.

Ein konkretes Beispiel macht es greifbarer. Die Recommendation-Infrastruktur von Spotify umfasst, wie das Unternehmen in Engineering-Blogposts öffentlich beschrieben hat, Features wie die aktuelle Hörhistorie eines Nutzers, die Skip-Rate bei bestimmten 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 →ünstlern und Hörmuster nach Tageszeit. All das zur Inference-Zeit für jeden Request neu zu berechnen, wäre rechnerisch nicht tragbar. Diese Features vorzuberechnen und in einem Online Store zu cachen, aktualisiert nach definiertem Schedule, hält die Latenz akzeptabel. Der Offline Store sorgt dann dafür, dass das Retraining historisch korrekte Snapshots derselben Features nutzt, sodass das, worauf das Modell gelernt hat, mit dem übereinstimmt, was es in Produktion sieht.

Tecton, Feast (das Open-Source-Projekt, ursprünglich von Gojek) und Hopsworks sind Stand 2026 die am häufigsten genannten dedizierten Feature-Store-Plattformen. Die großen Cloud-Anbieter haben Feature-Store-Funktionen ebenfalls in ihre ML-Plattformen integriert: Amazon SageMaker Feature Store, Vertex AI Feature Store auf Google Cloud und der Feature Store von Azure Machine Learning. Jeder Anbieter stellt naturgemäß die eigenen Benchmarks heraus, also gehen Sie mit Performance-Aussagen aus diesen Quellen entsprechend um und gewichten Sie unabhängige Evaluierungen stärker.

Wann man ihn einsetzt und wann nicht: die ehrlichen Tradeoffs

Ein Feature Store rechtfertigt seine Kosten, wenn mehrere Bedingungen gleichzeitig zutreffen: Mehrere Teams produzieren ML-Modelle, einige Features werden modellübergreifend genutzt, die Modelle laufen mit einer Inference-Latenz, die Berechnung on the fly ausschließt, und es gibt genug Retraining-Kadenz, damit Lineage und Versionierung operativ überhaupt etwas bedeuten.

Hat eine Organisation zwei Data Scientists, die zwei interne Tools bauen, ist ein Feature Store verfrühte Infrastruktur. Der Aufwand, eine Feature Registry zu pflegen, SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →-Evolution zu managen und Offline und Online Store synchron zu halten, verbraucht mehr Engineering-Zeit als er einspart. Mit gut dokumentierten SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.Vollständige Definition ansehen →-Transforms in einem gemeinsamen 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 → anzufangen, ist meist der richtige Zwischenschritt.

Es gibt auch Failure Modes, die Feature Stores erst erzeugen statt lösen. Schema Drift ist einer: Ein Feature wird upstream neu definiert, und wenn die Änderung nicht mit ordentlicher Versionierung durchgereicht wird, konsumieren Modelle stillschweigend eine andere Variable als die, auf der sie trainiert wurden. Das ist vermutlich schlimmer als gar kein Feature Store, weil es falsches Vertrauen in Konsistenz erzeugt. Die Governance rund um Feature-Ownership, also wer eine Feature-Definition ändern darf und wie der Deprecation-Prozess aussieht, muss vor der Infrastruktur stehen, nicht danach.

Die Build-oder-Buy-Entscheidung verdient ehrliche Prüfung. Einen Feature Store inhouse zu bauen, wie Uber mit Michelangelo und LinkedIn mit eigenem internem Tooling, war für diese Unternehmen bei ihrer spezifischen Größe und mit ihren Engineering-Ressourcen sinnvoll. Für die meisten Organisationen im Jahr 2026 ist es die besser begründbare Wahl, mit einem Managed-Angebot zu starten und bei Bedarf zu migrieren. Die Switching Costs sind tendenziell niedriger als erwartet, denn der eigentliche Asset sind die Feature-Definitionen und die Pipelines, die sie füllen, nicht der Store selbst.

Ein Feature Store ist Infrastruktur, die einen Reifegrad abbildet, kein Werkzeug, das ihn erzeugt. Organisationen, die ihn einführen, bevor geteilte Data Ownership und klare Model-Governance-Prozesse stehen, werden feststellen, dass er ihre bestehenden Koordinationsprobleme verstärkt statt löst. Die Aufgabe des CDO ist, die Investition in der richtigen Reihenfolge zu tätigen.