Flyte nach einem Jahr

Auf der Rennstrecke der ML-Anwendungsentwicklung werden die traditionellen Schritte der Softwareentwicklung oft überholt. Willkommen in der Welt von MLOps, in der einzigartige Herausforderungen auf innovative Lösungen treffen und Konsistenz König ist.

Bei Bazaarvoice bilden Trainings-Pipelines das Rückgrat unserer MLOps-Strategie. Sie sind die Grundlage für die Reproduzierbarkeit unserer Modell-Builds. Es gab jedoch eine eklatante Lücke bei der Überführung von experimentellem Code in die Produktion.

Anstatt weiter auf Stückwerk-Ansätze zu setzen, die oft stark auf Jupyter Notebooks ausgerichtet waren, haben wir festgestellt, dass es einen Standard braucht, mit dem Praktiker extrem schnell mit Machine-Learning-Modellen experimentieren und sie ausliefern können, während sie unsere Best Practices befolgen.

Bauen vs. Kaufen

Unmittelbar nach unseren Erfolgen bei der Vereinheitlichung unserer Strategie für das Deployment von Machine-Learning-Modellen (ML)Wird in neuem Fenster geöffnet mussten wir zunächst entscheiden, ob wir eine eigene, intern entwickelte Plattform zur Orchestrierung von ML-Workflows aufbauen oder externe Lösungen nutzen sollten.

Als wir uns für „Kaufen“ entschieden (es ist ja schließlich Open Source), erwies sich FlyteWird in neuem Fenster geöffnet als Workflow-Management-Plattform als klare Wahl. Das hat uns unschätzbar viel Entwicklungszeit gespart und unser Team einer robusten Self-Service-Infrastruktur nähergebracht. Eine solche Infrastruktur ermöglicht es unseren Ingenieuren, Modelle nahtlos zu entwickeln, zu evaluieren, zu registrieren und bereitzustellen. Statt das Rad neu zu erfinden, hat Flyte uns mit einem effizienten Rad ausgestattet, mit dem wir voranpreschen können.

Bevor wir uns für Flyte entschieden, begaben wir uns auf eine umfassende Evaluierungsreise. Bei der Wahl des richtigen Workflow-Orchestrierungssystems ging es nicht nur darum, ein Tool auszuwählen, sondern auch eine Plattform zu finden, die unsere Vision ergänzt und zu unseren strategischen Zielen passt. Wir kannten die Bedeutung dieser Entscheidung und wollten sicherstellen, dass wir alle Aspekte abgedeckt hatten. Am Ende standen als Tools Flyte, Metaflow, Kubeflow Pipelines und Prefect zur Auswahl.

Um eine fundierte Entscheidung zu treffen, haben wir eine Reihe von Kriterien aufgestellt:

Must-Haves:

• Entwicklungsfreundlichkeit: Das Tool sollte Entwickler intuitiv unterstützen, ohne steile Lernkurven.

• Einführung: Schnelle und unkomplizierte Einführungsmechanismen.

• Anpassung der Pipelines: Flexibilität, Pipelines an die jeweiligen Projektanforderungen anzupassen.

• Transparenz: Klare Einblicke in Prozesse für besseres Debugging und Verständnis.

Wünschenswertes:

• AWS-Integration: Nahtlose Integrationsmöglichkeiten mit AWS-Diensten.

• Metadatenspeicherung: Effiziente Speicherung und Abfrage von Metadaten.

• Startzeit: Schnelle Initialisierung zur Verringerung der Latenz.

• Caching: Optimales Daten-Caching für schnellere Ergebnisse.

Neutral, aber bemerkenswert:

• Sicherheit: Robuste Sicherheitsmaßnahmen gewährleisten den Schutz der Daten.

• Benutzer verwaltung: Funktionen, die die Verwaltung von Benutzern und die Zugriffskontrolle erleichtern.

• Kosten: Erschwinglichkeit: ein gutes Gleichgewicht zwischen Funktionen und Preis.

Warum Flyte überzeugte: Die wichtigsten Kriterien im Blick

Bei genauerer Betrachtung unseres Auswahlprozesses erfüllte Flyte durchweg unsere wichtigsten Kriterien und übertraf dabei oft die Fähigkeiten anderer in Betracht gezogener Tools:

1. Entwicklungsfreundlichkeit: Pure Python | Task Decorators Python-native Entwicklungserfahrung

2. Pipeline Customization Passen Sie jeden Workflow und jede Aufgabe ganz einfach an, indem Sie den Task-Decorator ändern

3. Bereitstellung: Kubernetes-Cluster

4. Sichtbarkeit Leicht zugängliche Container-Logs

5. Flyte Decks ermöglichen Reporting-Visualisierungen

6. Die native Kubernetes-Integration von Flyte vereinfachte den Bereitstellungsprozess.

Die Bazaarvoice-Individualisierung

Wie bei jeder Plattform brachte Flyte zwar viele Vorteile, wir brauchten aber eine andere Plug-and-Play-Lösung für unsere besonderen Anforderungen. Wir rechneten damit, dass die Plattform in unserer Organisation neu sein würde. Wir wollten die Lernkurve so weit wie möglich verkürzen und unseren Entwicklern einen reibungslosen Übergang ermöglichen, ohne sie zu überfordern.

