full stack on prem cv mlops

Sistema MLOps local full-stack para visão computacional

▶️ 1 configuração, 1 comando do Jupyter Notebook para atender milhões de usuários ◀️

Índice

• Visão geral
• Vídeos de demonstração
• Ferramentas/Tecnologias
• Práticas adotadas
• Portas de serviço
• Como usar
  • Configurar
  • Uso mínimo
  • Personalização
• Como tudo funciona junto
• Do local para a nuvem
• Esquemas de banco de dados
• Solução de problemas

Visão geral

Bem-vindo ao nosso abrangente ecossistema MLOps local projetado especificamente para tarefas de visão computacional, com foco principal na classificação de imagens. Este repositório fornece tudo que você precisa, desde um espaço de trabalho de desenvolvimento no Jupyter Lab/Notebook até serviços de nível de produção. A melhor parte? Leva apenas "1 configuração e 1 comando" para executar todo o sistema, desde a construção do modelo até a implantação! Integramos diversas práticas recomendadas para garantir escalabilidade e confiabilidade, mantendo ao mesmo tempo a flexibilidade. Embora nosso caso de uso principal gire em torno da classificação de imagens, nossa estrutura de projeto pode se adaptar facilmente a uma ampla variedade de desenvolvimentos de ML/DL, até mesmo na transição do local para a nuvem!

Outro objetivo é mostrar como integrar todas essas ferramentas e fazê-las funcionar juntas em um sistema completo. Se você estiver interessado em componentes ou ferramentas específicas, sinta-se à vontade para escolher o que atende às necessidades do seu projeto.

Todo o sistema é conteinerizado em um único arquivo Docker Compose. Para configurá-lo, tudo que você precisa fazer é executar docker-compose up ! Este é um sistema totalmente local, o que significa que não há necessidade de uma conta na nuvem e não custará um centavo para usar o sistema inteiro!

É altamente recomendável assistir aos vídeos de demonstração na seção Vídeos de demonstração para obter uma visão geral abrangente e entender como aplicar este sistema aos seus projetos. Esses vídeos contêm detalhes importantes que podem ser muito longos e não claros o suficiente para serem abordados aqui.

Vídeos de demonstração

Demonstração: https://youtu.be/NKil4uzmmQc
Passo a passo técnico detalhado: https://youtu.be/l1S5tHuGBA8

Recursos no vídeo:

• Arquivos de modelo (modelos baseados em ResNet50): link
• Slide: ligação

Ferramentas/Tecnologias

Para usar este repositório, você só precisa do Docker. Para referência, usamos Docker versão 24.0.6, build ed223bc e Docker Compose versão v2.21.0-desktop.1 no Mac M1.

• Plataforma: Docker
• Espaço de trabalho: Laboratório Jupyter
• Estrutura de aprendizado profundo: TensorFlow
• Versionamento de dados: DvC
• Validação de dados: DeepChecks
• Plataforma de aprendizado de máquina/rastreamento de experimentos: MLflow
• Orquestrador de pipeline: Prefeito
• Implantação de serviço de aprendizado de máquina: FastAPI, Uvicorn, Gunicorn, Nginx (+ HTML, CSS, JS para uma UI simples)
• Bancos de dados: PostgreSQL (SQL), Prometheus (série temporal)
• Monitoramento de modelo de aprendizado de máquina e detecção de desvios: evidentemente
• Monitoramento geral do sistema e painel: Grafana

Práticas adotadas

Implementamos várias práticas recomendadas neste projeto:

• Carregador/pipeline de dados eficiente usando tf.data para TensorFlow
• Aumento de imagem com imgaug lib para maior flexibilidade nas opções de aumento do que as funções principais do TensorFlow
• Usando os.env para configurações importantes ou de nível de serviço
• Registrando com o módulo logging em vez de print
• Armazenamento de banco de dados para resultados de resposta de serviço
• Configuração dinâmica através de .env para variáveis ​​em docker-compose.yml
• Usando default.conf.template para Nginx para aplicar variáveis ​​de ambiente com elegância na configuração do Nginx (novo recurso no Nginx 1.19)
• Configuração do Nginx para exibição de log do terminal
• Configurando um trabalhador Prefect para dar suporte ao trabalho em um cluster

