Autores: Luis Galo y Dr. Lídia Almazán Torres, Data Scientists en Lantek
En un artículo anterior explicamos qué es MLOps (Machine Learning Operations). En este artículo abordamos la diferencia entre dos entornos muy usados para ML (Machine Learning): Databricks y Azure ML workspace de Azure. El primero es de código abierto y no está orientado a MLOps; y el segundo es propietario de Azure y está pensado desde su origen como plataforma MLOps.
En todo proyecto surge la duda de cómo gestionar los modelos y qué herramientas usar para supervisar todo el ciclo de vida del software y facilitar su gestión, así como la labor de los desarrolladores. Aunque la tendencia es usar herramientasde código abierto, existen herramientas propietarias, pero gratuitas que facilitan mucho el desarrollo de aplicaciones ML, por ejemplo, Azure ML SDK.
En este artículo se comparan dos de los entornos más usados para desarrollar sistemas de aprendizaje automático y en la conclusión se propone la mejor solución.
¿Qué es Azure Databricks? Databricks es una plataforma analítica unificada que permite a los equipos realizar, de forma colaborativa, desde análisis de datos hasta soluciones de ciencia de datos utilizando Apache Spark.
¿Qué es Azure Machine Learning? Azure Machine Learning Service (AMLS) es la solución propietaria de Microsoft para apoyar el ciclo de vida de aprendizaje automático en Azure. AML recibe continuamente nuevas características al actualizar el proceso MLOps. Actualmente, se puede utilizar la SDK de Python para interactuar con el servicio o se puede utilizar Designer para realizar modelos sencillos de forma visual.
Las principales diferencias entre ambos entornos radican en lo siguiente:
AMLS incluye la funcionalidad de realizar el seguimiento de los conjuntos de datos, experimentos, pipelines, modelos y puntos de conexión. Además, puede aprovisionar fácilmente máquinas virtuales, clústeres entrenamiento e inferencia directamente desde su entorno web (y desde el SDK), y permite a los usuarios utilizar prácticamente cualquier paquete de Python usando Conda (un gestor de paquetes y sistema de gestión de entornos).
Se puede usar Databricks con MLFlow como motor de seguimiento dentro de Databricks, pero es un paquete aparte y requiere tiempo de mantenimiento. Aunque es un paquete de código abierto que viene preinstalado y habilitado en las versiones más recientes de ML en Databricks, MLFlow es un MLOps limitado y se restringe únicamente al control del ciclo de vida del modelo, no monitoriza el estado del modelo ni los datos.
Azure ML es mejor opción cuando se entrena con datos limitados (pequeños y medianos) en una sola máquina. Aunque Azure ML proporciona clústeres de procesado, la distribución de datos entre los nodos debe ser codificada por desarrolladores, por lo cual no es una opción adecuada para macrodatos.
Azure Databricks está diseñado para manejar datos distribuidos en múltiples nodos y de forma masiva, siempre y cuando se usen las bibliotecas de Databricks y Spark, lo cual es una ventaja para procesar datos de gran volumen.
Databricks puede albergar muchos formatos de archivo de forma nativa. Es fácil consultar y limpiar conjuntos de datos de gran volumen, mientras que en Azure ML tiene que ser gestionado de forma personalizada con bibliotecas de Python, donde la limpieza y escritura en el almacenamiento de datos debe realizarse por código.
Ambas plataformas tienen la capacidad de distribuir entrenamiento. Databricks proporciona algoritmos de ML (MLib) adaptados que pueden actuar en un chunk de datos en el nodo maestro y coordinarse con otros nodos. Aunque esto se puede hacer en AMLS, la gestión del flujo de datos y algoritmos se debe programar previamente.
AMLS ofrece implementaciones muy simples, ya que con un par de clics (o líneas de código del SDK) se puede implementar un modelo entrenado en una instancia de contenedor Azure o en un contenedor basado en el servicio Azure Kubernetes, con un URI accesible. Esto puede configurarse incluso con claves API o tokens y en entornos seguros. Se puede personalizar aún más configurando una imagen Docker personalizada para casos de uso específicos.
En Azure Databricks hay 3 opciones: sacar el modelo de Spark y ejecutarlo usando AMLS; usar Microsoft ML Spark (MMLSpark) para hacer un servicio web distribuido dentro del clúster de Spark; o usar la API de MLflow para la implementación de modelos.
MMLSpark es un paquete de Microsoft que permite a Spark manejar una carga de trabajo de streaming de datos desde un punto de conexión de la API. Este proceso es ideal para datos complejos que hay que procesar antes de ejecutarlos a través de un modelo entrenado.
AMLS es sencillo de integrar en los pipelines de CI/CD, ya que permite testear en sistemas sencillos con test unitarios y de integración sin necesidad de entornos especiales.
Databricks requiere una conexión al clúster para poder ejecutar los test de integración, lo que complica la gestión de los entornos de prueba, así como la depuración del software en IDE locales del programador; y puede resultar inconveniente para los desarrolladores.
Databricks tiene una curva de aprendizaje más alta que Azure ML; por lo tanto, es más recomendable si los datos y algoritmos son tan grandes como para tener que distribuirlos en el clúster.
Azure ML es mejor para modelos pequeños y medianos y especialmente para desarrolladores con experiencia en Python, ya que se programa en Python en local y se puede lanzar el entorno en un pipeline sin problema.
Databricks, en cambio, requiere utilizar sus propias bibliotecas (diseñadas especialmente para usarlas en Spark) y conocer el funcionamiento del clúster para aprovechar toda su capacidad y distribuir el cálculo por todo el clúster.
En general, si el conjunto de datos es pequeño o mediano, AMLS es la mejor opción. Si el tamaño de los datos es muy grande (no entra en la RAM PC de entrenamiento o procesado), Databricks es la más adecuada. Cuando el tamaño de los datos puede caber en una sola máquina escalada usando un marco de datos de pandas, sería totalmente inadecuado usar Azure Databricks.
La opción más adecuada es una combinación de ambos, ya que el procesamiento de los datos masivos se puede realizar en Databricks y los entrenamientos en AML, de forma que Azure ML lleva la gestión del ciclo de vida; y Databricks se encarga del procesado de datos. AMLS actualiza frecuentemente todo el proceso MLOps, por lo que siguiendo el ritmo de actualizaciones de Azure ML se consigue actualizar todo el proceso MLOps en paralelo.
En definitiva, se puede utilizar AMLS mediante recursos de código abierto como MLflow, cuyo uso es más sencillo, pero en realidad es una herramienta restringida, ya que no permite emplear algunas bibliotecas de código abierto. Por el contrario, herramientas propietarias como Azure ML tienen mayor potencial, ya que permiten acceder a bibliotecas de código abierto no tan conocidas que pueden resultar muy útiles.
