Scalierung von Feature-Engineering-Pipelines mit Feast und Ray
Bei der Entwicklung von Propensity-Modellen zur Vorhersage zukünftiger Käufe stieß ich auf typische Herausforderungen im Bereich Feature Engineering, die sich in zwei Hauptkategorien unterteilen lassen: unzureichende Feature-Verwaltung und hohe Latenz bei der Feature-Generierung. Um diese Probleme zu lösen, wird in diesem Artikel die Kombination von Feast – einem Open-Source-Feature Store – und Ray – einem verteilten Computing-Framework – vorgestellt, um skalierbare und effiziente ML-Pipelines zu realisieren. Das Ziel ist die Entwicklung eines 30-Tage-Propensity-Modells basierend auf dem UCI Online Retail-Datensatz (Dezember 2010 bis Dezember 2011), der Transaktionen eines britischen Online-Händlers enthält. Die Feature-Engineerung beschränkt sich auf RFM-Features (Recency, Frequency, Monetary Value) und Kundenverhaltensmerkmale, berechnet über einen 90-Tage-Blick zurück, wobei die Labels aus einem 30-Tage-Fenster nach dem jeweiligen Ausschnitt generiert werden. Dies ergibt neun zeitlich versetzte Daten-Snapshots. Feast fungiert als zentrale Datenbank für ML-Features und stellt sicher, dass Trainings- und Inference-Daten konsistent und punktgenau sind. Es unterstützt sowohl Offline- als auch Online-Features und ermöglicht eine zentrale Verwaltung über die sogenannten Feature Views, die die Struktur der Features definieren. Dabei ist die Angabe des event_timestamp entscheidend, um point-in-time correct Daten zu gewährleisten – eine Voraussetzung für fehlerfreie Modelle. Die Feature-Registry wird in PostgreSQL gehostet, um eine produktionsnahe Infrastruktur zu simulieren. Mit feast apply werden die Feature-Definitionen in der Registry synchronisiert. Ray dient als skalierbares Compute-Framework, das die parallele Ausführung von Feature-Engineering-Aufgaben ermöglicht. Durch die Verwendung von @ray.remote werden Funktionen als verteilte Tasks ausgeführt, was insbesondere bei der Verarbeitung mehrerer 90-Tage-Window (neun Cutoff-Dates) zu signifikanten Geschwindigkeitsgewinnen führt. Ray Core ermöglicht die verteilte Ausführung von Python-Funktionen über mehrere Kerne oder sogar Cluster, wodurch die Latenz bei der Feature-Generierung deutlich sinkt. Die Integration von Ray mit Feast als Offline Store beschleunigt zudem das Abfragen großer Feature-Datasets, da Join-Operationen und Datenzugriffe parallelisiert werden. Der Workflow beginnt mit der Datenvorbereitung, gefolgt von der parallelen Ausführung der Feature-Engineering-Funktionen über Ray. Anschließend werden die Features in Feast registriert, wobei die Struktur durch Entity, Data Source und Feature View definiert wird. Für Training und Inference wird ein Entity Spine (customer_id und event_timestamp) erstellt, über das Feast die korrekten Feature-Snapshots abruft. Die Konsistenz zwischen Trainings- und Inference-Phase wird dadurch gewährleistet, dass beide Schritte auf denselben Feature-Definitionen basieren. Industrieexperten betonen, dass die Kombination aus Feast und Ray eine signifikante Verbesserung der ML-Pipeline-Produktivität darstellt. Feast löst die klassischen Probleme der Feature-Duplizierung und Inkonsistenz, während Ray die Skalierbarkeit von Feature-Pipelines ermöglicht – besonders relevant für Unternehmen mit hohen Datenvolumina und zeitkritischen Anwendungen. Unternehmen wie Netflix, Uber und Airbnb nutzen ähnliche Architekturen, um ihre ML-Infrastruktur zu optimieren. Die Open-Source-Natur beider Tools ermöglicht eine schnelle Implementierung und Anpassung an spezifische Anforderungen. Zusammen bieten Feast und Ray eine robuste, skalierbare Basis für moderne, datengesteuerte ML-Systeme.