Portas de serviço

A maioria das portas pode ser personalizada no arquivo .env na raiz deste repositório. Aqui estão os padrões:

• JupyterLab: 8888 (número de telefone: 123456789 )
• Fluxo de ML: 5050
• Prefeito: 4200
• PostgreSQL: 5432
• pgAdmin: 16543 (usuário: [email protected] , pw: SuperSecurePwdHere )
• Serviço de aprendizagem profunda: 4242
• Interface Web UI para serviço Deep Learning: 4243
• Nginx: 80
• Evidentemente: 8000
• Prometeu: 9090
• Grafana: 3000 (usuário: admin , pw: admin )

Como usar

Você deve considerar comentar essas linhas platform: linux/arm64 em docker-compose.yml se não estiver usando um computador baseado em ARM (estamos usando Mac M1 para desenvolvimento). Caso contrário, este sistema não funcionará.

Configurar

1. Clone este repositório. Existem 2 submódulos neste repositório, então considere usar o sinalizador --recurse-submodules em seu comando: git clone --recurse-submodules https://github.com/jomariya23156/full-stack-on-prem-cv-mlops
2. [Para usuários com CUDA] Se você tiver GPU(s) compatíveis com CUDA, você pode descomentar a seção deploy no serviço jupyter em docker-compose.yml e alterar a imagem base em services/jupyter/Dockerfile de ubuntu:18.04 para nvidia/cuda:11.4.3-cudnn8-devel-ubuntu20.04 (o texto está lá no arquivo, basta comentar e descomentar) para aproveitar sua(s) GPU(s). Você também pode precisar instalar nvidia-container-toolkit na máquina host para que funcione. Para usuários de Windows/WSL2, achamos este artigo muito útil.
3. Na raiz do diretório repo, execute docker-compose up ou docker-compose up -d para desconectar o terminal.
4. Na primeira vez pode demorar um pouco devido ao tamanho das imagens, principalmente no Jupyter, pois contém muitos pacotes e bibliotecas. Geralmente, pode levar de 5 a 20 minutos.
5. Vá para o submódulo DvC em datasets/animals10-dvc e siga as etapas na seção Como usar .

Uso mínimo

1. Abra o laboratório Jupyter na porta 8888 http://localhost:8888/lab
2. Vá para o diretório do espaço de trabalho cd ~/workspace/
3. Ative o ambiente conda (o nome é configurável em docker-compose.yml ) conda activate computer-viz-dl
4. Execute python run_flow.py --config configs/full_flow_config.yaml
5. Relaxe e observe seu novo classificador ser construído, treinado, avaliado, implantado (em escala) e monitorado em um sistema totalmente operacional!

Personalização

• Há muitas coisas trabalhando juntas e é difícil falar em detalhes. Não há melhor maneira do que sujar as mãos, também conhecido como ler códigos, tentar entender e personalizar você mesmo!
• De qualquer forma, existem algumas diretrizes que você pode seguir para fazer com que os componentes funcionem perfeitamente juntos como deveriam:
  • Suas tarefas devem ser criadas dentro do diretório tasks
  • Todas as suas tarefas devem ser chamadas a partir dos fluxos criados dentro do diretório flows
  • Seus fluxos devem ser chamados com run_flow.py na raiz do repositório.
  • Para ser chamado desta forma, você deve implementar a função start(config) em seu arquivo de fluxo. Esta função aceita a configuração como um ditado Python e basicamente chama o fluxo específico nesse arquivo.
  • Os conjuntos de dados devem estar dentro do diretório datasets e todos devem ter a mesma estrutura de diretórios que está dentro deste repositório.
  • central_storage em ~/ariya/ deve conter pelo menos 2 subdiretórios chamados models e ref_data . Este central_storage serve ao propósito de armazenamento de objetos de armazenar todos os arquivos preparados para serem usados ​​em ambientes de desenvolvimento e implantação. (Esta é uma das coisas que você pode considerar mudar para um serviço de armazenamento em nuvem caso queira implantar na nuvem e torná-lo mais escalonável)

