De la plataforma de datos a la plataforma de aprendizaje automático

De la plataforma de datos al aprendizaje automático

Cómo evolucionan las plataformas de datos/ML y apoyan prácticas complejas de MLOps

Los datos/ML han sido el tema más popular en nuestro panorama tecnológico. Quiero compartir mi comprensión de la plataforma de datos/ML y cómo evolucionarán esas plataformas de básicas a complejas. Por último, hago todo lo posible por cubrir MLOps, un principio para gestionar proyectos de ML.

Sobre quién soy, aquí está mi LinkedIn.

Inicio del viaje: Servicio en línea + OLTP + OLAP

Al principio, las infraestructuras de datos podían ser bastante simples. Las consultas analíticas pueden enviarse a la réplica de lectura de una base de datos OLTP en línea o configurar una base de datos OLAP como almacén de datos.

Así es como podría ser la infraestructura:

• Potencia múltiples sitios web con la solución de chatbot de Langchain
• Aplicaciones de IA generativa con Amazon Bedrock introducción para desarrolladores de Go
• Búsqueda de imágenes en 5 minutos

No hay nada malo en esos sistemas siempre y cuando cumplan con los requisitos comerciales. Todos los sistemas que cumplen nuestras necesidades comerciales son buenos sistemas. Si son simples, aún mejor.

En esta etapa, hay varias formas de realizar análisis de datos:

1. Simplemente enviar consultas al nodo réplica de la base de datos OLTP (no se recomienda).
2. Habilitar la captura de cambios (CDC, por sus siglas en inglés) de la base de datos OLTP e ingresar esos datos a la base de datos OLAP. En cuanto a la opción del servicio de ingestión para los registros de CDC, puede elegir según la base de datos OLAP que haya seleccionado. Por ejemplo, Flink data streaming con conectores CDC es una forma de manejar esto. Muchos servicios empresariales vienen con su propia solución sugerida, por ejemplo, Snowpipe para Snowflake. También se recomienda cargar datos desde el nodo réplica para preservar el ancho de banda de CPU/E/S de nodo principal para el tráfico en línea.

En esta etapa, las cargas de trabajo de ML pueden ejecutarse en su entorno local. Puede configurar un bloc de notas de Jupyter localmente y cargar datos estructurados desde la base de datos OLAP, luego entrenar su modelo de ML localmente.

Los desafíos potenciales de esta arquitectura son, entre otros:

• Es difícil gestionar datos no estructurados o semiestructurados con una base de datos OLAP.
• La base de datos OLAP puede tener una regresión de rendimiento cuando se trata de procesamiento masivo de datos (más de TB de datos requeridos para una sola tarea de ETL).
• Falta de soporte para varios motores de cálculo, como Spark o Presto. La mayoría de los motores de cálculo admiten la conexión a OLAP con un punto de conexión JDBC, pero el procesamiento paralelo se verá gravemente limitado por el cuello de botella de E/S del propio punto de conexión JDBC.
• El costo de almacenar grandes cantidades de datos en una base de datos OLAP es elevado.

Es posible que ya conozca la dirección para resolver esto. ¡Construya un Lago de datos! Traer un Lago de datos no implica necesariamente que deba dar de baja por completo la base de datos OLAP. Aún es común ver empresas que tienen dos sistemas que coexisten para diferentes casos de uso.

Lago de datos: Separación de almacenamiento y cómputo + Esquema en escritura

Un lago de datos le permite persistir datos no estructurados y semiestructurados, y realizar un esquema en escritura. Le permite reducir costos almacenando grandes volúmenes de datos con una solución de almacenamiento especializada y crear clústeres de cómputo en función de su demanda. Además, le permite gestionar conjuntos de datos de TB/PB sin esfuerzo al escalar los clústeres de cómputo.

Así es como podría ser su infraestructura:

Este es un gráfico simplificado en efecto. La implementación real de un lago de datos puede ser mucho más complicada.

Actualmente, muchos proveedores de servicios en la nube ofrecen soluciones de almacenamiento bastante establecidas para los Data lake, como AWS S3 y Azure ADLS. Sin embargo, todavía hay muchas tareas que se deben realizar junto con esas soluciones de almacenamiento. Por ejemplo, se debería tener un metastore Hive para administrar los metadatos de las tablas y un Datahub para proporcionar visibilidad de los datos. También existen temas desafiantes como el control de permisos detallados en el Data lake y el análisis de linaje de los datos (por ejemplo, spline).

Para maximizar el valor y la eficiencia de su Data lake, debemos elegir cuidadosamente el formato de archivo y el tamaño promedio de archivo para cada capa de su Data lake.

Los consejos generales son:

• Avoid small files: Los archivos pequeños son una de las principales causas de alto costo de almacenamiento y mal rendimiento en el Data lake.
• Balance entre latencia, relación de compresión y rendimiento: Una tabla del Data lake con baja latencia y formato de archivo como Hudi puede que no le brinde la mejor relación de compresión, y los archivos ORC grandes con alta relación de compresión pueden darle un rendimiento desastroso. Es posible que desee elegir el formato de archivo sabiamente basado en el patrón de uso de la tabla, los requisitos de latencia y los tamaños de tabla.

Existen algunos proveedores SaaS/PaaS bastante establecidos como Databricks que ofrecen una solución decente para Data lake (o LakeHouse ahora). También puede explorar ByteHouse para tener una experiencia unificada de análisis de big data.

En cuanto al aprendizaje automático (ML), el equipo podría comenzar a explorar marcos de trabajo de ML bien establecidos como Tensenflow y Pytorch en entornos remotos. Además, los modelos de ML entrenados podrían implementarse en entornos de producción para realizar inferencias de modelos en línea. Tanto Tensorflow como Pytorch vienen con una solución de servir, como TensorFlow Serving y Pytorch Serving.

Sin embargo, nuestra tarea no terminará aquí. Podríamos enfrentar los siguientes desafíos ahora:

• Falta de métricas en tiempo real y gestión de características que son críticas para el servicio en línea de modelos de ML.
• Falta de monitoreo del rendimiento del modelo.

Avancemos aún más en nuestro juego.

Infraestructura en tiempo real de datos/ML: Data River + Data Streaming + Feature Store + Metric Server

Normalmente, construir una infraestructura de datos en tiempo real es un esfuerzo conjunto de varios departamentos de una empresa. La justificación inicial para construir un Data River generalmente no es para sistemas de datos/ML, sino para permitir que los microservicios crezcan aún más mediante la eliminación de llamadas sincronizadas. En cambio, los microservicios ganarán eficiencia al comunicarse con un intermediario de mensajes como Kafka (a costa de un nivel de consistencia más bajo).

La arquitectura general podría ser similar a esto:

Con los datos disponibles en el Data River (por ejemplo, Kafka), podemos construir una tubería de transmisión de datos para procesar datos en tiempo real. Esos datos se pueden utilizar directamente en el almacenamiento de características en línea o sincronizarse con un servidor de métricas como Pinot. El servidor de métricas puede procesar/agregar aún más esos puntos de métricas para obtener métricas de rendimiento del modelo y métricas comerciales más útiles. También puede adoptar una base de datos de transmisión como RisingWave que puede unir/agregar datos de transmisión con una sintaxis SQL.

Para construir la transmisión de datos en sí, Flink es bastante popular. También puede usar Flink con conector CDC para extraer datos de una base de datos OLTP y enviar datos a intermediarios de mensajes y al Data lake.

Debería existir un almacenamiento de características en línea respaldado por una base de datos clave-valor como ScyllaDB o AWS Dynamo DB. El almacenamiento de características en línea puede ayudarlo a enriquecer la solicitud enviada al servicio de Model Serving con un vector de características asociado a cierto ID de referencia (ID de usuario, UUID de producto). Esto puede desacoplar en gran medida la dependencia entre el equipo de servicios backend que construye microservicios y el equipo de ingenieros de ML que construye modelos de ML. Permite a los ingenieros de ML implementar nuevas características de ML con nuevos modelos de ML de forma independiente (la API de servicio de su modelo que se expone a los microservicios seguirá siendo la misma cuando actualize el vector de características).

En el libro Diseñando Sistemas de Aprendizaje Automático, se ha compartido sobre el Modelo de Stacking (Jen Wadkin’s publicación de VoAGI sobre el modelo de stacking). Es bastante común que las personas también utilicen el modelo de stacking en la implementación de modelos. Se requiere un orquestador cuando se quiere combinar modelos heterogéneos, por ejemplo, combinar modelos de PyTorch y TensorFlow. Incluso puedes hacer que tu orquestador sea más complejo al tener un peso dinámico basado en el rendimiento del modelo al enrutamiento de solicitudes a diferentes modelos.

Ahora tenemos un sistema complicado. Se ve bastante genial, pero conlleva nuevos desafíos:

• La deuda del sistema se disparará si se deja sin control.
• Alto nivel cognitivo para los ingenieros de Aprendizaje Automático.

Probablemente ahí es cuando necesitas pensar cómo MLOps puede ayudarte.

MLOps: Abstracción, Observabilidad y Escalabilidad

MLOps nunca es una solución específica. Es más bien un conjunto de principios para administrar los sistemas de Aprendizaje Automático. A diferencia de un proyecto de software típico, los sistemas de Aprendizaje Automático se ven muy afectados por el cambio de datos, y la gestión de la dependencia de los datos no es una tarea fácil. El artículo “Deuda Técnica Oculta en Sistemas de Aprendizaje Automático” (Hidden Technical Debt in Machine Learning Systems) describe esos desafíos en detalle. Por lo tanto, una plataforma de Aprendizaje Automático impulsada por MLOps debe poder:

• Monitorear el cambio de datos y la calidad de los datos.
• Administrar las características de Aprendizaje Automático en entornos offline y online.
• Tener una canalización de Aprendizaje Automático reproducible que cumpla con la simetría experimental-operacional.
• Tener una configuración concisa de la canalización de Aprendizaje Automático que pueda abstraer los detalles de infraestructura.

Este artículo, MLOps: Entrega continua y canalizaciones automatizadas en el aprendizaje automático, destaca la importancia de la simetría experimental-operacional. También describe el nivel de automatización de MLOps, desde el nivel-0, nivel-1 hasta finalmente el nivel-2. Realmente me gusta el gráfico de este documento y lo voy a utilizar para explicar cómo se ve el nivel-1 de MLOps.

Para escalar esta práctica de MLOps en tu organización, necesitas proporcionar una configuración concisa de la canalización de Aprendizaje Automático que pueda abstraer los detalles de implementación de infraestructura para los Ingenieros de Aprendizaje Automático. Al hacer esto, los ingenieros de plataforma también adquieren flexibilidad para actualizar la plataforma de Aprendizaje Automático sin causar demasiadas interrupciones a los usuarios de la plataforma. Puedes considerar el uso de archivos de configuración como YAML para describir las canalizaciones de Aprendizaje Automático y confiar en los controladores de tu Canalización de Aprendizaje Automático para traducirlos en carga de trabajo real.

Así que reorganicemos la infraestructura de datos/ML en tiempo real con el siguiente gráfico para destacar cómo MLOps da forma a nuestras plataformas.

Para darte una mejor idea de cómo podrían ser las canalizaciones de Aprendizaje Automático. Aquí hay posibles ejemplos de abstracciones para cada etapa en la canalización de Aprendizaje Automático. El siguiente gráfico solo te ayuda a comprender mejor cómo podría ser la configuración. No representa ninguna implementación real. Tampoco cubre todos los aspectos requeridos.

Kubernetes es una solución popular para orquestar la carga de trabajo de ML (o tal vez toda la carga de trabajo en la actualidad). Puede utilizar CRDs para proporcionar interfaces concisas entre los usuarios y las plataformas. En el artículo Mi pensamiento sobre Kubebuilder, he compartido algunas de mis reflexiones al construir CRD con Kubebuilder.

Por supuesto, no cubrí muchos temas importantes como la Optimización de Hiperparámetros y la arquitectura de Entrenamiento Distribuido.

Qué sigue

Puedes ver MLOps solo da a una misión conocida un nombre adecuado. Está lejos de ser un trabajo terminado. Lo que compartí es una estrategia con opiniones para implementar una plataforma de ML Ops. Incluso con eso, el nivel para crear productos de ML de alta calidad sigue siendo alto, y el esfuerzo de recopilación, procesamiento y exploración de datos sigue siendo considerable.

Además de esos desafíos, también quiero compartir las tendencias en el panorama de ML que he observado. Sin duda, no es una lista completa dado lo rápido que evoluciona este campo.

• Servicios sin servidor: Hemos dejado el valor de ML muy atrás porque la base de una plataforma de ML suele ser una plataforma de datos. Es como obligar a los usuarios a comprar computadoras para participar en plataformas de redes sociales cuando ya estamos en la era de los dispositivos móviles. Los servicios sin servidor y los clústeres de cómputo están abordando este desafío. Muchos proveedores de servicios exploran su propia solución de sin servidor para reducir la barrera de adopción, por ejemplo, Databricks, Snowflake, Bytehouse. Las empresas pueden comenzar a construir sus productos de ML después de crear almacenes de datos o lagos de datos.
• Ingeniería de características impulsada por IA: Bueno, ahora la IA puede hacer de todo, ¿verdad?
• Tendencias de MaaS: Aparecerán Model-as-a-Service más potentes. Las empresas podrán aprovechar directamente el poder del ML sin siquiera construir su propio servicio de ML para impulsar su negocio.

Como todos hemos notado, el espacio de ML evoluciona tan rápido. En este preciso momento, cuando estoy escribiendo esto, este artículo podría estar obsoleto. Ya han surgido más ideas y se han traducido en realidad. Por favor, déjame saber qué piensas sobre ML Ops, o dónde debería seguir aprendiendo. ¡Mantengámonos al día juntos!

We will continue to update Zepes; if you have any questions or suggestions, please contact us!