Von Zeit zu Zeit taucht am Horizont der Technologielandschaft ein neues Softwaresystem auf. In diesem Beitrag befassen wir uns mit so einer neuen Datenzugriffs- und -verarbeitungsschicht: dem Feature Store. Er wird eine wichtige Rolle bei der Konstruktion intelligenter Systeme spielen, die auf Algorithmen des maschinellen Lernens (ML) basieren.

Aber benötigt der immer schwerer werdende Technologie-Werkzeugkasten von Data Engineers noch ein weiteres Tool? Ja, denn Feature Stores sind großartig. Sie reduzieren die Komplexität eines Systems und verkürzen so den Bereitstellungszyklus von ML-Modellen. Um herauszufinden warum, müssen wir zunächst definieren, was ein Feature ist, welche Aufgabe ein Feature Store hat und wie wir dadurch bessere Ergebnisse in ML-Projekten erzielen können. Ready? Let´s go!

Was ist ein Feature?

Ein Feature ist eine unabhängige, messbare Variable, die als Input für das Training eines ML-Modell dient. Statistiker bezeichnen ein Feature als statistische Variable. Für Data Engineers hingegen ist ein Feature ein Attribut im Schema einer relationalen Datenbank, es lässt sich also beispielhaft als einzelne Spalte einer Datentabelle beschreiben.

Feature Stores haben ihren Namen von den Feature-Vektoren, die als Eingabe für ML-Modelle verwendet werden. Je nach ML-Modell gibt es unterschiedliche Anforderungen an einen Feature-Vektor. Random Forests sind beispielsweise ziemlich uneingeschränkt und erlauben kategorische Daten und nicht-standardisierte numerische Daten, während neuronale Netze hingegen nur mit standardisierten numerischen Daten arbeiten.

Beispiel: In der oberen Tabelle sind drei Attribute und ein Vorhersageattribut (Spalte „target“) dargestellt. Das hypothetische Modell, welches wir trainieren möchten, benötigt numerische Eingaben, um eine überwachte Klassifizierung in die beiden Ausprägungen des Vorhersageattributes, Hund (dog) und Katze (cat), vorzunehmen. Daher müssen wir die kategorischen und booleschen Attribute umwandeln. Die untere, transformierte Tabelle enthält die endgültigen Features. Auf das Ausgangsattribut Farbe haben wir eine One-Hot-Kodierung angewandt und auf das boolesche Attribut Schnurrhaare eine Binärisierung.

Die untere Tabelle beinhaltet einen einzelnen Feature-Vektor pro Zeile. Jede Entität, also jeder einzelne „Hund“ oder „Katze“, ist mit einer Zeile assoziiert. Jedes einzelne Feature, zum Beispiel die Größe (height), wird durch eine Spalte dargestellt. Dieser Prozess der Generierung von Features wird als Feature Engineering bezeichnet. Ziel es ist, Features mit einem hohen Informationsgewinn auszugeben und Features mit minimaler Korrelation zu kombinieren. Auf diese Weise können ML-Modelle Vorhersagen möglichst gut generalisieren und gleichzeitig Fehler erster und zweiter Art minimieren. Um qualitativ hochwertige Features zu erhalten, ist ein iterativer Ansatz erforderlich. Manuell ist dieser Prozess sehr langwierig und kann inkonsistent sein. Hier naht der Feature Store zur Rettung.

Warum brauchen wir einen Feature Store?

Feature Stores heben Datenaktualität auf ein neues Level, ermöglichen genauere Modelle durch Zugriff auf konsistentere Daten und helfen so, präzisere Vorhersagen zu treffen. Das Berechnen und Speichern von Features ermöglichen die Entdeckung, Registrierung und Nutzung von einheitlichen Features über die Grenzen einzelner Projekte hinaus.

Verfechter der agilen Softwareentwicklung predigen iterative Vorgehensweisen, um die Anforderungen des Kunden schneller zu erfüllen oder zu validieren. Iteration wird durch Automatisierung ermöglicht. Kleine Änderungen werden am Quellcode vorgenommen, anschließend werden sie mit einem anderem Code überprüft, um sicherzustellen, dass die Änderungen nichts kaputt machen. In einem intelligenten System ist Iteration allerdings eine große Herausforderung, weil Datenexperten – die für die Konzeptionierung und den Bau des Systems benötigt werden – unterschiedliche Sprachen sprechen.

Ein Data Scientist erhält einen anfänglichen Daten-Dump, die Rohdaten, und erstellt mithilfe einer Vorverarbeitungspipeline im Kontext des Notebooks ein Modell. Anschließend operationalisiert ein Data Engineer diese Pipeline, um dem Datenvolumen und der Datengeschwindigkeit Rechnung zu tragen. Hierfür nutzen Data Engineers verteilte Datenverarbeitungsplattformen wie Spark oder Flink. Schließlich integriert ein ML-Engineer das Modell in eine Anwendung, wobei das Modell möglicherweise neu geschrieben wird, um die Interferenzzeit zu optimieren und den Rechenbedarf eines Modells zu senken.