Convenções IMPORTANTES para ter MUITO CUIDADO caso queira alterar (porque essas coisas estão amarradas e usadas em diferentes partes do sistema):

• caminho central_storage -> Dentro deve haver subdiretórios models/ ref_data/
• Nomenclatura de arquivo em central_storage, por exemplo, <model_name>.yaml , <model_name>_uae , <model_name>_bbsd , <model_name>_ref_data.parquet
• Todos os esquemas de banco de dados (colunas) -> eles estão vinculados em muitos lugares (principalmente dl_service, prefect_worker/repo, evidentemente)
• Chave/Nome das variáveis ​​do prefeito current_model_metadata_file e monitor_pool_name
• Prefect versão 2.13.2, há bugs na modelagem do arquivo prefect.yaml e eles foram corrigidos nesta versão. Portanto, se não for necessário, não vá abaixo desta versão, caso contrário, você precisará fazer alterações nos arquivos relacionados ao Prefect.
• Evidentemente na versão 0.4.5, o bug do mmd, que usamos como método para incorporar a detecção de desvios, foi corrigido nesta versão. Novamente, se você quiser alterar a versão, tente não ir abaixo de 0.4.5.

Como tudo funciona junto

• O Jupyter Lab serve como seu espaço de trabalho para codificação. Inclui um ambiente Conda pré-instalado denominado computer-viz-dl (valor padrão), com todos os pacotes necessários para este repositório. Todos os comandos/códigos Python devem ser executados neste Jupyter.
• O Prefect orquestra todos os principais códigos de execução, incluindo tarefas e fluxos.
• O volume central_storage atua como o armazenamento central de arquivos usado durante o desenvolvimento e a implantação. Ele contém principalmente arquivos de modelo (incluindo detectores de deriva) e dados de referência no formato Parquet. No final da etapa de treinamento do modelo, novos modelos são salvos aqui e o serviço de implantação extrai modelos desse local. ( Observação : este é o local ideal para substituir serviços de armazenamento em nuvem para escalabilidade.)
• Estas são as explicações passo a passo do que acontece quando você executa o fluxo completo. O fluxo completo é composto por 3 subfluxos; treinar, avaliar e implantar em execução sequencial. Cada fluxo tem seu próprio conjunto de arquivos de configuração, pode ser um arquivo .yaml dedicado para cada fluxo ou pode ser apenas 1 arquivo .yaml para o fluxo completo (dê uma olhada nos arquivos na pasta de configuração ):
  1. Fluxo de trem
     1. Leia a configuração.
     2. Use a seção model na configuração para construir um modelo de classificador. O modelo é construído com TensorFlow e sua arquitetura é codificada em tasks/model.py:build_model .
     3. Use a seção dataset na configuração para preparar um conjunto de dados para treinamento. DvC é usado nesta etapa para verificar a consistência dos dados no disco em comparação com a versão especificada na configuração. Se houver alterações, ele converte de volta para a versão especificada programaticamente. Se quiser manter as alterações, caso esteja experimentando o conjunto de dados, você pode definir o campo dvc_checkout na configuração como falso para que o DvC não faça suas coisas.
     4. DeepChecks então valida o conjunto de dados preparado e salva o relatório de resultados. Você pode adicionar algumas condições nesta etapa. Por exemplo, se alguns testes sérios falharem, encerre o processo para que ele não treine um modelo ruim.
     5. Use a seção train na configuração para construir um carregador de dados e iniciar o processo de treinamento. As informações e os artefatos do experimento são rastreados e registrados com MLflow . Observação: o relatório de resultados (em um arquivo .html ) do DeepChecks também é carregado no experimento de treinamento no MLflow para a convenção.
     6. Crie o arquivo de metadados do modelo na seção model no arquivo config.
     7. Salve o modelo treinado e seu arquivo de metadados correspondente no disco local.
     8. Faça upload do modelo e dos arquivos de metadados do modelo para central_storage (neste caso, basta fazer uma cópia para o local central_storage . Esta é a etapa que você pode alterar para enviar arquivos para armazenamento em nuvem)
     9. Crie detectores de desvio com base no modelo treinado e na seção model/drift_detection na configuração.
     10. Salve e carregue os detectores de desvio para central_storage .
     11. Gere dados de referência usando os detectores de desvio e o conjunto de dados.
     12. Salve os dados de referência em .parquet e carregue-os em central_storage .
     13. Retorne o caminho para os modelos carregados e o arquivo de metadados do modelo para o próximo fluxo.
  2. Fluxo de avaliação
     1. Carregue modelos salvos e arquivos de metadados de modelo.
     2. Prepare um conjunto de dados para teste (reutilize a mesma tarefa do fluxo do trem)
     3. Crie um carregador de dados a partir da configuração e avalie o modelo
     4. Registre os resultados no MLflow
  3. Fluxo de implantação
     1. Solicitação PUT para acionar o serviço em execução (servido com FastAPI + Uvicorn + Gunicorn + Nginx ) para buscar o modelo recém-treinado de central_storage . (esta é uma preocupação discutida no vídeo de demonstração do tutorial, assista para mais detalhes)
     2. Crie ou atualize, se existirem, variáveis ​​de Prefect para configuração de monitoramento. Principalmente 2 variáveis ​​que são current_model_metadata_file armazenando o nome do arquivo de metadados do modelo terminado com .yaml e monitor_pool_name armazenando o nome do pool de trabalho para implantar o trabalhador e os fluxos do Prefect.
     3. Implante o fluxo do monitor Prefect que busca internamente os dados do PostgreSQL e usa o Evidently para calcular relatórios e métricas relacionados ao desvio de dados. Faça cd programaticamente em deployments/prefect-deployments e execute prefect --no-prompt deploy --name {deploy_name} usando entradas da seção deploy/prefect na configuração.
     4. O fluxo do monitor está programado para ser executado semanalmente, também conhecido como uma vez por semana. Mas você pode executar o fluxo implantado manualmente na IU do Prefect. Confira o documento oficial sobre como fazer isso (muito simples e direto)
     5. Você também pode visualizar o painel de desvio de dados na IU do Evidently (porta 8000, por padrão)

