Das Design der Modellproduktionsarchitektur in Data Science

Viele Unternehmen haben Schwierigkeiten, ihre Data-Science-Projekte in die Produktion zu bringen. Dies liegt vor allem daran, dass es eine große Wissenslücke gibt, da Datenwissenschaftler den Modellaufbau gut verstehen, aber es ihm fehlt Produktion Fähigkeiten. Der einfache Grund ist, dass diese Fähigkeiten nicht auf Youtube-Videos vermittelt werden und kaum von Data-Science-Kursen oder der Kaggle-Lernmethode berührt werden.

1639154423375.gif
Wissen fließt

Ziel dieses Newsletters ist es, meine Erkenntnisse aus diesen verschiedenen Einsätzen, die ich gemacht habe, zu teilen.

Technische Regel für die Bereitstellung: Geringere Abhängigkeit ∝ Schnellere Bereitstellung

Lassen Sie uns die Bereitstellung von Data-Science-Modellen anhand eines echten Problems verstehen. Ein Freund von mir rief mich irgendwann zurück und bat mich, ihm bei seinem Anwendungsfall zu helfen und das Modell in der Produktion einzusetzen.

1639285839218.gif
Anruf klingelt

Wir diskutierten das Problem ein oder zwei Stunden lang, um die Einschränkungen zu verstehen.

Zusammenfassung der besprochenen Einschränkungen:

  • Datenquelle ist Elastic Search (ES wird sehr häufig mit neuen Einträgen aktualisiert)

  • Echtzeit- oder Fast-Echtzeit-Inferenz (mit einer akzeptablen Verzögerung von bis zu 10 Minuten)

  • Niedriges Budget

  • Minimale Ausfallrate mit Fallbacks

  • Warnsystem im Falle eines aufgetretenen Fehlers

Nach dem Verständnis der Einschränkungen und des Problems, das er zu lösen versuchte. Ich habe eine Architektur vorgeschlagen (siehe Diagramm unten), die nahezu in Echtzeit arbeitet (Batch-Inferenz alle 5 Minuten), auf das letzte Modellupdate zurückgreift (das Backend ruft frühere Update-Ergebnisse von s3 ab) und eine einfache Webhook-Warnungsroute für lockere Webhooks geteilt hat.

1639311136382.jpeg
Batch-Modelldesign

Nach etwa zwei Wochen rief er an und teilte mit, dass die Lösung gut funktioniere 🥳 (Emotion super glücklich). Das oben Genannte hat sich bewährt: Low on Budget and Low on Maintenance – Model Productionisation Design.

1639311751981.gif

Lassen Sie uns argumentieren!

Das Architekturdesign, wie das Obige die Einschränkungen löst

Alternative Sagemaker-Batch-Inferenz: Dies hätte eine gute Option sein können, aber wir haben uns nicht dafür entschieden, weil er bereits eine EC2-Instance hatte, die rund um die Uhr lief und nicht ausgelastet war. Abgesehen von der oben genannten 5-Minuten-Inferenz (Fast-Echtzeit-Inferenzarchitektur) ist es sicherer, die Sagemaker-Batch-Inferenz nicht zu verwenden, während die Echtzeit-Inferenzoption teurer ist.

Die Vertrautheit der Entwickler ist ein weiterer Faktor, der beim Erstellen eines Architekturdesigns sehr wichtig ist. EC2 war schon immer ein Spielplatz für ihn.

Ein weiterer Lernpunkt: Wenn Sie ein Modell mit einer Aktualisierungshäufigkeit von 1 Tag ausführen und die Aufgabenberechnung auf einem neuen EC2-Computer ausführen möchten, kann bei jedem Lauf die obige Architektur weiterhin verwendet werden. Man kann diesem Blog folgen, um zu lernen „Wie stoppe und starte ich Amazon EC2-Instances in regelmäßigen Abständen mit Lambda?„Dies wird dazu beitragen, Kosten für die EC2-Maschine zu sparen, indem sie nur bis zum Rechenfenster ausgeführt wird.

Warum Airflow?

Apache Airflow ist ein Open-Source-Scheduler zur Verwaltung Ihrer regulären Jobs. Es ist ein hervorragendes Tool zum Organisieren, Ausführen und Überwachen Ihrer Arbeitsabläufe, damit sie reibungslos funktionieren.

Der Luftstrom würde den Datenabruf von ES und der Vorhersageaufgabe in einem definierten Intervall für den obigen Fall auslösen – alle 5 Minuten. Um einen Scheduler-Ausdruck zu schreiben, kann man verwenden Crontab.Guru (Dieses Werkzeug zum Schreiben von Ausdrücken ist ausgezeichnet, ich verwende es oft beim Schreiben einer Airflow-Aufgabe).