Der beschriebene Prozess und die unterschiedlichen Fähigkeiten der Akteure verlangsamen die Einführung neuer Modelle in eine Produktionsumgebung. Noch schwerwiegender sind Inkonsistenzen bei der Neuimplementierung von Datentransformationen. Inkonsistenzen führen zu einer Verzerrung der Trainings- und Interferenzdaten – was sich nachteilig auf die Vorhersageergebnisse eines Modells auswirkt. Darüber hinaus werden Features isoliert, die in verschiedenen Projekten generiert werden – was wiederum ihre Entdeckung erschwert. Die MLOps-Bewegung will diese Probleme allgemein beantworten. Jedoch besteht die Tendenz, dass MLOps sich mehr auf ML-Modelle und weniger auf Daten und Features konzentriert. Daher bedarf es einer Technologie, die die Fähigkeiten der unterschiedlichen Datenexperten unterstützt und ein gemeinsames Verständnis der Datenpipelines schafft.

Ziele eines Feature Stores:

• Reduzierte Reibungen zwischen verschiedenen Rollen (Data Scientist, Data Engineer, ML-Engineer)
• Einfache Auffindbarkeit von Features zwischen verschiedenen Projekten
• Einheitliche Namensgebung und Datentypen von Features
• Verhinderung von unterschiedlichen Verteilungen von Features zwischen Training und der Inferenz

Was ist ein Feature Store?

Ein Feature Store ist eine Plattform, auf der alle Features zentralisiert und für alle zugänglich sind, so dass sie in verschiedenen Projekten wiederverwendet können. Der Feature Store gilt als „single source of truth“ für alle ML-Projekte und ermöglicht so die konsistente Entdeckung, Berechnung und Nutzung von Features.

Die meisten Feature Stores haben drei gemeinsame Komponenten: eine Transformationsschicht, eine Speicherschicht und eine Auslieferungsschicht. Je nach den Anforderungen einer Datenanwendung und den beteiligten Akteuren in einer Projektphase können die drei Komponenten oft in einer Art Batch- oder Stream-Verarbeitung eingesetzt werden.

Feature stores aim to solve the full set of data management problems encountered when building and operating operational ML applications.

David Hershey (@tectonAI)

Transformation

Der Coursera-Gründer und ML-Experte Andrew Ng erklärte bereits 2013, dass das Feature-Engineering ein entscheidender Schritt bei der Entwicklung eines intelligenten Systems ist. Daher müssen wir den Transformationsschritt mit erhöhter Aufmerksamkeit angehen. Bei der Transformation von Rohdaten in ein Feature sind mehrere Schritte erforderlich:

Zunächst müssen die Daten aus verschiedenen Datenplattformen integriert werden. Dann muss die Qualität sichergestellt werden, indem alle Schritte, die mit dem Data Wrangling verbunden sind, durchgeführt werden. Schließlich werden die Datentuples so aufbereitet, dass sie von einem ML-Modell verwendet werden können. Dieser letzte Schritt beinhaltet Transformationen wie One-Hot-Codierung oder die Standardisierung des Wertebereichs eines Features. In seltenen Fällen ist es sogar möglich, dass die Transformation selbst ein ausgeklügeltes ML-Modell verwendet, um Features zu generieren. Ein Beispiel hierfür sind sentence embeddings, die aus natürlicher Sprache gewonnen werden. Diese komplexe Pipeline wird auf die historischen Rohdaten angewandt. Exakt dieselben Schritte müssen aber auch durchgeführt werden, um die Input-Feature-Vektoren der Inferenzzeit zu erstellen. Der Feature Store dient also als „single source of truth“ und stellt sicher, dass die Features für das Training und den Betrieb durch die exakt gleichen Pipeline-Definitionen erzeugt werden. Pipelines für ML-Anwendungen können so iterativ erstellt werden, indem das Fachwissen von Data Scientists als auch Data Engineers genutzt wird.

Persistenz

Bei der Speicherung von Features gibt es zwei verschiedene Szenarien, die ein Feature Store unterstützen muss. Im ersten Szenario braucht ein Feature Store ein Backend für die Speicherung historischer Features. Historische Features dienen als Trainingsdaten für ML-Modelle. In der Regel werden für diese Aufgabe Data-Warehouse-Systeme verwendet. Manchmal werden Features auch direkt in einem Data Lake gespeichert. Im Zweiten werden Features durch Streaming-Transformation erzeugt und in einem Key-Value-Store persistiert. Die Erstellung des Speicher-Backends eines Feature Stores sollte dabei in beiden Fällen von einem Data Engineer verwaltet werden.

