Feature Store - Verwaltung mehrerer Datenquellen mit Feast

In dem Maße, wie die Bemühungen um die Produktion von ML-Workflows zunehmen, gewinnen auch Feature-Stores immer mehr an Bedeutung. Ihre Aufgabe ist es, standardisierte und aktuelle Funktionen bereitzustellen, die in Produktionsmodellen verwendet werden können. Sie ermöglichen die Wiederverwendung vorhandener Funktionen für verschiedene Modelle und dienen als Plattform für die Datenerkennung - eine Datenbank mit Metadaten zu Funktionen. Darüber hinaus können Feature-Stores begrenzte Funktionen für das Feature-Engineering bieten.

Nach der Anzahl der GitHub-Sterne zu urteilen, ist Feast derzeit die beliebteste Open Source Feature Store-Implementierung. Die kombinierten Datenermittlungsfunktionen von Feast und Amundsen wurden bereits in Mariusz' genialem Blogbeitrag vorgestellt Entdeckung von Machine Learning Features mit Feast und Amundsen. In diesem Blogpost erfahren Sie, wie Sie Point-in-Time-Joins für Daten aus verschiedenen Quellen aus einer relationalen Datenbank sowie aus einem Echtzeit-Datenstrom verwenden können, um produktionsreife Features bereitzustellen.

Schlemmer-Demo

Um die Fähigkeiten von Feast zu demonstrieren, haben wir eine Demo erstellt, die einen beispielhaften Geschäftsfall mit zwei Datenquellen enthält, von denen eine die Postgres-Datenbank und die andere ein Kafka-Thema ist. Der Quellcode ist hier auf GitHub verfügbar.

Nehmen wir den folgenden Geschäftsfall an: Ein E-Commerce-Unternehmen bietet auf seiner Website Produkte an. Das Unternehmen hat Zugriff auf Daten über Benutzer und ihre Bestellungen (die in Postgres gespeichert sind) und einen Datenstrom über den Website-Verkehr, der über Kafka-Themen aufgenommen wird.

Das Unternehmen möchte mit Hilfe von Feast Funktionen erstellen und diese nutzen, um das Verhalten seiner Kunden besser zu verstehen. Zusätzlich zu den Daten, die den Benutzer definieren (die aus der Postgres-Tabelle stammen), müssen Funktionen entwickelt werden, die auf Daten zum Webverkehr basieren, wie z.B. die Anzahl der Zugriffe auf die Angebots-, Produkt- und Fotoseiten.

Ein Beispiel für das Nutzerverhalten wurde modelliert und die entsprechenden Daten wurden mit dem unschätzbaren doge_datagen Projekt. Dies ist das Diagramm des Benutzerverhaltensmodells:

‌

Feast erfordert eine feature_store.yaml Konfigurationsdatei und eine oder mehrere Python-Dateien mit Feast-Objektdefinitionen. Die von uns getestete Konfiguration beinhaltete die Verwendung von Postgres als Offline-Speicher und Redis als Online-Speicher.

Die Unterstützung von Postgres und Kafka-Quellen ist eine Neuerung in Feast, die in den Versionen v0.21 bzw. v0.22 erscheint. Ab Version 0.23 befindet sich die Unterstützung von Kafka-Streams im experimentellen Stadium und wir glauben, dass die Schnittstelle noch verbessert werden kann. Wie in den Feast-Dokumenten angegeben, muss für Kafka-Quellen eine Batch-Quelle angegeben werden, die zum Abrufen von historischen Merkmalen verwendet werden kann. Selbst wenn der Kafka-Stream nur als Quelle für den Online-Speicher verwendet wird, muss also eine Mock-Batch-Quelle erstellt werden. In der Demo hatten wir also drei definierte Datenquellen:

Diese Quellen identifizierten ihre Datensätze anhand einer Teilmenge von drei definierten Entitäten: Benutzer, Bestellung und Web-Traffic-ID. Schließlich haben wir zwei Funktionsansichten definiert, eine für Bestellungsdetails und die andere für den Benutzerverkehr, die wir zur Erstellung einer einfachen Visualisierung verwendet haben. Nachfolgend finden Sie eine Animation eines Beispiel-Demolaufs:

