Pipeline di Data Science e BLOB di modelli monolitici

Normalmente, un argomento importante in DevOps è come ci occupiamo della creazione e consegna automatizzata di artefatti software.

Con l'ascesa della scienza dei dati esiste un nuovo tipo di artefatto: blob binari monolitici che rappresentano ad esempio una rete neurale addestrata o altri modelli di apprendimento automatico. Tale BLOB può avere dimensioni di molti GB e la sua creazione non è ancora standardizzata AFAIK che riporta le organizzazioni all'era precedente alla CI. Tuttavia, hanno la loro versione e raccolte associate di dati di addestramento (corpora) che tendono a crescere rapidamente.

Quali sono le migliori pratiche per affrontare questa nuova sfida usando i metodi DevOps - se possibile?

— Peter Muryshkin
fonte

Non vedo la differenza tra un grande BLOB e un Uberjar nel contesto Java. Si applicano le stesse pratiche, la dimensione di un manufatto ha poche ragioni per entrare in gioco.

— Tensibai,

Ciao - Ho pensato che con i vasetti di Uber da 2 GB in poi avresti raccontato loro la storia dell'architettura dei microservizi, o ... Ma i BLOB di modelli appena iniziati lì, 8 GB non saranno presto rari.

— Peter Muryshkin,

Intendo solo un'istantanea in dB di 350Go non è una risorsa diversa rispetto a un vaso da 5Mo, deve essere comunque archiviata da qualche parte e il repository di artefatti può gestirlo

— Tensibai

Sono d'accordo - solo perché il programma risultante è grande non significa che non sia ancora compilato, aggiornato e archiviato come tutto il resto (anche se forse con alcune sfide di archiviazione), quindi non riesco a vedere come questo "riporta le organizzazioni al età pre-CI "Se un'organizzazione lo pensa, non sono sicuro che capiscano davvero DevOps / CI.

— James Shewey,

Risposte:

Personalmente non vedo alcun motivo per cui un repertorio di artefatti - lo strumento DevOps raccomandato per la gestione degli artefatti - non sia applicabile alle reti neurali addestrate o ad altri artefatti.

La dimensione del manufatto potrebbe avere un limite superiore per un particolare repository di manufatti, ma in tal caso sarebbe una limitazione tecnica o politica, non fondamentale / principale.

Per quanto riguarda l'applicazione delle metodologie DevOps per il processo di produzione di questi artefatti, penso che la maggior parte se non tutti possono essere applicati ugualmente bene, purché gli artefatti:

sono prodotti da una sorta di specifica che supporta il cambio di versione (equivalente al codice sorgente del software)
sono costruiti tramite un processo ripetibile e automatizzabile
vengono convalidati utilizzando una sorta di verifica ripetibile e automatizzabile (simile al QA), eventualmente utilizzando alcuni dati di supporto (dati di addestramento in questo caso, equivalenti ad istantanee di DB, ad esempio)

Nota a margine: la consegna del codice del software monolitico è ancora un grosso problema ed è perfettamente gestibile con le metodologie DevOps (con un po 'di attenzione), non tutto può essere suddiviso in microservizi. Le dimensioni non contano abbastanza da rendere DevOps non applicabile.

— Dan Cornilescu
fonte

Risposta perfetta git lfs

— Conservo

@ Dawny33 ma ora prenderesti in considerazione l'idea di allontanarti da git lfs?

— Peter Muryshkin,

@ J.Doe Finora tutto bene con lfs. Probabilmente si sposterebbe se trovassi un'alternativa davvero migliore.

— Dawny33

allora non capisco perché dici che la risposta è "perfetta" mentre suggerisce di usare un repository di artefatti ?! @ Dawny33

— Peter Muryshkin,

Il DVC può essere considerato una migliore alternativa agit-lfs

— Shcheklein,

Consiglierei di dare un'occhiata a DVC , un sistema di controllo della versione open source per progetti di data science.

Una delle cose di base che gestisce perfettamente è la gestione dei file di dati (insieme al codice): input, output (modelli), risultati intermedi. Semanticamente è simile git-lfsma a differenza di git-lfsè in grado di gestire file come 100 GB e, cosa più importante, non si basa su archiviazione / formato proprietari. È completamente open-source ed è compatibile con qualsiasi archivio di rete come server per conservare i file di dati - S3, archiviazione cloud GCP, SSH, FTP, ecc.

— Shcheklein
fonte