full stack on prem cv mlops

Sistema MLOps local completo para visión por computadora

▶️ 1 configuración, 1 comando de Jupyter Notebook para servir a millones de usuarios ◀️

Tabla de contenido

• Descripción general
• Vídeos de demostración
• Herramientas / Tecnologías
• Prácticas adoptadas
• Puertos de servicio
• como usar
  • Configuración
  • Uso mínimo
  • Personalización
• Cómo funciona todo junto
• De lo local a lo en la nube
• esquemas de base de datos
• Solución de problemas

Descripción general

Bienvenido a nuestro completo ecosistema MLOps local diseñado específicamente para tareas de visión por computadora, con un enfoque principal en la clasificación de imágenes. Este repositorio le proporciona todo lo que necesita, desde un espacio de trabajo de desarrollo en Jupyter Lab/Notebook hasta servicios de nivel de producción. ¿La mejor parte? ¡Solo se necesita "1 configuración y 1 comando" para ejecutar todo el sistema desde la construcción del modelo hasta la implementación! Hemos integrado numerosas mejores prácticas para garantizar la escalabilidad y la confiabilidad manteniendo la flexibilidad. Si bien nuestro caso de uso principal gira en torno a la clasificación de imágenes, la estructura de nuestro proyecto puede adaptarse fácilmente a una amplia gama de desarrollos de ML/DL, ¡incluso pasando de las instalaciones a la nube!

Otro objetivo es mostrar cómo integrar todas estas herramientas y hacer que funcionen juntas en un sistema completo. Si está interesado en componentes o herramientas específicos, no dude en elegir lo que se adapte a las necesidades de su proyecto.

Todo el sistema está contenedorizado en un único archivo Docker Compose. Para configurarlo, ¡todo lo que tienes que hacer es ejecutar docker-compose up ! Este es un sistema completamente local, lo que significa que no es necesario tener una cuenta en la nube, ¡y no le costará ni un centavo usar todo el sistema!

Recomendamos encarecidamente ver los vídeos de demostración en la sección Vídeos de demostración para obtener una descripción general completa y comprender cómo aplicar este sistema a sus proyectos. Estos videos contienen detalles importantes que pueden ser demasiado largos y no lo suficientemente claros como para cubrirlos aquí.

Vídeos de demostración

Demostración: https://youtu.be/NKil4uzmmQc
Tutorial técnico detallado: https://youtu.be/l1S5tHuGBA8

Recursos en el vídeo:

• Archivos de modelo (modelos basados ​​en ResNet50): enlace
• Diapositiva: enlace

Herramientas / Tecnologías

Para utilizar este repositorio, solo necesitas Docker. Como referencia, utilizamos Docker versión 24.0.6, compilación ed223bc y Docker Compose versión v2.21.0-desktop.1 en Mac M1.

• Plataforma: ventana acoplable
• Espacio de trabajo: Laboratorio Jupyter
• Marco de aprendizaje profundo: TensorFlow
• Versionado de datos: DvC
• Validación de datos: DeepChecks
• Plataforma de Machine Learning / Seguimiento de experimentos: MLflow
• Orquestador de oleoductos: Prefecto
• Implementación del servicio Machine Learning: FastAPI, Uvicorn, Gunicorn, Nginx (+ HTML, CSS, JS para una interfaz de usuario sencilla)
• Bases de datos: PostgreSQL (SQL), Prometheus (series temporales)
• Monitoreo de modelos de aprendizaje automático y detección de deriva: evidentemente
• Panel y monitoreo general del sistema: Grafana

Prácticas adoptadas

Hemos implementado varias mejores prácticas en este proyecto:

• Cargador/canalización de datos eficiente usando tf.data para TensorFlow
• Aumento de imágenes con imgaug lib para una mayor flexibilidad en las opciones de aumento que las funciones principales de TensorFlow
• Uso de os.env para configuraciones importantes o de nivel de servicio
• Iniciar sesión con el módulo logging en lugar de print
• Almacenamiento de base de datos para resultados de respuesta del servicio.
• Configuración dinámica mediante .env para variables en docker-compose.yml
• Uso de default.conf.template para que Nginx aplique elegantemente variables de entorno en la configuración de Nginx (nueva característica en Nginx 1.19)
• Configuración de Nginx para visualización de registros de terminal
• Configurar un trabajador prefecto para apoyar el trabajo en un clúster

