¿Qué Tipo de Cómputo Debo Usar en mi Proceso? ¿Job, Pool o Interactive?

En este post hablaremos sobre los diferentes tipos de cómputos disponibles en Databricks, sus características, ventajas e inconvenientes, además de comentar consideraciones importantes que tener en cuenta a la hora de elegir el tipo de cómputo para tu proceso.

 

¡Comenzamos!

Al configurar la ejecución de un proceso de carga de datos en Azure Databricks, ya sea orquestándolo con workflows o mediante herramientas como Azure Data Factory o Azure Synapse Analytics, debemos tomar una de las primeras decisiones: ¿qué clúster será responsable de ejecutar el proceso? Aunque pueda parecer trivial, en este artículo exploraremos cómo esta elección afecta significativamente tanto al costo como al tiempo de ejecución.

Los procesos de extracción, transformación y carga (ETL) son un paso fundamental en el mundo de la analítica de datos, y en esa línea Databricks nos facilita una plataforma unificada en la cual podemos implementar procesos completos de ETL, pero también nos permite ejecutar cuadernos para realizar partes específicas del proceso. Esa característica nos permite, por ejemplo, tener un proceso orquestado por una herramienta como Azure Data Factory que tiene más de 140 conectores de datos diferentes, lo que es una ventaja a la hora de realizar la E de la ETL, y usar Azure Databricks para la T y la L.

 

Al configurar un flujo de trabajo en Databricks, o la ejecución de un cuaderno desde Data Factory, una de las primeras configuraciones que tenemos que definir es qué clúster vamos a usar para ejecutar el proceso. Antes mismo de configurar el tamaño (capacidad y memoria) del clúster, debemos elegir entre los diferentes tipos de cómputo disponibles, donde cada uno está pensado para un tipo de uso y tiene un costo por DBU asociado. Esa definición puede marcar la diferencia a la hora de pagar la factura.

 

A continuación, describimos los diferentes tipos de cómputos, para qué está pensado cada uno y comentaremos una serie de pruebas que hemos realizado de cara a ayudar en la selección del tipo de cómputo.

Actualmente, en Azure Databricks existen cuatro tipos de cómputo que nos permiten ejecutar tareas específicas.

Cómputo Interactivo:

Los clústeres interactivos son cómputos que se pueden encender y apagar bajo demanda, y podemos pensar en él como un recurso computacional genérico. Es el tipo de cómputo con mayor versatilidad, pero también el más costoso. Se recomiendan para uso interactivo y colaborativo mediante cuadernos (notebooks). Se pueden crear, reiniciar y finalizar, siempre y cuando tengas los permisos adecuados. Además, se pueden ejecutar códigos en Python, R, Scala y SQL.

Cómputo de trabajos:

Este tipo de cómputo está bastante centrado en uso en entornos productivos, donde su uso es recomendado para ejecutar de manera rápida y robusta tareas automatizadas. Este cómputo se crea exclusivamente para ejecutar la tarea, y se elimina al terminarla. Es el tipo de cómputo más barato, pero no se puede usar durante análisis exploratorias, ni tampoco compartirlo entre diferentes flujos de trabajo, pero es posible compartir el recurso entre diferentes tareas dentro del mismo flujo.

Pools:

Son grupos de instancias inactivas listas para usar. Se puede configurar la cantidad mínima de instancias inactivas y la idea principal es reducir el tiempo de inicio de procesos. Al configurar un pool, podemos aprovisionar de manera rápida recursos para que cuando llegue una nueva carga de trabajo no se tenga que esperar hasta que se encienda un nuevo clúster. Es un recurso más barato que el interactivo y más caro que el cómputo de trabajo, pero debemos tener en mente que estamos manteniendo un recurso ocioso.

Almacenes de SQL:

Existen dos formas de Almacenes de SQL, el clásico y el serverless. Ambos están pensados para ejecutar comandos SQL, y solo SQL. Tienen como característica un tiempo de encendido reducido, en el caso del serverless es casi instantáneo. El serverless es un recurso que está alojado dentro de la cuenta de Databricks, y no en la cuenta de Azure como los demás cómputos. Eso tiene implicaciones a nivel de seguridad y conectividad, que se deben gestionar.

 

Para valorar esos diferentes tipos de cómputo y sus implicaciones en el proceso, hemos llevado a cabo un experimento que consiste en la carga de cuatro entidades, simulando un escenario común de lectura de archivos parquet y escritura en tablas delta.  Estas entidades serían geoCountries, de 246 filas, geoPostalCodes, de 1.423.768 filas, personAcademicLevel, de 6 filas, y salesSalesLines, de 52.722.451 filas. Se ejecutaron ocho veces para cada tipo de cómputo. En el caso del interactivo, cuatro ejecuciones partieron con el clúster apagado y cuatro con el clúster ya encendido (simulando el caso de que otro proceso lo había usado anteriormente).

La ejecución de dicha carga se configuró tanto desde Data Factory, con un pipeline compuesto por un bucle que ejecuta la carga de las cuatro tablas de forma paralela, como desde Databricks con flujos de trabajo, con una tarea por tabla, con las cuatro tareas ejecutándose en paralelo.

