Arquitectura de MLOps en el Lakehouse

Aquí en Databricks, hemos ayudado a miles de clientes a poner en producción el aprendizaje automático (ML). Shell cuenta con más de 160 proyectos de AI activos que ahorran millones de dólares; Comcast gestiona cientos de modelos de aprendizaje automático con facilidad gracias a MLflow; y muchos otros han creado con éxito soluciones impulsadas por ML.

Antes de trabajar con nosotros, muchos clientes tenían dificultades para poner en producción sus modelos de ML, y con razón: las operaciones de aprendizaje automático (MLOps) son todo un desafío. MLOps implica gestionar de forma conjunta el código (DevOps), los datos (DataOps) y los modelos (ModelOps) en su camino hacia la producción. El desafío más común y complejo que hemos observado es la brecha entre los datos y el ML, que a menudo se dividen en herramientas y equipos mal conectados.

Para resolver este desafío, Databricks Machine Learning se basa en la arquitectura Lakehouse para extender sus principales beneficios (simplicidad y apertura) a MLOps.

Nuestra plataforma simplifica el ML al definir un flujo de trabajo centrado en los datos que unifica las mejores prácticas de DevOps, DataOps y ModelOps. Las canalizaciones de aprendizaje automático son, en última instancia, canalizaciones de datos, donde la información pasa por las manos de diferentes roles. Los ingenieros de datos ingieren y preparan los datos; los científicos de datos crean modelos a partir de ellos; los ingenieros de ML supervisan las métricas de los modelos; y los analistas de negocio examinan las predicciones. Databricks simplifica el aprendizaje automático en producción al permitir que estos equipos de datos colaboren y gestionen esta gran cantidad de datos en una sola plataforma, en lugar de trabajar en silos. Por ejemplo, nuestro Feature Store le permite poner en producción sus modelos y características de forma conjunta: los científicos de datos crean modelos que "saben" qué características necesitan para que los ingenieros de ML puedan implementar modelos con procesos más sencillos.

El enfoque de Databricks para MLOps se basa en estándares abiertos de toda la industria. Para DevOps, nos integramos con herramientas de Git y CI/CD. Para DataOps, nos basamos en Delta Lake y el lakehouse, la arquitectura de facto para un procesamiento de datos abierto y de alto rendimiento. Para ModelOps, nos basamos en MLflow, la herramienta de código abierto más popular para la gestión de modelos. Esta base en formatos abiertos y APIs permite a nuestros clientes adaptar nuestra plataforma a sus diversos requisitos. Por ejemplo, los clientes que centralizan la gestión de modelos en torno a nuestra oferta de MLflow pueden utilizar nuestro servicio de modelos integrado u otras soluciones, según sus necesidades.

Nos entusiasma compartir nuestra arquitectura de MLOps en esta publicación de blog. Analizamos los desafíos de la combinación de DevOps + DataOps + ModelOps, ofrecemos una visión general de nuestra solución y describimos nuestra arquitectura de referencia. Para profundizar más, descargue El gran libro de MLOps y asista a las charlas sobre MLOps en el próximo Data+AI Summit 2022.

Gestión conjunta de código, datos y modelos

MLOps es un conjunto de procesos y automatización para gestionar código, datos y modelos con el fin de cumplir con dos objetivos: un rendimiento estable y eficiencia a largo plazo en los sistemas de ML. En resumen, MLOps = DevOps + DataOps + ModelOps.

Desarrollo, staging y producción

En su camino hacia las aplicaciones orientadas al negocio o al cliente, los activos de ML (código, datos y modelos) pasan por una serie de etapas. Deben desarrollarse (etapa de "desarrollo"), probarse (etapa de "staging") y desplegarse (etapa de "producción"). Este trabajo se realiza dentro de entornos de ejecución como los espacios de trabajo de Databricks.

Todo lo anterior (entornos de ejecución, código, datos y modelos) se divide en dev, staging y prod. Estas divisiones pueden entenderse en términos de garantías de calidad y control de acceso. Los activos en desarrollo pueden ser de acceso más amplio pero no tienen garantías de calidad. Los activos en producción suelen ser críticos para el negocio, con las mayores garantías de prueba y calidad, pero con controles estrictos sobre quién puede modificarlos.

Desafíos clave

El conjunto de requisitos anterior puede aumentar fácilmente su complejidad: ¿cómo se deben gestionar el código, los datos y los modelos en el desarrollo, las pruebas y la producción, a través de múltiples equipos, con complicaciones como los controles de acceso y múltiples tecnologías en juego? Hemos observado que esta complejidad genera algunos desafíos clave.

Procesos operativos
Las ideas de DevOps no se trasladan directamente a MLOps. En DevOps, existe una estrecha correspondencia entre los entornos de ejecución, el código y los datos; por ejemplo, el entorno de producción solo ejecuta código de nivel de producción y solo produce datos de nivel de producción. Los modelos de ML complican la situación, ya que las fases del ciclo de vida del modelo y del código a menudo funcionan de forma asíncrona. Es posible que desee implementar una nueva versión del modelo antes de implementar un cambio de código, y viceversa. Considere los siguientes escenarios:

• Para detectar transacciones fraudulentas, desarrolla una canalización de ML que vuelve a entrenar un modelo semanalmente. Actualiza el código trimestralmente, pero cada semana se entrena, prueba y pasa a producción automáticamente un nuevo modelo. En este escenario, el ciclo de vida del modelo es más rápido que el del código.
• Para clasificar documentos utilizando grandes redes neuronales, el entrenamiento y la implementación del modelo suelen ser un proceso de una sola vez debido al costo. Pero a medida que los sistemas descendentes cambian periódicamente, usted actualiza el código de servicio y monitoreo para que coincida. En este escenario, el ciclo de vida del código es más rápido que el del modelo.

Colaboración y gestión
MLOps debe equilibrar la necesidad de los científicos de datos de tener flexibilidad y visibilidad para desarrollar y mantener modelos con la necesidad opuesta de los ingenieros de ML de tener control sobre los sistemas de producción. Los científicos de datos necesitan ejecutar su código en datos de producción y ver registros, modelos y otros resultados de los sistemas de producción. Los ingenieros de ML deben limitar el acceso a los sistemas de producción para mantener la estabilidad y, a veces, para preservar la privacidad de los datos. Resolver estas necesidades se vuelve aún más difícil cuando la plataforma se compone de múltiples tecnologías inconexas que no comparten un único modelo de control de acceso.

Integración y personalización
Muchas herramientas de ML no están diseñadas para ser abiertas; por ejemplo, algunas herramientas de ML exportan modelos solo en formatos de caja negra, como archivos JAR. Muchas herramientas de datos no están diseñadas para ML; por ejemplo, los almacenes de datos requieren exportar datos a herramientas de ML, lo que aumenta los costos de almacenamiento y los problemas de gobernanza. Cuando estas herramientas de componentes no se basan en formatos abiertos y APIs, es imposible integrarlas en una plataforma unificada.

Simplificación de MLOps con Lakehouse

Para cumplir con los requisitos de MLOps, Databricks construyó su enfoque sobre la arquitectura Lakehouse. Los lakehouses unifican las capacidades de los lagos de datos y los almacenes de datos bajo una sola arquitectura, donde esta simplificación es posible gracias al uso de formatos abiertos y APIs que impulsan ambos tipos de cargas de trabajo de datos. De manera análoga, para MLOps, ofrecemos una arquitectura más simple porque construimos MLOps en torno a estándares de datos abiertos.

Antes de profundizar en los detalles de nuestro enfoque arquitectónico, lo explicamos a un alto nivel y destacamos sus beneficios clave.

Procesos operativos
Nuestro enfoque extiende las ideas de DevOps al ML, definiendo una semántica clara de lo que significa "pasar a producción" para el código, los datos y los modelos. Las herramientas de DevOps existentes y los procesos de CI/CD se pueden reutilizar para gestionar el código de las canalizaciones de ML. El cálculo de características, la inferencia y otras canalizaciones de datos siguen el mismo proceso de implementación que el código de entrenamiento del modelo, lo que simplifica las operaciones. Un servicio designado (el MLflow Model Registry) permite que el código y los modelos se actualicen de forma independiente, lo que resuelve el desafío clave de adaptar los métodos de DevOps al ML.

Colaboración y gestión
Nuestro enfoque se basa en una plataforma unificada que admite ingeniería de datos, ciencia de datos exploratoria, ML en producción y análisis de negocios, todo respaldado por una capa de datos lakehouse compartida. Los datos de ML se gestionan bajo la misma arquitectura lakehouse utilizada para otras canalizaciones de datos, lo que simplifica las entregas. Los controles de acceso en los entornos de ejecución, el código, los datos y los modelos permiten que los equipos adecuados obtengan los niveles de acceso correctos, simplificando la gestión.

Integración y personalización
Nuestro enfoque se basa en formatos abiertos y APIs: Git y herramientas de CI/CD relacionadas, Delta Lake y la arquitectura Lakehouse, y MLflow. El código, los datos y los modelos se almacenan en su cuenta de la nube (suscripción) en formatos abiertos, respaldados por servicios con APIs abiertas. Aunque la arquitectura de referencia descrita a continuación se puede implementar por completo dentro de Databricks, cada módulo se puede integrar con su infraestructura existente y personalizarse. Por ejemplo, el reentrenamiento del modelo puede ser totalmente automatizado, parcialmente automatizado o manual.

Arquitectura de referencia para MLOps

Ahora estamos listos para revisar una arquitectura de referencia para implementar MLOps en la plataforma Databricks Lakehouse. Esta arquitectura (y Databricks en general) es independiente de la nube, utilizable en una o varias nubes. Como tal, esta es una arquitectura de referencia destinada a adaptarse a sus necesidades específicas. Consulte The Big Book of MLOps para obtener más información sobre la arquitectura y la posible personalización.

Descripción general