Puertos de servicio

La mayoría de los puertos se pueden personalizar en el archivo .env en la raíz de este repositorio. Aquí están los valores predeterminados:

• JupyterLab: 8888 (contraseña: 123456789 )
• Flujo ml: 5050
• Prefecto: 4200
• PostgreSQL: 5432
• pgAdmin: 16543 (usuario: [email protected] , contraseña: SuperSecurePwdHere )
• Servicio de aprendizaje profundo: 4242
• Interfaz de usuario web para el servicio de aprendizaje profundo: 4243
• Nginx: 80
• Evidentemente: 8000
• Prometeo: 9090
• Grafana: 3000 (usuario: admin , contraseña: admin )

como usar

Debe considerar comentar esas líneas platform: linux/arm64 en docker-compose.yml si no usa una computadora basada en ARM (estamos usando Mac M1 para el desarrollo). De lo contrario, este sistema no funcionará.

Configuración

1. Clona este repositorio. Hay 2 submódulos en este repositorio, así que considere usar el indicador --recurse-submodules en su comando: git clone --recurse-submodules https://github.com/jomariya23156/full-stack-on-prem-cv-mlops
2. [Para usuarios con CUDA] Si tiene GPU compatibles con CUDA, puede descomentar la sección deploy en el servicio jupyter en docker-compose.yml y cambiar la imagen base en services/jupyter/Dockerfile de ubuntu:18.04 a nvidia/cuda:11.4.3-cudnn8-devel-ubuntu20.04 (el texto está en el archivo, solo necesitas comentar y descomentar) para aprovechar su(s) GPU(s). Es posible que también necesites instalar nvidia-container-toolkit en la máquina host para que funcione. Para los usuarios de Windows/WSL2, este artículo nos parece muy útil.
3. En la raíz del directorio del repositorio, ejecute docker-compose up o docker-compose up -d para desconectar el terminal.
4. La primera vez, puede tardar un poco debido al tamaño de las imágenes, especialmente para jupyter, ya que contiene muchos paquetes y bibliotecas. Generalmente puede tardar entre 5 y 20 minutos.
5. Vaya al submódulo DvC en datasets/animals10-dvc y siga los pasos de la sección Cómo utilizar .

Uso mínimo

1. Abra el laboratorio de Jupyter en el puerto 8888 http://localhost:8888/lab
2. Vaya al directorio del espacio de trabajo cd ~/workspace/
3. Active el entorno conda (el nombre se puede configurar en docker-compose.yml ) conda activate computer-viz-dl
4. Ejecute python run_flow.py --config configs/full_flow_config.yaml
5. ¡Siéntese y observe cómo se construye, entrena, evalúa, implementa (a escala) y monitorea su nuevo clasificador en un sistema completamente operativo!

Personalización

• Hay muchas cosas trabajando juntas y es difícil hablar en detalle cada detalle. ¡No hay mejor manera que ensuciarse las manos, es decir, leer códigos, intentar comprenderlos e intentar personalizarlos usted mismo!
• De todos modos, existen algunas pautas que puede seguir para que los componentes funcionen perfectamente como deberían:
  • Tus tareas deben crearse dentro del directorio tasks .
  • Se supone que todas sus tareas deben llamarse desde los flujos que se crean dentro del directorio de flows .
  • Sus flujos deben llamarse con run_flow.py en la raíz del repositorio.
  • Para que se le llame de esta manera, debe implementar la función start(config) en su archivo de flujo. Esta función acepta la configuración como un dictado de Python y luego básicamente llama al flujo específico en ese archivo.
  • Los conjuntos de datos deben residir dentro del directorio de datasets y todos deben tener la misma estructura de directorio que el que está dentro de este repositorio.
  • central_storage en ~/ariya/ debe contener al menos 2 subdirectorios llamados models y ref_data . Este central_storage cumple con el propósito de almacenamiento de objetos de almacenar todos los archivos preparados para su uso en entornos de desarrollo e implementación. (Esta es una de las cosas que podría considerar cambiar a un servicio de almacenamiento en la nube en caso de que desee implementarlo en la nube y hacerlo más escalable)

Convenciones IMPORTANTES que deben tener SÚPER CUIDADO si desea cambiar (porque estas cosas están vinculadas y utilizadas en diferentes partes del sistema):

• ruta central_storage -> Dentro debe haber models/ ref_data/ subdirectorios
• Nomenclatura de archivos en central_storage, por ejemplo, <model_name>.yaml , <model_name>_uae , <model_name>_bbsd , <model_name>_ref_data.parquet
• Todos los esquemas de bases de datos (columnas) -> están vinculados en muchos lugares (principalmente dl_service, prefect_worker/repo, evidentemente)
• Clave/Nombre de las variables prefectas current_model_metadata_file y monitor_pool_name
• Prefect versión 2.13.2, hay errores en la creación de plantillas del archivo prefect.yaml y se solucionaron en esta versión. Entonces, si no es necesario, no baje de esta versión; de lo contrario, deberá realizar cambios en los archivos relacionados con Prefect.
• Evidentemente, en la versión 0.4.5, el error del mmd, que utilizamos como método para incorporar la detección de deriva, se solucionó en esta versión. Nuevamente, si desea cambiar la versión, intente no bajar de 0.4.5.

Cómo funciona todo junto

• Jupyter Lab sirve como espacio de trabajo para la codificación. Incluye un entorno Conda preinstalado llamado computer-viz-dl (valor predeterminado), con todos los paquetes necesarios para este repositorio. Se supone que todos los comandos/códigos de Python se ejecutan dentro de este Jupyter.
• Prefect organiza todos los códigos de ejecución principales, incluidas las tareas y los flujos.
• El volumen central_storage actúa como almacenamiento de archivos central utilizado durante el desarrollo y la implementación. Contiene principalmente archivos de modelo (incluidos detectores de deriva) y datos de referencia en formato Parquet. Al final del paso de entrenamiento del modelo, los nuevos modelos se guardan aquí y el servicio de implementación extrae los modelos de esta ubicación. ( Nota : este es un lugar ideal para reemplazarlo con servicios de almacenamiento en la nube para lograr escalabilidad).
• Estas son las explicaciones paso a paso de lo que sucede cuando ejecuta el flujo completo. El flujo completo se compone de 3 subflujos; entrenar, evaluar e implementar ejecutándose secuencialmente. Cada flujo tiene su propio conjunto de archivos de configuración, puede ser un archivo .yaml dedicado para cada flujo o puede ser solo 1 archivo .yaml para el flujo completo (consulte los archivos en la carpeta de configuración ):
  1. Flujo de trenes
     1. Lea la configuración.
     2. Utilice la sección model en la configuración para crear un modelo de clasificador. El modelo está construido con TensorFlow y su arquitectura está codificada en tasks/model.py:build_model .
     3. Utilice la sección dataset en la configuración para preparar un conjunto de datos para el entrenamiento. DvC se utiliza en este paso para verificar la coherencia de los datos en el disco en comparación con la versión especificada en la configuración. Si hay cambios, lo convierte nuevamente a la versión especificada mediante programación. Si desea conservar los cambios, en caso de que esté experimentando con el conjunto de datos, puede configurar el campo dvc_checkout en la configuración en falso para que DvC no haga sus cosas.
     4. Luego, DeepChecks valida el conjunto de datos preparado y guarda el informe de resultados. Puede agregar algunas condiciones en este paso. Por ejemplo, si algunas pruebas importantes fallan, finalice el proceso para que no entrene un modelo incorrecto.
     5. Utilice la sección train en la configuración para crear un cargador de datos e iniciar el proceso de capacitación. La información y los artefactos del experimento se rastrean y registran con MLflow . Nota: el informe de resultados (en un archivo .html ) de DeepChecks también se carga en el experimento de capacitación en MLflow para la convención.
     6. Cree el archivo de metadatos del modelo desde la sección model en la configuración.
     7. Guarde el modelo entrenado y su archivo de metadatos correspondiente en el disco local.
     8. Cargue el modelo y los archivos de metadatos del modelo en central_storage (en este caso, solo se trata de hacer una copia en la ubicación de central_storage . Este es el paso que puede cambiar para cargar archivos en el almacenamiento en la nube)
     9. Cree detectores de deriva basados ​​en el modelo entrenado y la sección model/drift_detection en la configuración.
     10. Guarde y cargue los detectores de deriva en central_storage .
     11. Genere datos de referencia utilizando los detectores de deriva y el conjunto de datos.
     12. Guarde los datos de referencia en .parquet y cárguelos en central_storage .
     13. Devuelva la ruta a los modelos cargados y al archivo de metadatos del modelo para el siguiente flujo.
  2. Flujo de evaluación
     1. Cargue modelos guardados y archivos de metadatos de modelos.
     2. Prepare un conjunto de datos para realizar pruebas (reutilice la misma tarea que en el flujo del tren)
     3. Cree un cargador de datos a partir de la configuración y evalúe el modelo.
     4. Registre los resultados en MLflow
  3. Flujo de implementación
     1. Solicitud PUT para activar el servicio en ejecución (servido con FastAPI + Uvicorn + Gunicorn + Nginx ) para recuperar el modelo recién entrenado desde central_storage . (Esta es una preocupación que se analiza en el vídeo de demostración del tutorial; mírelo para obtener más detalles)
     2. Crear o actualizar, si existieran, variables de Prefecto para la configuración de monitoreo. Principalmente 2 variables que son current_model_metadata_file que almacena el nombre del archivo de metadatos del modelo terminado en .yaml y monitor_pool_name que almacena el nombre del grupo de trabajo para implementar flujos y trabajadores de Prefect.
     3. Implemente el flujo de monitor Prefecto que recupera internamente los datos de PostgreSQL y los utiliza Evidfully para calcular informes y métricas relacionados con la deriva de datos. Programe cd en deployments/prefect-deployments y ejecute prefect --no-prompt deploy --name {deploy_name} usando entradas de la sección deploy/prefect en la configuración.
     4. El flujo del monitor está programado para ejecutarse semanalmente, es decir, una vez por semana. Pero puedes ejecutar el flujo implementado manualmente desde Prefect UI. Consulte su documento oficial sobre cómo hacer esto (bastante simple y directo)
     5. También puede ver el panel de derivación de datos en Evidentemente UI (puerto 8000, de forma predeterminada)