Auslieferung

Ähnlich zu den vorherigen Komponenten eines Feature Stores unterstützt auch die Web API zur Auslieferung der Features einen Batch- und eine Low-Latency-Modus. Die Batch-API wird von Data Scientists genutzt, um Trainingsdaten für Modelle zu erhalten, und die Low-Latency-API wendet die Transformationspipeline auf ein einzelnes Datum (oder mehrere Daten) an, damit es von einem nachgelagerten Modell genutzt werden kann.

Das sind die drei gängigsten Komponenten eines archetypischen Feature Stores. Es gibt noch weitere Komponenten wie ein Überwachungssystem für die APIs, die automatische Erkennung von Concept Drifts sowie ein Metadaten-Repository, um Features zwischen Projekten leichter zu finden. Allerdings ist diese noch recht junge Technologie nach wie vor sehr fluide, wobei die drei Kernstücke (Transformation, Persistenz und Auslieferung) immer die Grundlagen eines Feature Stores darstellen.

Drei Feature Stores

Tecton

Tecton ist ein gehosteter SaaS Feature Store, der sich an Unternehmen richtet, die auf AWS arbeiten. Einer der größten Nutzer ist Atlassian, das Unternehmen hinter Jira, Confluence und Trello. Atlassian berichtet, dass die Bereitstellung neuer Features für ML-Modelle, welche sich bereits in der Produktion befanden, von 1 bis 3 Monaten auf einen einzigen Tag verkürzt wurde. Unter der Haube wird Tecton von Delta Lake, S3 und DynamoDB für die Speicherung angetrieben und nutzt Spark zur Transformation. Aus einer operationellen Sicht läuft die Auslieferungs-Komponente über Tectons Cloud-Umgebung. Die Transformations- und Speicherkomponenten liegen in der Hand des Nutzers (weitere Informationen unter DeployingTecton).

Feast

Feast ist ein Open Source Feature Store, der in jeder Kubernetes-Umgebung eingesetzt werden kann. Tecton ist einer der Hauptakteure bei der Entwicklung von Feast. Die Funktionen von Feast bilden eine Teilmenge der von Tecton. Der Hauptunterschied besteht darin, dass Feast keine zentrale Instanz für Feature-Transformationen bereitstellt und daher nur bereits vorberechnete Features speichert. Außerdem bietet Tecton mehr Überwachungsfunktionen, z. B. zur Erkennung von Verschiebungen in den Verteilungen der Features. Wir empfehlen, Feast für einen kleinen Proof-of-Concept zu nutzen und anschließend auf Tecton zu migrieren. Da die Feature-Auslieferungs-APIs beider Systeme sich stark ähneln, ist die Migration recht simpel.

Databricks Feature Store

Der Databricks Feature Store ist eng in das Cloud-agnostische Databricks-Ökosystem integriert und bildet eine Unterkomponente der Databricks Machine Learning Platform. Sollte ein Team bereits Erfahrung mit Transformationen in Spark haben, ist die Nutzung des Databricks Feature Store ein Kinderspiel. Außerdem können die vom Databricks Feature Store erzeugten Features direkt mit den Model-Serving-Funktionen von MLFlow genutzt werden. Intern speichert der Databricks Feature Store die Features in einer Tabelle mit Versionsnachweis, was eine Rückverfolgung der Datenherkunft ermöglicht. Im Vergleich zu Tecton fehlen dem Databricks Feature Store jedoch Funktionen zur Überwachung der Datenqualität. Abgesehen von diesem kleinen Nachteil bietet der Databricks Feature Store durch die enge Integration zu anderen Databricks-Services die beste Nutzererfahrung unter den drei vorgestellten Feature Stores.

Fazit

Wer konsistentere Pipelines, besser auffindbare und konstante Features sowie iterative Zusammenarbeit fördern möchte, sollte über die Implementierung eines Feature Stores nachdenken. Ein Feature Store besteht aus drei Komponenten, die sowohl Batch- als auch Streaming-Verarbeitung unterstützen und auf mehreren Ebenen die Exploration und Bereitstellung konsistenter Features fördern.  Alle Konzepte und Funktionen dieser (noch) neuen Technologie zu behandeln, wäre eher etwas für ein Buch als für einen Blogbeitrag, dennoch sollte das grundlegende Ziel klar sein: Feature Stores ermöglichen die Implementierung und Wiederverwendung konsistenter Features und fördern die iterative Zusammenarbeit zwischen verschiedenen Rollen im ML-Lifecycle. Langfristig hat die Technologie das Potenzial, die Art und Weise wie wir intelligente Systeme entwickeln, grundlegend zu verändern.