Feature Store: Das Frontend für Ihre KI-Daten-Pipelines

Unternehmens-KI entwickelt sich von einzelnen Modellen hin zu einheitlichen Datenökosystemen.

Während Unternehmen ihre KI-Initiativen skalieren, entsteht eine spannende Möglichkeit: der Aufbau eines einheitlichen Daten-Gateways, das jeden Schritt Ihrer KI-Pipeline verbindet, von Rohdaten über die Rechenverarbeitung bis hin zu Feature-Katalogen und der Modellbereitstellung. Es geht nicht nur darum, Komplexität zu managen, sondern auch darum, eine Grundlage zu schaffen, die hilft, Innovationen zu beschleunigen.

Eine wiederkehrende Herausforderung für Unternehmen besteht darin, dass Data Scientists immer wieder dieselben Features neu erstellen. Ein Team berechnet den Customer Lifetime Value für ein Modell zur Vorhersage von Abwanderung, und drei Monate später benötigt ein anderes Team dieselbe Berechnung für eine Empfehlungsmaschine, weiß aber nicht, dass sie bereits existiert. Also erstellen sie es von Grund auf neu, was zu Inkonsistenzen führt und wochenlange Entwicklungszeit verschwendet.

Dies ist das Problem der Feature-Wiederverwendung, und es kostet Unternehmen sowohl Zeit als auch Qualität.

Was ist ein Feature Store?

Ein Feature Store ist eine zentrale Plattform, die ML-Features verwaltet, speichert und bereitstellt – die Eingabevariablen, die Modelle für Vorhersagen verwenden. Stellen Sie sich einen Datenkatalog vor, der speziell für KI entwickelt wurde. Anstatt Dokumentationen zu durchsuchen oder Kollegen zu fragen, ob jemand schon einmal die monatliche Kaufgeschwindigkeit berechnet hat, können Data Scientists Funktionen in ihren ML-Projekten entdecken, wiederverwenden und teilen.

Ein Feature Store bietet jedoch mehr als nur einen Katalog von Features. Er löst drei kritische Probleme:

1. Wiederverwendung von Features: Ermöglicht es Entwicklungsteams, vorhandene Features zu entdecken und wiederzuverwenden, anstatt sie von Grund auf neu zu erstellen.
2. Konsistenz zwischen Training und Bereitstellung: Er sorgt für Konsistenz, sodass Modelle in Training und Produktion identische Feature-Berechnungen verwenden, um das gefürchtete Problem „Es hat in meinem Notebook funktioniert“ zu vermeiden.
3. Operative Einfachheit: Ermöglicht die Verwaltung von Feature-Pipelines, Versionierung und Monitoring über eine einzige Oberfläche.

Red Hat OpenShift AI umfasst als native Komponente der Plattform eine integrierte Feature Store-Funktion, die auf dem Open Source-Projekt Feast basiert. Es ist keine separate Installation erforderlich. Die Lösung ist verfügbar und kann aktiviert werden, sobald Ihre Teams bereit sind, funktionsorientierte Entwicklungspraktiken einzuführen.

Die Möglichkeit mit einem einheitlichen Daten-Gateway

Feast kann als eine einzige, konsistente Zugriffsschicht für alle Ihre KI-Daten-Pipelines dienen. Feast basiert auf einer bewährten Open Source-Basis mit mehr als 6.500 GitHub-Sternen und mehr als 16 Millionen Downloads und verbindet Datenquellen, Compute Engines (Ray/Spark) und Orchestratoren (KFP/Airflow) zu einem einheitlichen Katalog, sodass Unternehmen anbieterneutrale Daten erstellen können.

Das Pipeline-Frontend: Komplexe KI-Daten-Workflows vereinfachen

Der Feature Store von Red Hat OpenShift AI unterstützt diesen einheitlichen Ansatz:

• Anbieterneutrale Basis: Integration mit Spark, Ray, Milvus, Elastic, Postgres und vielen anderen gängigen Datenbanken – Sie wählen Ihre Infrastruktur.
• Vollständige Pipeline-Transparenz: Von Rohdaten über Feature Engineering bis hin zur Modellinferenz
• Freie Hybrid-Bereitstellungen: Einheitliche Ausführung in On-Premise-, Cloud- und Edge-Umgebungen
• Open Source-Innovation: Basiert auf der bewährten Basis von Feast mit über 16 Millionen Downloads und wird von vielen Unternehmen genutzt und mitgestaltet, darunter Shopify, NVIDIA, Walmart und mehr.

Dieser Ansatz löst auch reale Herausforderungen für Unternehmen. Bundesbehörden können sensible Daten lokal verarbeiten und gleichzeitig Cloud Computing nutzen. Finanzinstitute können Compliance-Anforderungen erfüllen und gleichzeitig ihre operative Flexibilität wahren. Fertigungsunternehmen können Daten am Edge verarbeiten und gleichzeitig eine Verbindung zu zentralen Analysen herstellen.

Die 3-Schichten-Architektur: Daten, Computing und Katalog

Der Ansatz von Red Hat zur KI-Datenverwaltung basiert auf einer einfachen, aber überzeugenden Erkenntnis: Die besten Unternehmensplattformen verbinden bestehende Infrastrukturen, anstatt sie zu ersetzen. Wir zeigen Ihnen anhand der Geschichte eines Finanzdienstleistungsunternehmens, das Feature Stores einführt, wie dies in der Praxis funktioniert.

Schicht 1: Datenquellen – Ihre Daten dort abrufen, wo sie sich befinden

Betrachten wir eine große Bank, die eine Betrugserkennung implementiert. Ihre Kundendaten befinden sich in einer lokalen Oracle-Datenbank (Anforderungen an die Einhaltung gesetzlicher Bestimmungen), Transaktionsströme fließen über Kafka auf AWS (moderne Echtzeitverarbeitung), und historische Muster befinden sich in einem Snowflake Data Warehouse (Investition des Analyseteams vor drei Jahren).

Herkömmliche Feature Store-Lösungen erzwingen eine Wahl: Entweder alles zur Plattform migrieren oder den Feature Store überhaupt nicht nutzen. Dies führt zu einer sehr schwierigen Situation: Die Oracle-Datenbank kann aufgrund von Compliance-Bestimmungen nicht verschoben werden, das Team will seine Snowflake-Investition nicht aufgeben, und die Echtzeit-Kafka-Pipelines sind entscheidend für den Betrieb.

Der Feature Store von Red Hat löst dies durch universelle Datenkonnektivität:

• Ortsunabhängige Verbindung: Features können aus lokalen Datenbanken, Cloud Storage, Edge-Sensoren und Streaming-Plattformen abrufen - in derselben Feature-Definition.
• Investitionen erhalten: Das Team für Betrugserkennung kann seine bestehende Infrastruktur ohne Migrationskosten oder Betriebsunterbrechungen weiter nutzen.
• Compliance gewährleisten: Sensible Kundendaten verbleiben in der konformen On-Premise-Datenbank, während der Feature Store den kontrollierten Zugriff orchestriert.

Das Team für Betrugserkennung der Bank definiert seine Features einmalig: „customer_transaction_velocity_30d“, „account_risk_score“, „merchant_category_pattern“ – und der Feature Store übernimmt die Komplexität des Abrufens aus Oracle, des Zusammenführens mit Kafka-Streams und der Anreicherung mit Snowflake-Historie. Data Scientists müssen keine JOIN-Anweisung mehr schreiben, um diese Quellen zusammenzuführen.

Schicht 2: Datenverarbeitung – Flexibilität für verschiedene Workloads

Sehen wir uns nun an, wie diese Features berechnet werden. Das Team für Betrugserkennung muss täglich Milliarden von Transaktionen verarbeiten, aber verschiedene Features haben unterschiedliche Anforderungen an die Rechenleistung:

• Einfache Aggregationen (Transaktionszählungen) werden effizient in SQL ausgeführt.
• Die Erkennung komplexer Muster (Verhaltensanomalien) erfordert Spark für die verteilte Verarbeitung.
• Für die Risikobewertung in Echtzeit (Latenz unter einer Sekunde) ist schlankes Streaming Computing erforderlich.