Weitere Argumentationshinweise zur Architektur:

  • Das Modell wird aus S3 in den Arbeitsspeicher geladen, um Schlussfolgerungen zu ziehen, sodass der lokale Plattenspeicher nicht von Modellgewichten verwendet wird. Hinweis: Ich habe viele Data Scientists gesehen, die die Modelldatei auf dem Maschinenspeicher aufbewahren. Und wenn etwas mit EC2 schief geht, werden alle Dateien gelöscht und damit all ihre Bemühungen. Bewahren Sie das Modell immer als Backup auf S3 auf.

  • Die Ausgabe wird auf S3 überschrieben und das Backend wählt Modellergebnisse von S3 aus; S3-Speicher ist bei AWS zuverlässig und am günstigsten.

  • Für Benachrichtigungen ist Slack die beste Option, da es während der Bürozeiten immer eingeschaltet ist und wenn Sie nicht verfügbar sind, können Ihre Teammitglieder Benachrichtigungen einsehen, man kann sogar Luftstromausfälle hinzufügen und E-Mails erneut versuchen, aber ich bevorzuge Benachrichtigungen mit Webhooks in den Bürokommunikationstools : locker/Herde/Teams.

1639378804688.jpeg
Einfach ist nicht immer die Lösung

Ich weiß, dass es bessere Optionen für Airflow-Komponenten wie Dagster oder Perfect gibt. Ähnlichkeit für andere Komponenten in der Architektur gibt es neue/vergleichende Alternativen. Aber vergessen Sie nie den Faktor der Dev-Vertrautheit, wenn Sie Tools für Ihre Modellpipelines auswählen. Je älter das Tool, desto besser der Support und man kann es nicht wirklich kleinreden.

„WAS WENN WIR EIN ECHTZEITMODELL IN DER PRODUKTION EINSETZEN WOLLEN?“ – fragte mein Freund, sogar die Leser hier müssen das gleiche denken.

1639461867756.gif
Ich habe eine Frage?

Wir haben die Einschränkungen besprochen, die unten zusammengefasst sind:

  • Ein Pool von Items wird von ES abgerufen
  • Ausgabe des Echtzeitmodells mit Timeout von 100 ms erforderlich
  • Bei Zeitüberschreitung fällt das Modell auf die zwischengespeicherte Version zurück
  • Protokollierung ist erforderlich

Unten ist das Design der Produktionsarchitektur des Echtzeitmodells 👇

1639469513567.jpeg
Modelldesign in Echtzeit

Argumentation und andere Imbissbuden zur Echtzeitarchitektur

  • Ich habe das dockerisierte Modell gezeigt, das auf EC2 bereitgestellt wird. Es kann auch auf ECS/SageMaker bereitgestellt werden, würde diese Wahl Ihnen überlassen.
  • Für das Caching – persönliche Vorlieben Redis.
  • Kibana dient zum Protokollieren von Antwort- und Infoprotokollen innerhalb des Modelldienstes
  • Zum Modelldienen kann man verwenden MLFlow, BentoML, FastAPI, Kortexusw. Ich bevorzuge BentoML, da Sie Ihr ML-Modell in weniger als 10 Minuten über einen HTTP-API-Endpunkt bereitstellen und ein Docker-Image erstellen können, das in der Produktion bereitgestellt werden kann.

Fazit

Ich hoffe, dass das Design der Data-Science-Modellproduktionsarchitektur keine Frage mehr außerhalb des Lehrplans ist. Es steckt so viel mehr dahinter, als wir behandeln können, aber verbringen Sie einige Zeit damit, sich den Kopf darüber zu zerbrechen …!

Auch veröffentlicht hier.

Ich hoffe, Sie haben aus diesem Beitrag etwas Neues gelernt. Wenn es dir gefallen hat, drücke 👍 oder ❤️ und teile es mit anderen. Seien Sie gespannt auf den nächsten!

Mein Newsletter auf LinkedIn wird jetzt von mehr als 4500+ Abonnenten gelesen. Wenn Sie ein KI- oder Datenprodukt oder -dienst entwickeln, sind Sie eingeladen, Sponsor einer der zukünftigen Newsletter-Ausgaben zu werden. Wenden Sie sich gerne an [email protected] für weitere Details zu Patenschaften.

Ich bin nominiert für die HackerNoon 2022 Noonies, stimme für mich ab: HackerNoon Mitwirkender des Jahres – Daten || Dämon der Datenwissenschaft

Buchempfehlungen zu Data Science:

[1] Das Buch des Warum

[2] Nackte Statistiken

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *