Canalizaciones de Data Science y blobs modelo monolítico

Normalmente, un tema importante en DevOps es cómo nos ocupamos de la creación y entrega automatizada de artefactos de software.

Con el auge de la ciencia de datos, hay un nuevo tipo de artefacto: gotas binarias monolíticas que representan una red neuronal entrenada, por ejemplo, u otros modelos de aprendizaje automático. Tal blob puede tener un tamaño de muchos GB y su creación aún no está estandarizada AFAIK, lo que hace que las organizaciones vuelvan a la era anterior a CI. Sin embargo, tienen su versión y colecciones asociadas de datos de capacitación (corpus) que también tienden a crecer rápidamente.

¿Cuáles son las mejores prácticas para abordar este nuevo desafío utilizando los métodos DevOps, si es posible?

— Peter Muryshkin
fuente

No veo la diferencia entre un blob grande y un uberjar en contexto java. Se aplican las mismas prácticas, el tamaño de un artefacto tiene pocas razones para entrar en juego.

— Tensibai

Hola, pensé que con los tarros uber de 2 gb en adelante les contarías la historia de la arquitectura de microservicios, o ... Pero los blobs de modelo solo comienzan allí, 8 gb pronto no será raro.

— Peter Muryshkin

Sólo quiero decir una instantánea dB de 350Go no es un activo diferente a un frasco 5Mo, tiene que ser almacenado en algún lugar de todos modos y repositorio de artefacto que puede manejar

— Tensibai

Estoy de acuerdo: el hecho de que el programa resultante sea grande no significa que todavía no se haya compilado, versionado y almacenado como todo lo demás (aunque quizás con algunos desafíos de almacenamiento), así que no veo cómo esto "hace que las organizaciones vuelvan a pre-CI age "Si una organización piensa eso, no estoy seguro de que realmente entienda DevOps / CI.

— James Shewey

Respuestas:

Personalmente, no veo ninguna razón por la cual un Repositorio de artefactos , la herramienta recomendada de DevOps para administrar artefactos, no sea aplicable a redes neuronales entrenadas u otros artefactos.

El tamaño del artefacto podría tener algún límite superior para un repositorio de artefactos en particular, pero en tal caso sería una limitación técnica o de política, no fundamental / de principios.

En cuanto a la aplicación de metodologías DevOps para el proceso que produce estos artefactos, creo que la mayoría, si no todos, pueden aplicarse igualmente bien, siempre que los artefactos:

se producen a partir de algún tipo de especificación que admite el cambio de versiones (equivalente al código fuente del software)
se construyen a través de un proceso repetible y automatizable
se validan utilizando algún tipo de verificación repetible y automatizable (similar a QA), eventualmente utilizando algunos datos de soporte (datos de capacitación en este caso, equivalentes a instantáneas de DB, por ejemplo)

Nota al margen: la entrega de código de software monolítico sigue siendo un gran problema y se puede mantener perfectamente con las metodologías DevOps (con un poco de cuidado), no todo se puede dividir en microservicios. El tamaño no importa lo suficiente como para que DevOps no sea aplicable.

— Dan Cornilescu
fuente

Respuesta perfecta. Guardo todos mis modelos pesados git lfsy los

— tiro

@ Dawny33, pero ¿considerarías ahora alejarte de git lfs?

— Peter Muryshkin

@ J.Doe Hasta ahora todo bien con lfs. Probablemente me mudaría si encuentro una alternativa realmente buena y mejor.

— Dawny33

entonces no entiendo por qué dices que la respuesta es "perfecta" mientras sugiere usar un repositorio de artefactos. @ Dawny33

— Peter Muryshkin

DVC puede considerarse como una mejor alternativa agit-lfs

— Shcheklein

Recomendaría echar un vistazo a DVC , un sistema de control de versiones de código abierto para proyectos de ciencia de datos.

Una de las cosas básicas que maneja perfectamente es administrar archivos de datos (junto con el código): entradas, salidas (modelos), resultados intermedios. Semánticamente es similar git-lfspero, a diferencia de git-lfsesto, es capaz de administrar archivos como 100 GB y, lo que es más importante, no depende del almacenamiento / formato propietario. Es completamente de código abierto y es compatible con cualquier almacenamiento de red como servidor para guardar archivos de datos: S3, almacenamiento en la nube GCP, SSH, FTP, etc.

— Shcheklein
fuente