Um den Übergang zu erleichtern und den Entwicklungsprozess zu beschleunigen, haben wir eine CookiecutterWird in neuem Fenster geöffnet-Vorlage entwickelt, die Entwicklern als Startrampe dient und einen strukturierten Ausgangspunkt bietet, der standardisiert und an Best Practices für Flyte-Projekte ausgerichtet ist. Diese Struktur versetzt Entwickler in die Lage, Trainings-Pipelines schnell aufzubauen.

Die relevantesten Dateien der Vorlage sind:

• Pipfile – Beschreibt die Projektabhängigkeiten im Detail

• Dockerfile - Erstellt den Docker-Container

• Makefile - Hilfsdatei zum Erstellen, Registrieren und Ausführen von Projekten

• README.md - Beschreibt das Projekt

• src/ tasks/

• Workflows.py (folgt dem Kedro-Standard für DatenschichtenWird in neuem Fenster geöffnet) process_raw_data – Workflow zum Extrahieren, Bereinigen und Transformieren von Rohdaten

• generate_model_input - Workflow zur Erstellung von Trainings-, Test- und Validierungsdatensätzen

• train_model - Workflow zur Erzeugung eines serialisierten, trainierten Machine-Learning-Modells

• generate_model_output - Workflow zur Vermeidung von Train-Serving-Skew durch Inferenz auf dem Validierungsdatensatz mit dem trainierten Machine-Learning-Modell

• evaluate - Workflow zur Bewertung des Modells anhand einer gewünschten Reihe von Leistungskennzahlen

• reporting - Workflow zur Zusammenfassung und Visualisierung der Modellleistung

• full - vollständige Flyte-Pipeline zur Erzeugung eines trainierten Modells

• tests/ - Unit-Tests für Ihre Workflows und Tasks

• run - Vereinfacht die Ausführung von Workflows

Außerdem besteht eine häufige Herausforderung bei der Entwicklung von Pipelines darin, dass Ressourcen benötigt werden, die über das hinausgehen, was unsere lokalen Rechner bieten. Oder es gibt Aufgaben, die längere Laufzeiten erfordern. Flyte bietet durchaus die Möglichkeit, lokal zu entwickeln und remote auszuführen. Dies erfordert jedoch eine Reihe von Schritten:

• Erstellen Sie Ihr benutzerdefiniertes Docker-Image nach jeder Codeänderung neu.

• Weisen Sie diesem neuen Docker-Image ein Versions-Tag zu und pushen Sie es nach ECR.

• Registrieren Sie diese neue Workflow-Version bei Flyte und aktualisieren Sie dabei das Docker-Image.

• Weisen Sie Flyte an, genau diese Version des Workflows auszuführen, und parametrisieren Sie dabei über die CLI.

Um diese Herausforderungen zu umgehen und den Entwicklungsprozess zu beschleunigen, haben wir das Makefile und das Run-Skript der Vorlage so gestaltet, dass sie die oben genannten Schritte in einem einzigen Befehl zusammenfassen!

./run —remote src/workflows.py full

Das Makefile verwendet ein paar Hilfs-Targets, bietet aber insgesamt die folgenden Befehle:

• info - Gibt Informationen zu diesem Projekt aus

• init - Richtet das Projekt in flyte ein und erstellt ein ECR-Repository

• build - Erstellt das Docker-Image

• push - Überträgt das Docker-Image nach ECR

• package - Erstellt das flyte-Paket

• register - Registriert die Version in flyte

• runcmd - Erzeugt den Ausführungsbefehl für lokal und remote

• test - Führt alle Tests für den Code aus

• code_style - Wendet die Formatierung black & flake8 an

Wichtige Erfolge

Mit Flyte als zentralem Bestandteil unserer Machine-Learning-Plattform haben wir in der ML-Entwicklung eine beispiellose Dynamik erreicht. Es ermöglicht schnelles Experimentieren und Bereitstellen unserer Modelle und stellt sicher, dass wir stets Best Practices einhalten. Über die Ausrichtung an grundlegenden MLOps-Prinzipien hinaus sorgen unsere Anpassungen dafür, dass Flyte unsere spezifischen Anforderungen perfekt erfüllt und die Konsistenz und Zuverlässigkeit unserer ML-Modelle gewährleistet.

Abschließende Gedanken

So wie Rennfahrer beim Überqueren der Ziellinie Hochgefühl empfinden, erfüllt unser Team ein riesiges Gefühl der Leistung, wenn es sieht, wie unsere Machine-Learning-Vorhaben mit Flyte durchstarten. Wenn wir nach vorn blicken, sind wir optimistisch und bereit, die neuen Herausforderungen und Meilensteine anzugehen, die vor uns liegen. 🏎️

Wenn Sie diese Art von Arbeit reizt, schauen Sie sich unsere StellenangeboteWird in neuem Fenster geöffnet an.

Über den Autor

Edgar Trujillo ist MLOps-Spezialist bei Bazaarvoice und auf den gesamten Modelllebenszyklus vom Training bis zur Produktion spezialisiert. Bevor er zu Bazaarvoice kam, arbeitete er als ML Engineer im CTML-Team von JP Morgan und unterstützte interne Compliance- und Rechtsteams bei der Datenanalyse. Außerdem sammelte er bei einem Praktikum in einem E-Auto-Start-up Erfahrung im Bereich selbstfahrender Autos; seine Forschung zur Vorhersage von Fahrerverhalten führte dort zu einem Patent. In seiner Freizeit beschäftigt sich Edgar gern mit Fotografie, reist und bleibt bei den neuesten Netflix-Veröffentlichungen auf dem Laufenden.