‌

Um einen Schritt in der Visualisierung der Daten zu zeigen, haben wir Histogramme erstellt, die die erwartete Anzahl der Besuche auf den Angebots-, Produkt- und Fotoseiten pro erfolgreicher Transaktion zeigen. Wie Sie sehen können, weisen alle diese Histogramme ähnliche Verteilungen auf (was zu erwarten ist, da dies aus dem Datagen-Modell abgeleitet werden kann). Während die meisten Kunden sich bereits nach wenigen Klicks für den Kauf des Produkts entscheiden, scheinen einige lange zu überlegen, bevor sie schließlich auf das Einkaufswagensymbol klicken!

‌

Caveats
Während der Arbeit an der Demo sind wir auf einige Probleme gestoßen, die Sie vielleicht beachten sollten, insbesondere wenn Sie darüber nachdenken, Feast zur Implementierung von Feature Store in Ihrem eigenen Projekt zu verwenden. Die meisten dieser Probleme lassen sich auf das frühe Stadium des Projekts zurückführen. Achten Sie also darauf, regelmäßig neue Feast-Versionen zu lesen.
Die Feature-Extraktion befindet sich noch im Alpha-Stadium und ihre Möglichkeiten sind begrenzt. So werden z.B. in den Eingabedaten der "On Demand"-Feature Views keine Entity-Werte bereitgestellt, so dass der Datenrahmen nicht für die Extraktion von Aggregaten geeignet ist. Aufgrund dieser Einschränkung haben wir die Kafka-Quelldaten transformiert, bevor wir sie an Feast weitergegeben haben. Außerdem haben wir keine Möglichkeit gefunden, eine Zufallsstichprobe aus dem Offline/Online-Speicher zu ziehen. Laut Dokumentation ist es möglich, pd.Dataframe oder SQL bereitzustellen. Die SQL-Lösung scheint eleganter zu sein, aber es ist uns nicht gelungen, diese Option erfolgreich zu nutzen.
Darüber hinaus ist die Fehlersuche in der jetzigen Form eine Qual, da bei der Entwicklung der internen Bibliotheken jede Menge Ausnahmen auftreten. Wenn ein feast applies -Befehl zu einer Pandas- oder psycopg2-Ausnahme führt, erfordert die Suche nach dem Problem Phantasie und Zeit. Es scheint auch, dass Feast einige Annahmen über Schemata macht, die nicht dokumentiert sind. So kann es beispielsweise sein, dass das Feld für den Zeitstempel des Ereignisses und das Feld für den Zeitstempel der Erstellung einer definierten Quelle nicht dasselbe Feld ist. Dies führt dazu, dass eine definierte Quelle eine interne SQL-Generierungsausnahme auslöst. Während meiner Tests hat die Kafka-Online-Quelle auch stillschweigend versagt, Datensätze aufzunehmen, und zwar ohne jede Ausnahme, weil das Schema nicht übereinstimmt.
Es scheint jedoch, dass sich das Feast-Team des oben erwähnten Debugging-Problems bewusst ist und einige Korrekturen in späteren Versionen vorgenommen werden.
Feast Feature Store Demo Zusammenfassung
Feature Stores spielen eine wichtige Rolle bei der Operationalisierung von Machine Learning-Modellen und Feast ist sicherlich eines der beliebtesten Open Source-Projekte in diesem Bereich. Das Feast-Framework hat noch einige Kinderkrankheiten, die wir im vorigen Kapitel zusammengefasst haben, aber das Tempo der Verbesserung ist schnell und wir hoffen, dass die rauen Kanten im Laufe der Zeit beseitigt werden und der Produktivitätsmultiplikator der Lösung noch größer sein wird. Wenn Sie mehr über unsere anderen Feature Store-Implementierungen erfahren möchten, lesen Sie unseren Blogbeitrag Feature Store-Vergleich: 4 Feature Stores - erklärt und verglichen.

Interessieren Sie sich für ML- und MLOps-Lösungen? Wie können Sie ML-Prozesse verbessern und die Lieferfähigkeit von Projekten steigern? Sehen Sie sich unsere MLOps-Demo an und melden Sie sich für eine kostenlose Beratung an.