Esta arquitectura explica nuestro proceso de MLOps a un alto nivel. A continuación, describimos los componentes clave de la arquitectura y el flujo de trabajo paso a paso para llevar las canalizaciones de ML a producción.

Componentes

Definimos nuestro enfoque en términos de la gestión de algunos activos clave: entornos de ejecución, código, datos y modelos.

Entornos de ejecución son donde el código crea o consume modelos y datos. Los entornos se definen como espacios de trabajo de Databricks (AWS, Azure, GCP) para desarrollo, staging y producción, con controles de acceso al espacio de trabajo utilizados para hacer cumplir la separación de roles.
En el diagrama de la arquitectura, las áreas azul, roja y verde representan los tres entornos.

Dentro de los entornos, cada canalización de ML (los cuadros pequeños en el diagrama) se ejecuta en instancias de computación gestionadas por nuestro servicio de Clusters (AWS, Azure, GCP). Estos pasos se pueden ejecutar manualmente o automatizarse a través de Workflows y Jobs (AWS, Azure, GCP). Cada paso debe utilizar de forma predeterminada un Databricks Runtime para ML con bibliotecas preinstaladas (AWS, Azure, GCP), pero también puede utilizar bibliotecas personalizadas (AWS, Azure, GCP).

El código que define las canalizaciones de ML se almacena en Git para el control de versiones. Las canalizaciones de ML pueden incluir la generación de características, el entrenamiento y ajuste de modelos, la inferencia y el monitoreo. A grandes rasgos, "llevar ML a producción" significa promover el código desde las ramas de desarrollo, a través de la rama de staging (generalmente `main`), y hacia las ramas de lanzamiento para su uso en producción. Esta alineación con DevOps permite a los usuarios integrar las herramientas de CI/CD existentes. En el diagrama de arquitectura anterior, este proceso de promoción de código se muestra en la parte superior.

Al desarrollar canalizaciones de ML, los científicos de datos pueden comenzar con notebooks y hacer la transición a código modularizado según sea necesario, trabajando en Databricks o en IDEs. Databricks Repos se integra con su proveedor de git para sincronizar notebooks y código fuente con los espacios de trabajo de Databricks (AWS, Azure, GCP). Las herramientas de desarrollo de Databricks le permiten conectarse desde IDEs y sus sistemas de CI/CD existentes (AWS, Azure, GCP).

Los datos se almacenan en una arquitectura lakehouse, todo en su cuenta de la nube. Las canalizaciones para la generación de características, la inferencia y el monitoreo se pueden tratar como canalizaciones de datos. Por ejemplo, el monitoreo de modelos debe seguir la arquitectura de medallón de refinamiento progresivo de datos, desde eventos de consulta sin procesar hasta tablas agregadas para paneles de control. En el diagrama de arquitectura anterior, los datos se muestran en la parte inferior como datos generales de "Lakehouse", ocultando la división en datos de nivel de desarrollo, staging y producción.

De forma predeterminada, tanto los datos sin procesar como las tablas de características deben almacenarse como tablas Delta para garantizar el rendimiento y la coherencia. Delta Lake proporciona una capa de almacenamiento abierta y eficiente para datos estructurados y no estructurados, con un Delta Engine optimizado en Databricks (AWS, Azure, GCP). Las tablas de Feature Store son simplemente tablas Delta con metadatos adicionales como el linaje (AWS, Azure, GCP). Los archivos y tablas sin procesar están bajo un control de acceso que se puede otorgar o restringir según sea necesario.

Los modelos son gestionados por MLflow, lo que permite una gestión uniforme de modelos de cualquier biblioteca de ML, para cualquier modo de despliegue, tanto dentro como fuera de Databricks. Databricks proporciona una versión gestionada de MLflow con controles de acceso, escalabilidad a millones de modelos y un superconjunto de APIs de MLflow de código abierto.

En el desarrollo, el servidor de MLflow Tracking realiza el seguimiento de los modelos prototipo junto con instantáneas de código, parámetros, métricas y otros metadatos (AWS, Azure, GCP). En producción, el mismo proceso guarda un registro para la reproducibilidad y la gobernanza.

Para el despliegue continuo (CD), MLflow Model Registry realiza el seguimiento del estado de despliegue de los modelos y se integra con sistemas de CD a través de webhooks (AWS, Azure, GCP) y a través de APIs (AWS, Azure, GCP). El servicio Model Registry realiza el seguimiento de los ciclos de vida de los modelos de forma independiente de los ciclos de vida del código. Este acoplamiento débil entre modelos y código ofrece la flexibilidad de actualizar los modelos de producción sin necesidad de realizar cambios en el código, y viceversa. Por ejemplo, un pipeline de reentrenamiento automatizado puede entrenar un modelo actualizado (un modelo de "desarrollo"), probarlo (modelo de "staging") y desplegarlo (modelo de "producción"), todo dentro del entorno de producción.

La siguiente tabla resume la semántica de "desarrollo", "staging" y "producción" para el código, los datos y los modelos.