Do local para a nuvem

Como tudo já está encaixado e conteinerizado neste repositório, converter o serviço local para nuvem é bastante simples. Ao terminar de desenvolver e testar sua API de serviço, você pode simplesmente desmembrar services/dl_service construindo o contêiner a partir de seu Dockerfile e enviá-lo para um serviço de registro de contêiner em nuvem (AWS ECR, por exemplo). É isso!
Nota: Há um problema potencial no código de serviço se você quiser usá-lo em um ambiente de produção real. Abordei isso no vídeo detalhado e recomendo que você passe algum tempo assistindo o vídeo inteiro.

Esquemas de banco de dados

Temos três bancos de dados dentro do PostgreSQL: um para MLflow, um para Prefect e um que criamos para nosso serviço de modelo de ML. Não nos aprofundaremos nos dois primeiros, pois são autogerenciados por essas ferramentas. O banco de dados para nosso serviço de modelo de ML é aquele que nós mesmos projetamos.

Para evitar uma complexidade esmagadora, mantivemos tudo simples com apenas duas tabelas. Os relacionamentos e atributos são mostrados no DER abaixo. Essencialmente, nosso objetivo é armazenar detalhes essenciais sobre as solicitações recebidas e as respostas do nosso serviço. Todas essas tabelas são criadas e manipuladas automaticamente, então você não precisa se preocupar com configuração manual.

Digno de nota: input_img , raw_hm_img e overlaid_img são imagens codificadas em base64 armazenadas como strings. uae_feats e bbsd_feats são conjuntos de recursos de incorporação para nossos algoritmos de detecção de desvio.

Solução de problemas

• Se você enfrentar ImportError: /lib/aarch64-linux-gnu/libGLdispatch.so.0: cannot allocate memory in static TLS block , tente export LD_PRELOAD=/lib/aarch64-linux-gnu/libGLdispatch.so.0 e execute novamente seu roteiro.