De lo local a lo en la nube

Dado que todo ya está acoplado y contenedorizado en este repositorio, convertir el servicio de local a en la nube es bastante sencillo. Cuando termine de desarrollar y probar la API de su servicio, puede simplemente crear servicios/dl_service construyendo el contenedor desde su Dockerfile y enviarlo a un servicio de registro de contenedores en la nube (AWS ECR, por ejemplo). ¡Eso es todo!
Nota: Existe un problema potencial en el código de servicio si desea utilizarlo en un entorno de producción real. Lo he abordado en el vídeo en profundidad y te recomiendo que dediques un rato a ver el vídeo completo.

esquemas de base de datos

Tenemos tres bases de datos dentro de PostgreSQL: una para MLflow, otra para Prefect y una que hemos creado para nuestro servicio de modelo ML. No profundizaremos en los dos primeros, ya que son autogestionados por dichas herramientas. La base de datos para nuestro servicio de modelo ML es la que hemos diseñado nosotros mismos.

Para evitar una complejidad abrumadora, lo hemos mantenido simple con solo dos tablas. Las relaciones y atributos se muestran en el ERD a continuación. Básicamente, nuestro objetivo es almacenar detalles esenciales sobre las solicitudes entrantes y las respuestas de nuestro servicio. Todas estas tablas se crean y manipulan automáticamente, por lo que no necesita preocuparse por la configuración manual.

Cabe destacar: input_img , raw_hm_img y overlaid_img son imágenes codificadas en base64 almacenadas como cadenas. uae_feats y bbsd_feats son conjuntos de funciones integradas para nuestros algoritmos de detección de deriva.

Solución de problemas

• Si se enfrenta ImportError: /lib/aarch64-linux-gnu/libGLdispatch.so.0: cannot allocate memory in static TLS block , intente export LD_PRELOAD=/lib/aarch64-linux-gnu/libGLdispatch.so.0 y luego vuelva a ejecutar su guion.