Pipelines de ciência de dados e blobs de modelo monolítico

Normalmente, um tópico importante no DevOps é como cuidamos da criação e entrega automatizadas de artefatos de software.

Com o surgimento da ciência de dados, existe um novo tipo de artefato - blobs binários monolíticos que representam uma rede neural treinada, por exemplo, ou outros modelos de aprendizado de máquina. Esse blob pode ter um tamanho de muitos GB e sua criação ainda não é um AFAIK padronizado, que traz as organizações de volta à era anterior ao IC. No entanto, eles têm sua versão e coleções associadas de dados de treinamento (corpora), que tendem a crescer rapidamente também.

Quais são as práticas recomendadas para enfrentar esse novo desafio usando os métodos DevOps - se possível?

— Peter Muryshkin
fonte

Não vejo a diferença entre um blob grande e um uberjar no contexto java. Mesmas práticas se aplicam, o tamanho de um artefato tem poucas razões para entrar em jogo.

— Tensibai 13/09/17

Oi - Pensei que, com os uber-jars de 2 GB para cima, você contaria a história da arquitetura de microsserviços, ou? ... Mas os blobs de modelo apenas começam por aí, 8 GB logo não serão raros.

— Peter Muryshkin

Eu só quero dizer um instantâneo dB de 350Go não é um activo diferente de um frasco 5Mo, tem que ser armazenado em algum lugar de qualquer maneira e repositório de artefatos pode lidar com isso

— Tensibai

Eu concordo - só porque o programa resultante é grande, não significa que ainda não foi compilado, versionado e armazenado como todo o resto (embora talvez com alguns desafios de armazenamento), por isso não vejo como isso "traz as organizações de volta ao idade pré-IC "Se uma organização pensa isso, não tenho certeza de que eles realmente entendem o DevOps / CI.

— James Shewey 13/09/17

Respostas:

Pessoalmente, não vejo nenhuma razão pela qual um Repositório de Artefatos - a ferramenta recomendada do DevOps para gerenciar artefatos - não seja aplicável a redes neurais treinadas ou outros artefatos.

O tamanho do artefato pode ter algum limite superior para um repositório de artefatos específico, mas, nesse caso, seria uma limitação técnica ou de política, não fundamental / principial.

Quanto à aplicação de metodologias DevOps para o processo de produção desses artefatos, acho que a maioria, se não todas, pode ser aplicada igualmente bem, desde que os artefatos:

são produzidos a partir de algum tipo de especificação que suporta controle de versão de mudança (equivalente ao código-fonte do software)
são construídas através de um processo repetível e automatizável
são validados usando algum tipo de verificação repetível e automatizável (semelhante ao controle de qualidade), eventualmente usando alguns dados de suporte (dados de treinamento nesse caso, equivalentes aos instantâneos do banco de dados, por exemplo)

Nota lateral: a entrega de código de software monolítico ainda é um grande negócio e é perfeitamente sustentável com as metodologias DevOps (com um pouco de cuidado), nem tudo pode ser dividido em microsserviços. Tamanho não importa o suficiente para tornar o DevOps não aplicável.

— Dan Cornilescu
fonte

Resposta perfeita. Eu armazenar todos os meus pesados modelos git lfse trazê-los quando necessário [serverless paradigma] :)

— Dawny33

@ Dawny33, mas agora você consideraria se afastar do git lfs?

— Peter Muryshkin

@ J.Doe Até agora tudo bem com lfs. Provavelmente seria movido se eu encontrar uma alternativa melhor realmente boa.

— Dawny33

então não entendo por que você diz que a resposta é "perfeita", enquanto sugere o uso de um repositório de artefatos ?! @ Dawny33

— Peter Muryshkin

DVC pode ser considerado como uma alternativa melhor paragit-lfs

— Shcheklein

Eu recomendaria dar uma olhada no DVC - um sistema de controle de versão de código aberto para projetos de ciência de dados.

Uma das coisas básicas com as quais ele lida perfeitamente é o gerenciamento de arquivos de dados (junto com o código) - entradas, saídas (modelos), resultados intermediários. Semanticamente, é semelhante, git-lfsmas ao contrário git-lfs, é capaz de gerenciar arquivos como 100 GB e, o mais importante, não depende de armazenamento / formato proprietário. É completamente de código aberto e é compatível com qualquer armazenamento de rede como servidor para manter arquivos de dados - S3, armazenamento em nuvem GCP, SSH, FTP, etc.

— Shcheklein
fonte