Para todas las ejecuciones hemos utilizamos clústeres con las configuraciones que se ven abajo. En todos los casos la cantidad de DBUs es la misma, 1,5DBU/h. En el caso del clúster interactivo, está configurado para apagarse automáticamente tras 10 minutos de inactividad (valor mínimo). Con el objetivo de acotar el análisis, no se llevaron a cabo experimentos con Almacenes de SQL ni pools. En el momento que los experimentos fueron ejecutados, el coste informado era de €0,508 / DBU/h para el cómputo interactivo y €0,278 / DBU/h para el cómputo de trabajo, ya que todos los experimentos se ejecutaron en un área de trabajo Premium.

Las ejecuciones que usan el cómputo interactivo tienen un costo más elevado no solo por su coste por DBU, pero también porque el clúster queda encendido por 10 minutos tras el fin del proceso.

Para el cómputo interactivo ejecutado desde ADF, hemos obtenido un tiempo medio de ejecución de 1:55, en los casos que el clúster ya estaba encendido y 7:16 en los casos en los que hubo que encender el clúster antes de ejecutar el proceso. En un caso coincidió que el clúster estaba en proceso de apagarse cuando se lanzó la carga. En esa ocasión el proceso tardó un total de 11:27. Las ejecuciones conllevaron un coste de 1,38€.

Por otro lado, las ejecuciones desde ADF usando cómputos de trabajo estuvieron bastante constantes, con un tiempo promedio de ejecución de 6:53, pero para cada entidad se levantaba un clúster (cuatro clústeres por carga), implicando un coste de 0,76€, aun así, bastante inferior al interactivo.

En el caso del uso de un clúster interactivo en un flujo de trabajo de databricks ocurre algo parecido que en el uso de este mismo tipo de clúster en ADF en cuanto a tiempos. En esta opción, el tiempo medio con el clúster apagado fue de 6:58 y con el clúster ya encendido fue de 1:38. El coste total de las ejecuciones fue de 1,30€.

Usando cómputos de trabajo en los flujos de trabajo de Databricks se ve una gran diferencia con respecto a la utilización de éste en ADF, por lo comentado anteriormente del número de clústeres levantados. Para este caso, se emplea un tiempo medio de 7:08, y sólo se enciende un clúster que ejecuta todo el proceso paralelizando las tareas internamente. En este caso el coste que conlleva es de 0,12€.

Abajo resumimos los tiempos de ejecución para cada escenario:

Como hemos visto, el uso de cómputos de trabajo puede reducir significativamente el costo del proceso de carga. Además, podemos asignar a cada tarea un tamaño de clúster adecuado, reduciendo aún más el costo del proceso. Sin embargo, es importante tener en cuenta, especialmente si orquestamos el proceso desde herramientas externas, que cada ejecución puede generar un nuevo clúster, lo que afecta tanto al tiempo del proceso como al costo.

Buscar utilizar toda la capacidad disponible de cada clúster, por ejemplo, paralelizando tareas en un mismo clúster, también es algo que tener en cuenta. Sin embargo, eso no es tan sencillo de implementar a partir de herramientas externas como Azure Data Factory o Synapse Analytics, pero sí se puede hacer desde los flujos de trabajo de Databricks.

Por otra parte, es importante destacar que los cómputos interactivos nos permiten someter varios flujos de trabajo al mismo clúster, y éste se encarga de la paralelización (y escalado, si así estuviera configurado). Así logramos una mejor utilización de los recursos. Además, si el clúster ya está activo, no necesitamos esperar a que se encienda para ejecutar la tarea y así reducimos el tiempo de ejecución de los procesos.

Finalmente, queda evidente que un buen análisis de los procesos y un dimensionamiento adecuado de los clústeres pueden generar un ahorro significativo, sobre todo si no existe la presión por la velocidad en el proceso.

https://learn.microsoft.com/es-es/azure/databricks/introduction/

https://www.databricks.com/product/pricing

https://learn.microsoft.com/en-us/azure/databricks/getting-started/overview

https://learn.microsoft.com/es-es/fabric/data-factory/connector-overview

https://learn.microsoft.com/es-es/azure/databricks/workflows/jobs/use-compute

En resumen, dependiendo de las necesidades de tu proceso, el tipo de cómputo a usar puede ser uno u otro. Si hay necesidad de mantener un cómputo activo, se puede valorar el uso de un cómputo interactivo (all-purpose compute) para procesos de carga, pero, por lo general es un recurso más caro y suele ser recomendado para análisis exploratorias y uso compartido entre analistas, ingenieros y científicos de datos. El cómputo de trabajo (job Compute) puede ser la solución más barata, pero es necesario tener en cuenta que se tarda un poco en arrancar el clúster y se pueden generar un número significativo de instancias cuando se hacen llamadas en bucles. Por fin, si la velocidad para ejecutar el proceso es un factor importante, los pools pueden ser una solución atractiva, al tener un coste inferior al cómputo interactivo y posibilitar un arranque del proceso de manera más ágil.