Pipelines de science des données et blobs de modèles monolithiques

Normalement, un sujet important dans DevOps est de savoir comment nous nous occupons de la création et de la livraison automatisées des artefacts logiciels.

Avec l'essor de la science des données, il existe un nouveau type d'artefact: des taches binaires monolithiques représentant un réseau neuronal formé par exemple ou d'autres modèles d'apprentissage automatique. Un tel blob peut avoir une taille de plusieurs Go et sa création n'est pas encore standardisée AFAIK ce qui ramène les organisations à l'ère pré-CI. Néanmoins, ils ont leur version et les collections associées de données de formation (corpus) qui ont également tendance à croître rapidement.

Quelles sont les meilleures pratiques pour relever ce nouveau défi en utilisant les méthodes DevOps - si possible?

— Peter Muryshkin
source

Je ne vois pas la différence entre un gros blob et un uberjar dans le contexte java. Les mêmes pratiques s'appliquent, la taille d'un artefact a peu de raisons d'entrer en jeu.

— Tensibai

Salut - Je pensais qu'avec des uber-pots à partir de 2 Go, vous leur raconteriez l'histoire de l'architecture des microservices, ou? ... Mais les blobs de modèle commencent juste là, 8 Go ne seront bientôt pas rares.

— Peter Muryshkin

Je veux juste dire qu'un instantané dB de 350Go n'est pas un atout différent d'un pot de 5 Mo, il doit être stocké de toute façon et le référentiel d'artefacts peut gérer cela

— Tensibai

Je suis d'accord - ce n'est pas parce que le programme résultant est volumineux qu'il n'est pas encore compilé, versionné et stocké comme tout le reste (quoique avec peut-être quelques défis de stockage), donc je ne vois pas comment cela "ramène les organisations à la âge pré-CI "Si une organisation pense cela, je ne suis pas sûr qu'elle comprenne réellement DevOps / CI.

— James Shewey

Réponses:

Personnellement, je ne vois aucune raison pour laquelle un référentiel d'artefacts - l'outil recommandé de DevOps de gestion des artefacts - ne serait pas applicable aux réseaux neuronaux formés ou à d'autres artefacts.

La taille de l'artefact peut avoir une limite supérieure pour un référentiel d'artefact particulier, mais dans ce cas, il s'agirait d'une limitation technique ou politique, et non fondamentale / principale.

Quant à l'application des méthodologies DevOps pour le processus produisant ces artefacts, je pense que la plupart sinon la totalité d'entre elles peuvent être appliquées aussi bien, tant que les artefacts:

sont produits à partir d'une sorte de spécification qui prend en charge le changement de version (équivalent au code source du logiciel)
sont construits via un processus répétable et automatisable
sont validés à l'aide d'une sorte de vérification répétable et automatisable (similaire à l'assurance qualité), éventuellement à l'aide de certaines données de support (données de formation dans ce cas, équivalentes à des instantanés de base de données, par exemple)

Remarque: la livraison de code logiciel monolithique est toujours un gros problème et est parfaitement maintenable avec les méthodologies DevOps (avec un peu de soin), tout ne peut pas être divisé en microservices. La taille n'a pas assez d'importance pour que DevOps ne soit pas applicable.

— Dan Cornilescu
source

Réponse parfaite. Je stocke tous mes modèles lourds git lfset les tire quand c'est nécessaire [paradigme sans serveur] :)

— Dawny33

@ Dawny33 mais envisageriez-vous maintenant de vous éloigner de git lfs?

— Peter Muryshkin

@ J.Doe Jusqu'ici tout va bien avec lfs. Serait probablement déplacer si je trouve une très bonne meilleure alternative.

— Dawny33

alors je ne comprends pas pourquoi vous dites que la réponse est "parfaite" alors qu'elle suggère d'utiliser un référentiel d'artefacts?! @ Dawny33

— Peter Muryshkin

Le DVC peut être considéré comme une meilleure alternative àgit-lfs

— Shcheklein

Je recommanderais de jeter un œil à DVC - un système de contrôle de version open source pour les projets de science des données.

L'une des choses de base qu'il gère parfaitement est la gestion des fichiers de données (avec le code) - entrées, sorties (modèles), résultats intermédiaires. Sémantiquement, il est similaire à git-lfsmais contrairement à git-lfsil est capable de gérer des fichiers comme 100 Go et ce qui est plus important, il ne repose pas sur un stockage / format propriétaire. Il est complètement open-source et est compatible avec tout stockage réseau en tant que serveur pour conserver les fichiers de données - S3, stockage cloud GCP, SSH, FTP, etc.

— Shcheklein
source