Die meisten Feature-Plattformen zwingen Sie, ihre bevorzugte Compute Engine zu verwenden. Wenn Sie in Spark-Expertise und -Infrastruktur investiert haben, wird Ihnen gesagt, Sie sollen diese aufgeben und sich mit dem proprietären System vertraut machen. Wenn Sie Ray für ML-intensive Transformationen benötigen, haben Sie Pech.

Der Feature Store von Red Hat bietet Computing-Flexibilität:

• Anbieterneutrale Engines: Native Unterstützung für Ray und Spark sowie die Möglichkeit, Ihr eigenes Compute-Framework (Spark, Ray usw.) zu verwenden
• Offene Standards: Features, die mit Standard-Python und SQL definiert werden, nicht mit proprietären DSLs, die eine Anbieterbindung schaffen.

Das Team für Betrugserkennung führt seine einfachen Aggregationen in Postgres (bereits bereitgestellt) aus, führt komplexe Verhaltensmodelle in seinem bestehenden Spark-Cluster aus (wodurch jahrelange Infrastrukturinvestitionen erhalten bleiben) und stellt Echtzeit-Scoring-Engines an den Standorten der Zweigstellen bereit, um Betrug sofort zu erkennen. Einheitliche Feature-Definitionen bei unterschiedlichen Compute-Strategien je nach Geschäftsanforderungen

Schicht 3: Einheitlicher Katalog – Ihre zentrale Schnittstelle zu allen Features

Hier beginnen die Herausforderungen. Das Team für Betrugserkennung hat mehr als 50 Features definiert, die aus drei Datenquellen stammen und auf zwei Computing-Plattformen ausgeführt werden. Ohne einen einheitlichen Katalog passiert Folgendes:

• Data Scientists verschwenden Stunden damit, Git-Repositories, Jupyter-Notebooks und das Wissen des Teams zu durchsuchen, um herauszufinden, ob jemand bereits einen Rechner für die monatliche Transaktionsgeschwindigkeit erstellt hat.
• Wenn sie ein Feature finden, stellen sie fest, dass es nicht kompatibel ist – unterschiedliche Spaltennamen, unterschiedliche Zeitstempel, unterschiedliche Aggregationsfenster.
• Production Engineers haben Schwierigkeiten, Feature-Abhängigkeiten zu verstehen: Welche Features basieren auf welchen Datenquellen und Rechenaufträgen?
• Compliance-Beauftragte können die Frage nicht beantworten, wer Zugriff auf sensible Kunden-Features hat.

Der einheitliche Katalog (Feast) löst all diese Probleme:

• Einheitliche Oberfläche: Data Scientists finden alle 50 Features über eine Suchoberfläche – kein Durchsuchen von Repositories oder Nachfragen in Slack.
• Vollständige Pipeline-Transparenz: Jedes Feature zeigt genau, woher die Daten stammen, welche Rechenleistung erforderlich ist und welche Modelle sie nutzen.
• Unternehmensgerechte Governance: Dank der integrierten rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) erhalten nur autorisierte Teams Zugriff auf sensible Features. Vollständige Audit-Trails verfolgen jeden Zugriff, und Genehmigungs-Workflows setzen Standards für Deployments in der Produktion durch.

So sieht dies für zwei verschiedene Nutzende aus:

Admin-Workflow (Plattformteam):

1. Feature Store aktivieren: Navigieren Sie im OpenShift AI Dashboard zu den Feature Store-Einstellungen und aktivieren Sie die Komponente (integriert, keine separate Installation).
2. Berechtigungen konfigurieren: Definieren Sie, welche Data Science-Teams Features erstellen und welche nur Features nutzen können und welche Datenquellen für jedes Team zugänglich sind.
3. Operationen überwachen: Das Dashboard zeigt den Zustand der Feature-Pipeline, die Ressourcenauslastung und die Datenaktualität an.

Data Scientist-Workflow:

1. Features entdecken: Durchsuchen Sie den Feature-Katalog nach „transaction“ – finden Sie zwölf vorhandene Features, darunter „customer_transaction_velocity_30d“, das vom Betrugsteam im letzten Quartal erstellt wurde.
2. Kontext verstehen: Klicken Sie auf das Feature, um Datenquellen (Kafka-Transaktionen + Oracle-Kunden), Rechenanforderungen (Spark-Job, wird täglich ausgeführt) und Beispielcode für die Verwendung anzuzeigen.
3. Wiederverwendung in neuem Modell: Kopieren Sie die Feature-Definition in das Projekt mit der Empfehlungs-Engine und erhalten Sie dieselbe Berechnungslogik und Konsistenz zwischen Betrugserkennung und Empfehlungen.
4. Schnelle Iterationen: Starten Sie vorintegrierte Jupyter-Notebooks direkt aus dem Feature-Katalog mit bereits konfigurierter Authentifizierung.

Das Ergebnis: Was früher drei Tage Recherche, fünf Slack-Gespräche und das Debuggen inkonsistenter Berechnungen erforderte, dauert jetzt zehn Minuten. Wenn das Betrugsteam seine Berechnung der Transaktionsgeschwindigkeit verbessert, profitieren alle nachgelagerten Modelle automatisch von der Verbesserung.

Das ist der Mehrwert eines einheitlichen Katalogs: Durch jedes neue Feature wird die KI-Entwicklung im gesamten Unternehmen schneller, zuverlässiger und konsistenter.

Die geschäftlichen Auswirkungen: Vom taktischen Tool zur strategischen Plattform

Diese 3-Schichten-Architektur wandelt Feature Stores von einer taktischen Komponente in ein strategisches Daten-Gateway um, das den gesamten KI-Datenverbrauch orchestriert. Anstatt separate Pipelines für verschiedene KI-Initiativen zu verwalten, richten Sie einen einzigen, kontrollierten Einstiegspunkt ein, der herkömmliche ML-Modelle, generative KI-Anwendungen und fortschrittliche hybride Workflows bedient.

Die geschäftlichen Auswirkungen sind transformativ:

• Schnellere Innovation: Data Scientists entdecken und verwenden Features projektübergreifend wieder, anstatt sie von Grund auf neu zu erstellen, wodurch die Markteinführungszeit verkürzt wird.
• Stärkere Governance: Einheitlicher Kontrollpunkt für Datenzugriffsrichtlinien, Audit-Trails und Compliance-Anforderungen für alle KI-Initiativen
• Mehr Wirtschaftlichkeit: Gemeinsam genutzte Infrastruktur und wiederverwendbare Assets senken die Kosten pro Projekt und verbessern gleichzeitig die Qualität.
• Strategische Flexibilität: Plattformunabhängige Architektur, die sich an die Entwicklung Ihres Technologie-Stacks anpasst und Ihre Innovationsfähigkeit erhält.

Da KI immer mehr zum zentralen Bestandteil geschäftlicher Abläufe wird, können Sie mit der frühzeitigen Einführung einer anbieterneutralen Dateninfrastruktur einen nachhaltigen Wettbewerbsvorteil durch Innovationsgeschwindigkeit und operative Exzellenz erzielen.

Fazit: Aufbau Ihrer KI-Datengrundlage für den Erfolg

Die Feature Store-Funktion von Red Hat OpenShift AI ist mehr als nur eine Lösung für das Feature-Management – sie ist Ihre Plattform für den Aufbau eines anbieterneutralen KI-Datenökosystems, das Ihnen hilft, Innovationen zu beschleunigen, Abläufe zu optimieren und strategische Flexibilität zu erhalten.

Ihre Datenstrategie ermöglicht die Zukunft Ihrer KI: Bauen Sie auf einer Basis auf, die mit den Fähigkeiten Ihres Unternehmens wächst und gleichzeitig die Flexibilität für Innovationen bewahrt.

Einstieg

Sind Sie bereit, den Feature Store-Ansatz für Ihr Unternehmen zu erkunden?

• Testversion starten: Red Hat AI Testversion
• Feast-Beispiele testen: Community-Demos und -Tutorials
• Erfolgreiche KI-Einführung mit Red Hat: Consulting Services für KI
• Kontaktieren Sie das Team: jzarecki@redhat.com
• Code erkunden: Feast GitHub Repository
• Weitere Informationen: OpenShift AI Documentation