Data Science-Pipelines und monolitische Modellblobs

8

Normalerweise ist ein wichtiges Thema in DevOps, wie wir uns um die automatisierte Erstellung und Bereitstellung von Software-Artefakten kümmern.

Mit dem Aufstieg der Datenwissenschaft gibt es eine neue Art von Artefakten - monolitische binäre Blobs, die beispielsweise ein trainiertes neuronales Netz oder andere Modelle des maschinellen Lernens darstellen. Ein solcher Blob kann eine Größe von vielen GB haben und seine Erstellung ist noch nicht standardisiert. AFAIK bringt Organisationen zurück in das Zeitalter vor CI. Trotzdem haben sie ihre Version und die dazugehörigen Sammlungen von Trainingsdaten (Korpora), die ebenfalls schnell wachsen.

Was sind Best Practices, um diese neue Herausforderung mithilfe von DevOps-Methoden anzugehen - wenn überhaupt möglich?

continuous-integration continuous-delivery automation methodology Peter Muryshkin
quelle
3
Ich sehe keinen Unterschied zwischen einem großen Blob und einem Uberjar im Java-Kontext. Gleiche Praktiken gelten, die Größe eines Artefakts hat nur wenige Gründe, ins Spiel zu kommen.
Tensibai
Hallo - ich dachte, mit Uber-Gläsern ab 2 GB würden Sie ihnen die Geschichte der Microservice-Architektur erzählen, oder? .. Aber Modell-Blobs fangen einfach dort an, 8 GB werden bald nicht selten sein.
Peter Muryshkin
1
Ich meine nur, ein dB-Schnappschuss von 350Go ist kein anderes Gut als ein 5Mo-Glas, er muss sowieso irgendwo gespeichert werden und das Artefakt-Repository kann damit umgehen
Tensibai,
Ich stimme zu - nur weil das resultierende Programm groß ist, heißt das nicht, dass es noch nicht wie alles andere kompiliert, versioniert und gespeichert ist (wenn auch mit vielleicht ein paar Speicherproblemen), also sehe ich nicht, wie dies "Organisationen zurück zum Programm bringt" Pre-CI-Alter "Wenn eine Organisation das glaubt, bin ich mir nicht sicher, ob sie DevOps / CI tatsächlich versteht.
James Shewey

Antworten:

8

Persönlich sehe ich keinen Grund, aus dem ein Artefakt-Repository - das empfohlene DevOps-Tool zum Verwalten von Artefakten - nicht auf trainierte neuronale Netze oder andere Artefakte anwendbar wäre.

Die Artefaktgröße kann eine Obergrenze für ein bestimmtes Artefakt-Repository haben, in diesem Fall handelt es sich jedoch um eine technische oder Richtlinienbeschränkung, nicht um eine grundlegende / prinzipielle.

Was die Anwendung von DevOps-Methoden für den Prozess zur Herstellung dieser Artefakte betrifft, denke ich, dass die meisten, wenn nicht alle gleich gut angewendet werden können, solange die Artefakte:

  • werden aus einer Spezifikation hergestellt, die die Versionierung von Änderungen unterstützt (entspricht dem Software-Quellcode).
  • werden über einen wiederholbaren und automatisierbaren Prozess erstellt
  • werden mithilfe einer wiederholbaren und automatisierbaren Überprüfung (ähnlich wie bei der Qualitätssicherung) validiert, wobei schließlich einige unterstützende Daten verwendet werden (in diesem Fall Trainingsdaten, die beispielsweise DB-Snapshots entsprechen).

Randnotiz: Die Bereitstellung von monolithischem Software-Code ist immer noch eine große Sache und kann mit DevOps-Methoden (mit ein wenig Sorgfalt) perfekt gewartet werden. Nicht alles kann in Microservices aufgeteilt werden. Die Größe spielt keine Rolle, sodass DevOps nicht anwendbar ist.

Dan Cornilescu
quelle
Perfekte Antwort. Ich speichere alle meine schweren Modelle in git lfsund ziehe sie bei Bedarf [serverloses Paradigma] :)
Dawny33
@ Dawny33 aber würdest du jetzt darüber nachdenken, dich von git lfs zu entfernen?
Peter Muryshkin
@ J.Doe So weit so gut mit lfs. Würde mich wahrscheinlich bewegen, wenn ich eine wirklich gute bessere Alternative finde.
Dawny33
dann verstehe ich nicht, warum Sie sagen, dass die Antwort "perfekt" ist, während sie die Verwendung eines Artefakt-Repositorys vorschlägt?! @ Dawny33
Peter Muryshkin
2
DVC kann als eine bessere Alternative zugit-lfs
Shcheklein
4

Ich würde empfehlen, einen Blick auf DVC zu werfen - ein Open-Source-Versionskontrollsystem für datenwissenschaftliche Projekte.

Eines der grundlegenden Dinge, die perfekt verarbeitet werden, ist die Verwaltung von Datendateien (zusammen mit Code) - Eingaben, Ausgaben (Modelle), Zwischenergebnisse. Semantisch ist es ähnlich, git-lfsaber im Gegensatz git-lfsdazu ist es in der Lage, Dateien wie 100 GB zu verwalten, und was noch wichtiger ist, es basiert nicht auf proprietärem Speicher / Format. Es ist vollständig Open Source und mit jedem Netzwerkspeicher als Server kompatibel, um Datendateien zu speichern - S3, GCP-Cloud-Speicher, SSH, FTP usw.

Shcheklein
quelle