Estrategias de reducción de costes en Databricks

Este artículo se creó con OpenAI O1 – DeepResearch y 4 iteraciones sobre el contenido y los casos de uso. Los prompts utilizados están al final del artículo.

1. Optimización del cómputo

Serverless vs. Cluster Pools vs. Clústeres dedicados

El cómputo serverless en Databricks aprovisiona y escala recursos automáticamente bajo demanda, generando cargos solo cuando hay trabajo en marcha (Serverless vs pool : r/databricks). Este modelo es muy eficiente en coste para cargas intermitentes o a ráfagas, ya que no pagas nada cuando los clústeres están inactivos (Serverless vs pool : r/databricks). También simplifica la gestión (sin dimensionado manual) y escala rápido. Sin embargo, los DBUs (Databricks Units) serverless pueden ser algo más caros por hora de ejecución, así que si tu carga corre casi 24/7, un clúster de larga duración podría salir más barato (Serverless vs pool : r/databricks). En escenarios de uso constante, te puedes beneficiar de precios de VM reservadas en un clúster dedicado, mientras que serverless brilla cuando el uso es esporádico o impredecible (Serverless vs pool : r/databricks). Los SQL warehouses serverless son especialmente útiles para consultas BI a ráfagas: arrancan casi al instante y se autosuspenden cuando están ociosos para ahorrar coste (Databricks Cost Optimization: A Practical Guide | overcast blog). Por ejemplo, Databricks señala que un SQL Warehouse interactivo es “el motor más eficiente en coste” para cargas SQL y viene afinado con Photon para una mejor relación precio/rendimiento (Best practices for cost optimization – Azure Databricks | Microsoft Learn).

Los Cluster Pools mantienen un conjunto de VMs prearrancadas como un “pool caliente” para reducir los tiempos de arranque del clúster y de autoescalado (Best practices for cost optimization – Azure Databricks | Microsoft Learn). La ventaja es principalmente menor latencia: los jobs o notebooks pueden engancharse a un clúster mucho más rápido usando instancias del pool. Esto puede ahorrar coste de forma indirecta al recortar tiempo de espera improductivo (los clústeres empiezan a trabajar antes) y al permitir que clústeres de jobs frecuentes arranquen y paren sin grandes demoras. Importante: Databricks no cobra DBUs por las instancias ociosas que están en el pool (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Solo pagas el coste de la VM en la nube por esos nodos ociosos, no el sobreprecio de Databricks, lo que supone un ahorro por el lado de Databricks (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Aun así, como las VMs están corriendo, sí sigues incurriendo en costes de infraestructura mientras esperan. En esencia, los pools te permiten simular algunos beneficios de serverless usando tu propia flota gestionada (Serverless vs pool : r/databricks): pagas un poco más por tener instancias listas a cambio de escalabilidad instantánea. Es ideal si tienes muchos jobs cortos a lo largo del día. Si los nodos del pool quedan ociosos demasiado tiempo, los costes se acumulan, así que conviene dimensionar bien el pool (o dejarlo a 0 cuando no se use) para equilibrar capacidad de respuesta frente a coste.

Los clústeres dedicados por usuario (es decir, cada data scientist o ingeniero corriendo su propio clúster all-purpose) son lo más sencillo para aislar cargas, pero también lo menos eficiente en coste en muchos casos. Cada clúster así tiene su propio driver y, potencialmente, ejecutores ociosos, lo que lleva a baja utilización global si los usuarios no corren cargas pesadas de forma continua. Además, los clústeres all-purpose interactivos llevan una tarifa de DBU más alta que los clústeres específicos de jobs (Best practices for cost optimization – Azure Databricks | Microsoft Learn): correr notebooks en un clúster personal puede costar bastante más que usar un clúster de job para el mismo trabajo (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Si varios usuarios tienen cada uno un clúster pequeño corriendo, ten en cuenta que estás pagando por N conjuntos separados de infraestructura. A menos que cada usuario sature constantemente su clúster, este enfoque desperdicia recursos. Por ejemplo, 5 usuarios con 5 clústeres pequeños siempre encendidos costarán por lo general más que compartir un único clúster más grande entre 5 usuarios con recursos totales comparables. Recomendación: favorece el cómputo serverless o acotado a jobs para cargas ad hoc y usa pools para jobs repetidos, en lugar de darle a cada usuario un clúster personal de larga vida. Reserva los clústeres dedicados solo para casos especiales (por ejemplo, si una carga concreta necesita librerías únicas o aislamiento de seguridad). Como lo resumió con acierto un experto de Databricks: con los pools pagas por capacidad aun estando ocioso, mientras que con serverless no pagas nada cuando está ocioso (Serverless vs pool : r/databricks). El compromiso clave es control vs. comodidad: los clústeres dedicados dan a cada usuario control total pero a un alto coste por el tiempo ocioso, mientras que serverless/pools mejoran la eficiencia global a costa de algo de control sobre las instancias subyacentes.

Clústeres compartidos para varios usuarios

En lugar de encerrar a cada ingeniero o científico en su propio clúster, muchas veces es viable compartir clústeres para aumentar la utilización. Azure Databricks permite que varios usuarios se enganchen al mismo clúster y hagan análisis interactivo de forma colaborativa (Cost Breakdown of Databricks by job or user – Microsoft Q&A). Al usar un clúster all-purpose compartido para un equipo, reduces el número total de clústeres corriendo (por ejemplo, un clúster sirviendo a 5 usuarios en lugar de 5 clústeres separados). Esto significa menos núcleos ociosos dando vueltas y menos sobrecarga duplicada (te ahorras pagar 5 drivers cuando uno puede servir a todos). En la práctica, un clúster compartido de tamaño medio puede gestionar las cargas de notebooks de varios usuarios, escalando hacia arriba si hace falta para acomodar tareas concurrentes. Este enfoque es eficiente en coste porque Spark puede planificar el trabajo de todos los usuarios sobre el mismo conjunto de nodos, mejorando la utilización global de recursos.

Los compromisos de los clústeres compartidos son la gestionabilidad y el aislamiento de rendimiento. Los usuarios tienen que ponerse de acuerdo en un entorno base (librerías instaladas, configuraciones) en ese clúster. Si el job de un usuario es muy exigente, podría consumir la mayor parte del clúster y ralentizar el trabajo de los demás. Estos problemas se pueden mitigar habilitando fair scheduling en Spark y configurando el autoescalado del clúster con un máximo suficientemente alto para manejar el pico de carga. En nuestra experiencia, tener un clúster para un grupo pequeño (por ejemplo, todos los data scientists) funciona bien en horario laboral: el clúster puede escalar hacia arriba durante una ráfaga de actividad y volver a bajar cuando los usuarios están ociosos. También debería configurarse para autoterminarse fuera de hora, para evitar quedarse ocioso por la noche (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Los clústeres compartidos reducen drásticamente el número de instancias infrautilizadas, a costa de algo de complejidad en la coordinación. Para muchos equipos es un compromiso razonable que produce una reducción directa en las horas de cómputo facturadas. (Varios usuarios sobre un mismo clúster incurren colectivamente en la misma tarifa de DBU que ese único clúster, que suele ser mucho menor que la suma de cada usuario corriendo el suyo.)

Autoescalado e instancias spot para jobs

Para cargas batch o de streaming como el micro-batching con UDFs, apoyarse en el autoescalado y en las instancias spot puede generar ahorros sustanciales:

• Autoescalado: Los clústeres de Databricks se pueden configurar para escalar su número de nodos worker hacia arriba o hacia abajo según la demanda de la carga (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Por ejemplo, podrías configurar un clúster de job con 1–8 workers; si la carga de micro-batch tiene un pico (por ejemplo, llega un batch de entrada grande o una UDF se vuelve más intensiva en CPU), el clúster escalará hasta 8 nodos. Cuando el procesamiento se ralentiza o termina, puede volver al mínimo (incluso 0 para clústeres de job, o 1 para streaming) para no pagar por capacidad ociosa. Así te aseguras de pagar solo por la potencia de cómputo que realmente necesitas, cuando la necesitas (Databricks Cost Optimization: A Practical Guide | overcast blog). Especialmente para cargas variables o a ráfagas, el autoescalado evita el sobreaprovisionamiento. Sin él, podrías dimensionar un clúster para el pico de carga y pagar por ese tamaño incluso en los valles. Con autoescalado, el clúster se ajusta solo, lo que suaviza la utilización y recorta costes en los periodos de baja demanda. Se recomienda habilitar también la autoterminación (por ejemplo, terminar tras 30 minutos de inactividad) para que incluso el clúster mínimo se apague cuando no se usa (Best practices for cost optimization – Azure Databricks | Microsoft Learn). El compromiso es un ligero retardo al escalar hacia arriba (lleva un poco adquirir nuevas VMs), así que cargas muy puntiagudas podrían experimentar pequeñas demoras. En conjunto, el autoescalado es una buena práctica de coste: “asegura que solo pagas por la potencia de cómputo que necesitas” (Databricks Cost Optimization: A Practical Guide | overcast blog), a cambio de algo de control en tiempo real sobre el tamaño del clúster.
• Instancias spot: Las Azure Spot VMs son capacidad de cómputo sobrante ofrecida con grandes descuentos (hasta un 90% más baratas que los precios on-demand) (Azure Spot Instances for Databricks AI | Databricks Blog). Databricks permite usar instancias spot para los nodos worker de un clúster. Esto puede reducir enormemente el coste de correr jobs batch. Por ejemplo, si tu job de micro-batching normalmente necesita 5 VMs estándar, podrías correrlo con 5 VMs spot y potencialmente pagar solo una fracción del precio. Según Databricks, usar Spot VMs para clústeres de Azure Databricks puede ahorrar “hasta un 90% en costes de cómputo” (Azure Spot Instances for Databricks AI | Databricks Blog). La pega es que Azure puede desalojar las instancias spot con poco aviso si necesita la capacidad en otro sitio. Databricks lo mitiga reemplazando automáticamente los nodos spot desalojados por nodos on-demand para garantizar que el job termina (Azure Spot Instances for Databricks AI | Databricks Blog). Aun así, los jobs deben tolerar la pérdida de un worker (Spark reejecutará las tareas perdidas). El procesamiento micro-batch con UDFs idempotentes suele ser un buen candidato para spot, porque si un batch falla o cae un nodo, el stream puede reintentar ese batch. Si la carga es extremadamente sensible a la latencia (por ejemplo, streaming en tiempo real con SLAs ajustados de segundos), las interrupciones de spot podrían ser problemáticas: una guía recomienda evitar spot para cargas en tiempo real o transaccionales donde cualquier interrupción sale cara (Databricks Cost Optimization: A Practical Guide | overcast blog). Pero para la mayoría de jobs ETL, batch o streaming con algo de tolerancia, spot es una gran manera de recortar costes. También puedes usar una estrategia mixta: por ejemplo, correr el 80% de los workers como spot y el 20% como on-demand para equilibrar coste y fiabilidad (Databricks Cost Optimization: A Practical Guide | overcast blog). En la práctica, habilitar una estrategia spot puede significar tiempos de ejecución ocasionalmente algo más largos (cuando ocurre un desalojo), pero enormes ahorros de coste a lo largo del tiempo.
• Combinar autoescalado + spot: Estas funciones encajan muy bien juntas. Podrías configurar un clúster para autoescalar entre 1 y 10 nodos, todos ellos instancias spot. Con carga baja, quizá corre 1 nodo spot; durante un pico, escala a 10 nodos spot. Pagas precios spot por la escala que uses, minimizando el coste en cada paso. Si el clúster necesita escalar rápido, usar un instance pool en conjunto puede ayudar: el pool puede mantener unas pocas VMs spot ociosas listas para engancharse, de modo que el autoescalado no tenga que esperar a que Azure arranque nuevas VMs (Azure Spot Instances for Databricks AI | Databricks Blog). Este enfoque híbrido garantiza que la capacidad llega rápido y barata. El impacto global es que incluso cargas pesadas de UDFs pueden correr de forma eficiente: cuando necesitan más potencia la consiguen (manteniendo así el rendimiento), pero pagas la tarifa más baja posible por esa potencia, y no pagas cuando no se necesita.

En resumen, aprovecha el autoescalado para manejar el throughput variable de los jobs de micro-batching y usa instancias spot para recortar drásticamente el coste por instancia de esos jobs. Estas estrategias se pueden implementar mediante políticas de clúster (forzando autoescalado en los clústeres, prohibiendo clústeres fijos sobredimensionados, etc.) (Best practices for cost optimization – Azure Databricks | Microsoft Learn). El ahorro potencial es significativo: por ejemplo, usar Spot VMs en Databricks ha demostrado ahorrar más de un 34% solo por reducir costes de ejecución en un caso de estudio (Databricks Cost Optimization: A Practical Guide | overcast blog) (y potencialmente mucho más, según el precio y la disponibilidad spot). El compromiso es sobre todo de fiabilidad: mientras tus jobs puedan manejar la naturaleza dinámica (que la mayoría de los jobs batch pueden, con los mecanismos de reintento de Spark), los beneficios de coste superan con creces el inconveniente ocasional.

2. Optimización de la ejecución local y el despliegue

Databricks Asset Bundles para desarrollo local

Los Databricks Asset Bundles (DABs) son una herramienta nueva para facilitar el desarrollo y despliegue de cargas con el rigor de la ingeniería de software. Un Databricks Asset Bundle empaqueta tu código (notebooks, módulos de Python, etc.) junto con la configuración de jobs, clústeres, librerías y otros recursos, todo en un formato estructurado (Develop a job on Azure Databricks using Databricks Asset Bundles – Azure Databricks | Microsoft Learn). En la práctica, un bundle se define mediante ficheros de configuración YAML/JSON y el código de tu proyecto, que juntos describen todo lo necesario para correr un job en Databricks. Usar DABs puede mejorar bastante la eficiencia de coste durante el desarrollo de varias maneras:

• Codificación y testing en local: Con DABs puedes desarrollar código en tu IDE favorito en tu máquina local, incluyendo escribir tests unitarios para tus funciones. El concepto de bundle fomenta tratar notebooks y jobs como artefactos de código que se pueden versionar y testear offline. Así, quienes trabajan con datos pueden iterar en local (lo que no genera coste en la nube) y solo ejecutar en un clúster de Databricks cuando sea necesario. Esto contrasta con el enfoque tradicional de desarrollar directamente en un notebook sobre un clúster (generando costes de nube en cada experimento). Dicho de otro modo, los DABs habilitan un flujo offline-first donde “adoptas buenas prácticas de desarrollo de software” y solo usas la nube para tests de integración y ejecuciones de producción (Simplify your workflow deployment with Databricks Asset Bundles: Part I – Xebia).
• Despliegue eficiente y CI/CD: Los Asset Bundles se integran sin fricción con pipelines de CI/CD (Simplify your workflow deployment with Databricks Asset Bundles: Part I – Xebia). Puedes validar la configuración de un bundle e incluso ejecutarlo en un entorno de staging vía línea de comandos o un job de CI. Por ejemplo, un desarrollador podría desplegar su bundle a un pequeño workspace de desarrollo de Databricks para probarlo, y luego promover el mismo bundle a producción mediante un pipeline automatizado (Simplify your workflow deployment with Databricks Asset Bundles: Part I – Xebia). Esta automatización significa que puedes levantar clústeres de job efímeros para testing y derribarlos automáticamente. Evita clústeres de desarrollo de larga vida. Los despliegues son scriptables y repetibles, así que hay menos adivinanza y menos necesidad de mantener un clúster encendido “por si acaso” alguien necesita reejecutar un notebook. Según el tutorial de Microsoft, los data engineers pueden crear un bundle para un job, validarlo en local y luego desplegarlo y ejecutarlo en el workspace de la nube de forma programática (Develop a job on Azure Databricks using Databricks Asset Bundles – Azure Databricks | Microsoft Learn) (Develop a job on Azure Databricks using Databricks Asset Bundles – Azure Databricks | Microsoft Learn). Al hacerlo, solo incurres en costes de nube durante la ejecución real del job: todo el empaquetado y la validación se pueden hacer en local. Esto puede traducirse en ahorros importantes con el tiempo, sobre todo si tu equipo antes hacía muchos retoques interactivos en clústeres.
• Bundle de librerías y configuración: Otro beneficio es que los Asset Bundles encapsulan las dependencias de librerías y la preparación del entorno. Esto reduce la necesidad de configurar manualmente clústeres interactivos para desarrollo. Por ejemplo, si tu job necesita ciertos paquetes de Python, se pueden definir en el bundle. Los desarrolladores pueden probar ese entorno en local (con herramientas como venv o Conda) y tener la confianza de que, cuando el bundle se despliegue en Databricks, traerá esas dependencias. Esto evita el patrón habitual de “mantengo un clúster encendido con mis librerías instaladas para poder cacharrear”, un patrón que cuesta dinero. En su lugar, despliegas el entorno bajo demanda con el job. En resumen, los DABs promueven una mentalidad de “infraestructura como código” para Databricks, donde levantas recursos solo cuando hacen falta y de forma consistente mediante automatización.

En conjunto, usar Databricks Asset Bundles puede agilizar el paso de desarrollo a producción y minimizar el tiempo usando costosos clústeres interactivos. Los data engineers pueden hacer la mayor parte de su trabajo en local y tratar el runtime de Databricks como un destino de despliegue, no como un cajón de arena de desarrollo. Este enfoque puede requerir una inversión inicial en preparar las configuraciones del bundle y el CI/CD, pero se amortiza al eliminar clústeres de desarrollo manuales y de larga duración. El proceso se puede resumir así: desarrolla en local, despliega a un workspace de desarrollo para testear y luego promueve a producción, todo guiado por el bundle (Simplify your workflow deployment with Databricks Asset Bundles: Part I – Xebia). Esto mantiene el uso de la nube ajustado y con propósito.

Usar cómputo local o híbrido para desarrollo

Otra estrategia para recortar costes es hacer tanto desarrollo y testing como sea posible fuera del clúster (en local o en recursos más baratos) antes de usar cómputo de Databricks. Algunas técnicas y herramientas que lo habilitan:

• Testing de Spark en local: Apache Spark puede correr en modo local en la máquina de un desarrollador (usando un solo nodo o multihilo para paralelismo). Los ingenieros pueden aprovechar esto para testear código Spark sobre muestras pequeñas de datos sin lanzar un clúster. Por ejemplo, PySpark o Spark con master local (spark://local[*]) puede ejecutar el mismo código que correría en un clúster, solo que a menor escala. Este enfoque tiene beneficios de coste claros: aprovechas tu CPU/RAM local (que es gratis) para el desarrollo inicial. Como señala un blog, montar Spark en local aporta “varios beneficios, como ahorro de costes y trabajo aislado” para los desarrolladores (Local Development using Databricks Clusters – Pivotal BI). No manejará grandes volúmenes de datos, pero suele bastar para testear lógica y tests unitarios. Al cazar bugs e iterar el código en local, evitas malgastar tiempo de clúster. Muchos equipos lo combinan con pequeños ficheros de datos de prueba en su portátil o en una VM de desarrollo.
• Databricks Connect: Databricks Connect es una librería cliente que te permite escribir código Spark en tu máquina local y ejecutarlo contra un clúster remoto de Databricks. Esencialmente conecta tu sesión Spark local con el backend Spark del clúster de Databricks (Local Development using Databricks Clusters – Pivotal BI). Esto puede considerarse un enfoque híbrido: codificas y haces algo de procesamiento en local, pero las operaciones pesadas ocurren en el clúster. El beneficio es que puedes desarrollar en un IDE con un entorno local, y solo cuando disparas una acción se usan los recursos del clúster. Quizá no reduzca directamente el uso del clúster frente a trabajar en un notebook (ya que el clúster sigue corriendo el job), pero permite compartir un clúster entre varios desarrolladores o tests. Por ejemplo, un ingeniero puede conectarse a un gran clúster de desarrollo compartido, correr unos tests y desconectar, todo sin el lío de gestionar notebooks en el workspace. Hay que asegurar que las versiones de Spark locales y del clúster sean compatibles (Local Development using Databricks Clusters – Pivotal BI), lo cual es una pega conocida, pero aun así mejora la productividad. El ángulo de coste aquí es que podrías mantener un único clúster pequeño siempre encendido para dev/testing al que todos se conectan, en lugar de que cada desarrollador corra el suyo. Es una forma de consolidación habilitada por la conexión remota. No obstante, con la llegada de los Asset Bundles y la mejora de la experiencia de notebooks, Databricks Connect se enfatiza menos ahora que antes (era útil sobre todo antes de DBR 13). Aun así, es una opción en ciertos escenarios.
• Clústeres de un solo nodo (efímeros): Si de verdad necesitas usar Databricks para desarrollo (por ejemplo, para acceder a grandes datos o a un entorno específico), considera usar un clúster pequeño de un solo nodo o, al menos, mínimo. Databricks permite clústeres con cero workers (solo un nodo driver que hace todo el trabajo). Esto es, en la práctica, como correr Spark en un nodo en la nube. Para muchas tareas de desarrollo, un solo nodo (con 8–16 núcleos y algo de RAM) basta y es mucho más barato que un clúster multinodo. También evita la sobrecarga de shuffles distribuidos para cargas pequeñas. De hecho, Databricks recomienda usar un clúster de un solo nodo para experimentos iniciales en algunos casos, porque “tener menos nodos” puede simplificar las cosas (y reducir la sobrecarga) (Compute configuration recommendations – Azure Databricks | Microsoft Learn). Por ejemplo, un data scientist explorando un nuevo dataset podría enganchar su notebook a un clúster de un solo nodo que se autotermine en 30 minutos. El coste podría ser, digamos, 1 nodo * 30 min de uso, en lugar de 4 nodos * varias horas si tuviera un clúster más grande sentado ocioso. Una vez que el código funciona y hay que correrlo sobre el dataset completo, puedes cambiar a un clúster mayor o a una ejecución de job. Automatizar el arranque de estos pequeños clústeres (posiblemente vía APIs o CLI) bajo demanda puede integrar esto en el flujo de trabajo para no mantener ni siquiera el nodo único más tiempo del necesario.
• Aprovechar capas gratuitas o de bajo coste: Si encaja, podrías usar la Community Edition de Databricks para parte del desarrollo. La Community Edition es un workspace gratuito de Databricks con un pequeño clúster de 15 GB disponible (Databricks Community Edition FAQ). Tiene limitaciones (Spark 3.x, potencia de cómputo limitada, sin integración real de datos con tu almacenamiento de Azure), así que no es una opción para la mayoría de flujos profesionales. Pero para pura experimentación con la API de Spark o aprendizaje, es un entorno de coste cero. En la mayoría de los entornos de equipo, un enfoque mejor es tener una suscripción de dev/test en Azure con un workspace de Databricks más pequeño que solo esté activo en horario laboral.

En resumen, prioriza la ejecución local siempre que puedas: depura la lógica de tus UDFs en una sesión Spark local, corre tests unitarios sobre tus funciones fuera de Spark y usa un clúster solo para escalar o para tests de integración. Cuando sí necesites un clúster, usa el recurso más pequeño que haga el trabajo (y asegúrate de que se apaga solo cuando está ocioso). Al reducir el tiempo en grandes clústeres interactivos para desarrollo, hay equipos que han visto reducciones de coste significativas. Un equipo contó que movió gran parte de su trabajo de desarrollo fuera de los notebooks de Databricks, usando un IDE local con dbx (un SDK similar a los Asset Bundles), y desplegando a un clúster de job efímero solo cuando estaba listo: esto eliminó por completo la necesidad de clústeres de desarrollo de larga vida, recortando sus costes de cómputo interactivo a casi cero (más allá de las ejecuciones reales de jobs). El compromiso aquí es que montar entornos locales y pipelines de CI requiere esfuerzo, y los desarrolladores necesitan la disciplina de no caer en el “tira del clúster grande porque está ahí”. Pero con herramientas modernas, la experiencia de desarrollo puede seguir siendo fluida a la vez que se sigue este modelo eficiente en coste.

3. Optimización rentable de instancias y almacenamiento

Mejores tipos de instancia para cargas de micro-batching

Elegir el tipo de VM adecuado para tus clústeres de Azure Databricks es crucial para la optimización de costes. Distintas cargas se benefician de distintos perfiles de hardware, y elegir una instancia rentable puede ahorrar dinero sin dejar de cumplir las necesidades de rendimiento:

• Propósito general vs. optimizadas para cómputo: Las cargas de micro-batching (pequeños batches de datos procesados con frecuencia, a menudo con UDFs limitadas por CPU) suelen beneficiarse de mayor throughput de CPU más que de una memoria enorme. Para esos jobs, las instancias optimizadas para cómputo (con más vCPUs por unidad de memoria) pueden ofrecer mejor relación precio/rendimiento. En Azure, familias como la serie Fsv2 ofrecen frecuencias de reloj de CPU altas y una alta proporción núcleos-a-memoria a menor coste; pueden ser ideales si tus UDFs son intensivas en cálculo pero no requieren cargar datasets enormes en RAM. Las VMs de propósito general (por ejemplo, las series Dv3/Dv4) son una elección equilibrada si necesitas una mezcla de CPU y memoria decentes. Tienden a ser rentables para un amplio rango de cargas y suelen considerarse opciones por defecto “eficientes en coste” (Best practices for cost optimization – Azure Databricks | Microsoft Learn). En cambio, las instancias optimizadas para memoria (por ejemplo, Ev4, con mucha RAM por núcleo) podrían ser excesivas para micro-batches salvo que estés haciendo algo como ventanas o agregaciones que necesiten gran estado en memoria. Como los nodos optimizados para memoria son más caros, deberías usarlos solo si has identificado la memoria como el cuello de botella. Empieza siempre con el tamaño de instancia más pequeño que pueda manejar la huella de memoria de tu carga y escala hacia fuera desde ahí, en lugar de usar unos pocos nodos enormes medio vacíos.
• Evita hardware premium innecesario: Mantente lejos de instancias especializadas caras salvo que tu carga las requiera de verdad. Por ejemplo, las instancias con GPU son bastante más costosas y solo benefician a tareas específicas (como el entrenamiento de deep learning). La inmensa mayoría de los jobs de Spark (ETL, SQL, UDFs) no usan GPUs en absoluto, así que usar una VM con GPU sería tirar el dinero (Best practices for cost optimization – Azure Databricks | Microsoft Learn). La documentación de Azure Databricks aconseja explícitamente restringir las máquinas con GPU salvo que sepas que las necesitas (Best practices for cost optimization – Azure Databricks | Microsoft Learn). La misma lógica aplica a otras VMs especializadas: por ejemplo, VMs de muchísima memoria (como la serie M con cientos de GB de RAM) o VMs muy intensivas en IO (serie Ls con discos NVMe) deberían elegirse solo si tus jobs hacen cuello de botella en esos recursos. Si tu job de micro-batch es mayormente limitado por CPU, una VM F-series de 8 núcleos a ~$X/hora es más económica que una E-series de 8 núcleos a ~$X*1.5/hora que incluye memoria extra que no aprovecharás del todo. Las políticas de clúster se pueden usar para forzar esto, permitiendo solo ciertos tipos de instancia para los clústeres de usuario (asegurando que nadie seleccione por accidente un tipo de VM muy costoso) (Best practices for cost optimization – Azure Databricks | Microsoft Learn).
• Escalar hacia arriba vs. escalar hacia fuera: A menudo surge la duda de usar unos pocos nodos grandes vs. muchos nodos pequeños para la misma potencia total de cómputo. Por ejemplo, 8 workers de 4 núcleos cada uno vs. 2 workers de 16 núcleos cada uno (ambos dan 32 núcleos en total). El coste puro podría ser similar si el precio por núcleo/hora es lineal, pero el rendimiento puede diferir por las sobrecargas (más nodos significan más sobrecarga de shuffle por red, pero también más paralelismo para I/O). Para micro-batching, que normalmente procesa datos en pequeños trozos rápidamente, tener demasiados nodos puede llevar a rendimientos decrecientes: el batch podría ser tan pequeño que la sobrecarga de coordinar muchos ejecutores supere el beneficio. En esos casos, usar nodos moderadamente más grandes (por ejemplo, 4–8 núcleos cada uno) puede reducir el coste de coordinación. Databricks señala que dos workers más grandes vs. varios más pequeños pueden tener los mismos recursos brutos (Compute configuration recommendations – Azure Databricks | Microsoft Learn), así que se trata de encontrar el punto dulce. Una buena práctica es experimentar con el dimensionado del clúster: corre tu carga sobre distintas formas de clúster (1 nodo grande, pocos nodos medianos, muchos nodos pequeños) y observa el tiempo de ejecución y el coste. A menudo, un clúster más pequeño que justo encaje con el batch será el más eficiente en coste, porque el job termina rápido y el clúster puede apagarse antes. Considera también que Databricks cobra DBUs según el tamaño/tipo de instancia del nodo: por ejemplo, una VM de muy alta gama podría costar más DBUs por hora. Las familias eficientes en coste en Azure (como Dv3, Fsv2) suelen tener una valoración de coste de DBU menor que las VMs extremadamente grandes o especializadas.
• Aprovecha generaciones más nuevas y spot: Las nuevas generaciones de VM (Dv5, Ev5, etc.) suelen ofrecer mejor rendimiento a un precio similar o menor que las anteriores. Si están disponibles en Databricks, prefiere las instancias de última generación, ya que hacen más trabajo por dólar (por ejemplo, la serie Ebdsv5 puede tener un 300% mejor rendimiento de disco que la generación previa al mismo coste (Virtual Machine series | Microsoft Azure), lo que significa I/O más rápido por el mismo precio). Además, recuerda que puedes combinar la selección de instancia con precios spot como ya comentamos. Por ejemplo, correr instancias Fsv2 spot podría ser el camino más barato si tu carga lo tolera. Un usuario contó que pasar de tipos de instancia caros a una mezcla de instancias más rentables más spot ahorró mucho a su equipo: “dejamos de usar máquinas [premium] i3 y en su lugar usamos … instancias spot” y forzaron clústeres más pequeños, combinado con autoterminación agresiva (How did you reduce your Databricks costs ? : r/dataengineering) (How did you reduce your Databricks costs ? : r/dataengineering). Aunque ese ejemplo era específico de AWS, el principio se mantiene: evita familias de instancias caras y usa opciones de precios con descuento siempre que puedas.

En resumen, optimiza la configuración de tu clúster usando tipos de instancia que encajen con el perfil de tu carga sin sobreaprovisionar recursos que no usas. Usa políticas de clúster o guías para asegurar que solo se seleccionan “instancias de VM eficientes en coste” (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Un enfoque práctico es: empieza con una instancia DSv2/DSv3 o FSv2 estándar para la mayoría de los jobs, monitoriza el uso de CPU, memoria e I/O del job, y ajusta si hace falta (sube el tamaño de instancia si llegas al 100% de CPU o a límites de memoria, o escala hacia fuera si la CPU está baja pero el job va lento, indicando falta de paralelismo). Haciendo esto, a menudo puedes recortar el coste de cómputo de un pipeline en un 20-30% solo eliminando desperdicio (por ejemplo, encontramos un job corriendo en máquinas enormes con un 10% de uso de CPU; moverlo a máquinas más pequeñas y más paralelismo recortó el coste drásticamente con el mismo rendimiento).

Optimizar los costes de almacenamiento (Delta Lake y Azure Blob)

El almacenamiento quizá no sea la mayor partida comparado con el cómputo, pero un almacenamiento ineficiente lleva directamente a mayores costes de cómputo (escanear más datos, esperar al I/O) y puede inflar tu factura de la nube si no se gestiona. Dos aspectos clave aquí son el formato/gestión de datos (Delta Lake) y la capa de almacenamiento en la nube (Azure Blob Storage):

• Usa Delta Lake para almacenamiento e IO eficientes: Guardar tus datos en formato Delta Lake (que es una capa optimizada sobre Parquet) es muy recomendable para las cargas de Databricks. Delta Lake aporta mejoras de rendimiento como data skipping, compactación de ficheros y evolución de esquema, que hacen las lecturas y escrituras mucho más eficientes que los formatos en crudo (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Microsoft destaca que Delta Lake “acelera significativamente las cargas comparado con usar Parquet, ORC y JSON”, lo que se traduce directamente en menor tiempo de cómputo encendido y menores costes para tus jobs (Best practices for cost optimization – Azure Databricks | Microsoft Learn). En la práctica, los beneficios de Delta hacen que tus jobs de ETL o consulta terminen más rápido (porque se leen y escriben menos datos), de modo que el clúster puede terminarse antes y ahorrar dinero. Algunas formas concretas en que Delta ayuda:
  • Compactación de ficheros pequeños: Muchos pipelines de big data producen montones de ficheros pequeños (por ejemplo, cada micro-batch escribe un fichero). Leer miles de ficheros diminutos es ineficiente y aumenta la sobrecarga por consulta. Delta Lake puede combinarlos automáticamente en ficheros más grandes, o puedes correr periódicamente el comando OPTIMIZE para fundir ficheros pequeños en bloques de, digamos, 256 MB. Esto mejora el throughput de Spark y baja la sobrecarga de CPU. Gestionar el tamaño de los ficheros en Delta es “clave para impulsar el rendimiento y recortar costes”: demasiados ficheros pequeños llevan a un manejo excesivo de metadatos y a consultas lentas (Databricks Cost Optimization: A Practical Guide | overcast blog). Optimizando el tamaño de fichero, te aseguras de que cada tarea hace trabajo significativo, reduciendo así el tiempo total de ejecución. Es habitual ver aceleraciones drásticas (y, por tanto, caídas de coste) tras compactar una tabla que tenía un problema de ficheros pequeños.
  • Data skipping e indexado: Delta Lake mantiene logs de transacciones y estadísticas sobre los datos (como valores mín/máx por columna y por fichero). Esto permite a Databricks saltarse la lectura de ficheros que no coinciden con el filtro de una consulta, por ejemplo. Menos datos leídos = menos IO y cómputo. Técnicas como el Z-Ordering (agrupar los datos en disco por una clave) potencian esto aún más. Al agrupar los ficheros por claves de consulta comunes, Delta puede saltarse todavía más datos. El resultado son consultas más rápidas, lo que significa que puedes usar un clúster más pequeño o terminar antes, ahorrando DBUs. Se señala que usar las optimizaciones de Delta (como z-order, data skipping) “reduce el coste de las consultas minimizando la cantidad de datos leídos” (Databricks Cost Optimization: A Practical Guide | overcast blog).
  • Concurrencia y fiabilidad: Las propiedades ACID de Delta reducen la probabilidad de fallos en los jobs por datos inconsistentes (sin ficheros a medio escribir, etc.). Esto significa que es menos probable que tengas que reejecutar jobs por problemas de datos, ahorrando coste indirectamente al evitar reejecuciones malgastadas. Además, varios jobs pueden leer/escribir Delta de forma concurrente, lo que puede eliminar la necesidad de copias duplicadas de datos para distintos flujos (ahorrando espacio de almacenamiento).
  • Time Travel vs. duplicación de datos: La función de time travel de Delta (mantener el historial de cambios) también puede ahorrar coste: puede reducir la necesidad de mantener copias completas de snapshots para backups o auditorías. En lugar de almacenar N versiones de un dataset en directorios separados (y pagar por N× almacenamiento), mantienes una sola tabla Delta con histórico de versiones. Acceder a datos antiguos sigue siendo posible sin la sobrecarga de mantener múltiples datasets (Databricks Cost Optimization: A Practical Guide | overcast blog). Solo recuerda hacer vacuum del histórico antiguo que de verdad no necesites, para liberar almacenamiento.
  En resumen: invierte en la optimización de Delta Lake. El coste inicial de correr periódicamente comandos OPTIMIZE o ZORDER se compensa fácilmente con el ahorro posterior en costes de consulta. Por ejemplo, podrías programar un job de compactación semanal (que en sí cuesta algo de cómputo), pero entonces todas las consultas diarias corren 2x más rápido y, por tanto, usan la mitad del tiempo de clúster: el efecto neto es una reducción de coste. Usar Delta para todas las tablas importantes también simplifica el diseño del pipeline y reduce el esfuerzo de desarrollo (que tiene su propio tipo de coste).
• Optimiza el uso de Azure Blob Storage: Azure Databricks usa Azure Blob Storage (a menudo vía ADLS Gen2) para almacenar datos (por ejemplo, la raíz de DBFS y los puntos de montaje). Para reducir los costes de almacenamiento, considera lo siguiente:
  • Tiering de datos: Azure Blob ofrece capas de acceso Hot, Cool y Archive. La capa Hot es para datos de acceso frecuente y tiene el mayor coste de almacenamiento (pero el menor coste de acceso), mientras que las capas Cool y Archive tienen almacenamiento más barato pero mayores costes de lectura y restricciones (por ejemplo, los datos deberían permanecer 30+ días en cool, 180+ en archive) (Azure Cost Optimisation: 12 Quick Tips for a Lower Bill). Para datos a los que no accedes a menudo (logs antiguos, datos crudos históricos, checkpoints viejos), muévelos a almacenamiento cool o archive. Puedes ahorrar bastante al no pagar tarifas de almacenamiento hot por datos fríos: “ahorra muchísimo alineando los tipos de almacenamiento con tu uso real” (Azure Cost Optimisation: 12 Quick Tips for a Lower Bill). Implementa reglas de gestión del ciclo de vida para transicionar blobs a capas más frías automáticamente tras cierta antigüedad. Por ejemplo, guarda los últimos 30 días de datos en Hot, los siguientes 90 días en Cool y todo lo más antiguo en Archive. Así, solo pagas premium por los datos que estás usando activamente. Muchas empresas descubren que la mayoría de sus datos son “fríos” y se pueden almacenar barato si se gestionan bien.
  • Disposición eficiente de los datos: Organiza tus datos en ficheros más grandes y directorios particionados. Esto enlaza con la optimización de Delta: ficheros más grandes reducen la sobrecarga, y particionar (por fecha, por ejemplo) significa que cuando lees un día de datos, no tocas todos los demás días. Una disposición eficiente significa menos bytes totales escaneados del almacenamiento, lo que no solo acelera los jobs sino que también reduce cualquier coste de transacción u operaciones de lectura sobre la cuenta de almacenamiento. Aunque el modelo de coste de almacenamiento de Azure es mayormente por capacidad, transacciones (llamadas) muy frecuentes pueden incurrir en costes; usar partition pruning (listar solo las carpetas relevantes) lo mitiga.
  • Compresión: Asegúrate de que los datos se almacenan en forma comprimida (Parquet y Delta están comprimidos por defecto usando codecs como Snappy). Los datos comprimidos consumen menos espacio en Blob y también significan que hay que leer menos datos en la memoria del clúster. Solo ten cuidado de no usar una compresión demasiado lenta que queme CPU; Snappy suele ser un buen equilibrio. Una huella de almacenamiento menor es, directamente, menor coste de almacenamiento.
  • Evita copias redundantes: Es fácil dejar que los datos se desparramen (por ejemplo, varias personas haciendo copias de la misma tabla para sus experimentos). Fomenta el uso del time travel de Delta o de los shallow clones en lugar de duplicados completos cuando sea posible. O usa control de versiones en el lake (por ejemplo, particiones para distintas versiones de datos) en lugar de copiar datos a rutas nuevas. Cada copia extra duplica los costes de almacenamiento y puede duplicar el cómputo necesario para actualizar o corregir datos. Limpiando datos sin usar y consolidando duplicados, a menudo puedes recortar tus costes de almacenamiento.
  • Elecciones de geo-redundancia: Las cuentas de almacenamiento de Azure pueden ser LRS (redundancia local), ZRS/GRS (redundancia de zona o geográfica). Mayor redundancia aumenta el coste. Para datos de no-producción o recreables (como salidas intermedias de análisis), podrías elegir LRS para recortar coste. Usa GRS solo para datos críticos que necesiten recuperación ante desastres entre regiones. Esto no es un ajuste de Databricks per se, sino parte de la configuración de almacenamiento de Azure que puede afectar al coste de forma significativa.
• Caching y patrones de acceso a datos: Aunque no es un “coste” directo en términos de facturación, usar el caching de Databricks (Delta cache o el comando CACHE de Spark) puede reducir la cantidad de datos leídos desde Blob storage para algoritmos iterativos o consultas repetidas. Esto se traduce en una finalización más rápida y menos tiempo que los clústeres necesitan correr. Por ejemplo, si tus data scientists consultan repetidamente el mismo gran dataset en un notebook, considera cachearlo en memoria en el clúster (si cabe) o usar Delta caching en los SSDs locales de los workers. Así no golpearán el almacenamiento en cada consulta. Este tipo de optimización está a caballo entre el ajuste de rendimiento y el ahorro de coste: en esencia, acelerar los flujos de trabajo es una forma de optimización de coste, porque pagas por menos segundos de cómputo (Databricks Cost Optimization: A Practical Guide | overcast blog) (Databricks Cost Optimization: A Practical Guide | overcast blog).

Para ilustrar el impacto: imagina un dataset de 1 TB almacenado en 10.000 ficheros JSON diminutos vs. los mismos datos en una tabla Delta bien particionada con 200 ficheros grandes, con las particiones más antiguas en almacenamiento cool. El primer escenario podría tardar una hora de cómputo de 10 nodos en leerse y procesarse (y pagas almacenamiento hot caro por 1 TB). El segundo escenario podría tardar 10 minutos de cómputo de 5 nodos en procesarse (porque Delta se saltó un montón de datos irrelevantes y leyó ficheros más grandes de forma eficiente), y pagas quizá 1/3 del coste de almacenamiento por las porciones frías. La diferencia en coste mensual para ese pipeline podría ser enorme. Por tanto, invertir en una gestión adecuada del almacenamiento de datos en Azure puede generar ahorros directos tanto en las facturas de almacenamiento como en las de cómputo.

4. Buenas prácticas y recomendaciones

Juntando las estrategias anteriores, aquí van las recomendaciones clave para un equipo de data engineers (gestionando flujos/jobs) y data scientists (corriendo notebooks), junto con los posibles ahorros y compromisos:

• Dimensiona y elige bien el tipo de tus clústeres: Evita mantener grandes clústeres interactivos encendidos cuando bastaría un clúster de job más pequeño o efímero. Usa clústeres de job (Jobs Compute) para pipelines de producción siempre que puedas, ya que cobran una tarifa de DBU menor que los notebooks all-purpose (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Del mismo modo, prefiere el cómputo serverless para cargas bajo demanda; elimina los costes de tiempo ocioso al correr solo cuando tienes trabajo (Serverless vs pool : r/databricks). Por ejemplo, un ETL nocturno que solía correr en un clúster de 8 nodos siempre encendido podría moverse a un job que se levanta, corre en un clúster una hora y luego se termina, ahorrando todas las horas de cómputo que antes pasaba ocioso. A muchos equipos también les resulta útil servir consultas ad hoc a través de Databricks SQL warehouses en lugar de un clúster Spark general, ya que el SQL warehouse puede autodetenerse cuando no se usa y está optimizado para coste por consulta (Best practices for cost optimization – Azure Databricks | Microsoft Learn) (How did you reduce your Databricks costs ? : r/dataengineering). El compromiso con el cómputo totalmente serverless o acotado a jobs es algo menos de interactividad en tiempo real (podrías esperar ~30 segundos a que arranque un clúster en algunos casos) y tener que gestionar la planificación de jobs, pero el ahorro de consolidar el trabajo y recortar el tiempo ocioso suele compensar de sobra.
• Consolida el uso y elimina recursos ociosos: Siempre que sea factible, haz que los usuarios compartan clústeres o usen workflows multitarea en lugar de clústeres aislados por persona/tarea. Un clúster interactivo compartido con autoescalado puede manejar los notebooks de varios usuarios y se apagará cuando nadie lo use. Esto reduce drásticamente el número de clústeres de baja utilización corriendo a la vez. El testimonio de un usuario fue “hacer un uso agresivo de clústeres de job” y mover a serverless los notebooks (How did you reduce your Databricks costs ? : r/dataengineering): en la práctica, pasaron de muchos clústeres siempre encendidos a principalmente clústeres basados en jobs bajo demanda. El ahorro potencial aquí puede ser del orden del 30-50% si antes cada uno tenía su propio clúster corriendo 8+ horas al día con uso solo esporádico. El compromiso es que los equipos necesitan coordinarse (por ejemplo, que no todos corran jobs pesados exactamente al mismo tiempo en un clúster compartido salvo que pueda escalar para ello), pero con autoescalado y políticas adecuadas, es manejable. Habilita siempre la autoterminación en los clústeres interactivos (por ejemplo, 1 hora o incluso 15 minutos de inactividad) para no pagar por la noche o el fin de semana por algo que alguien olvidó apagar (How did you reduce your Databricks costs ? : r/dataengineering) (Best practices for cost optimization – Azure Databricks | Microsoft Learn).
• Aprovecha las funciones de ahorro (autoescalado, spot, pools): Asegúrate de que el autoescalado está activado para clústeres con cargas variables, para no pagar por la capacidad máxima durante el uso bajo (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Usa instancias spot para cargas no críticas para ahorrar hasta un ~90% en costes de VM (Azure Spot Instances for Databricks AI | Databricks Blog): por ejemplo, un job batch que cuesta 10 $ en VMs on-demand podría costar solo 1-2 $ con spots, aunque con posibles reintentos si se reclama un nodo. Muchos equipos han reportado reducciones sustanciales en costes de procesamiento batch usando spot: una guía señala que es estupendo para jobs de ETL o entrenamiento de ML donde se pueden manejar las interrupciones (Databricks Cost Optimization: A Practical Guide | overcast blog) (Databricks Cost Optimization: A Practical Guide | overcast blog). El compromiso es un ligero golpe a la fiabilidad, pero Databricks lo mitiga recurriendo automáticamente a on-demand si hace falta (Azure Spot Instances for Databricks AI | Databricks Blog). Usar instance pools puede optimizar aún más los costes recortando el tiempo de arranque (es decir, tus jobs pasan más tiempo trabajando y menos esperando) (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Aunque los pools en sí no reducen los costes de VM-hora (sigues pagando por VMs ociosas que llenan el pool), mejoran la eficiencia para flujos de jobs a ráfagas y se pueden combinar con spot (spot pools) para el máximo ahorro. Una buena práctica es analizar los logs de los jobs para encontrar tiempos ociosos o de espera y aplicar estas funciones en consecuencia (Databricks proporciona métricas y system tables para ayudar con esta monitorización (Best practices for cost optimization – Azure Databricks | Microsoft Learn)).
• Optimiza el código y las prácticas de desarrollo: A veces el ahorro de coste viene de mejorar el código en lugar de la infraestructura. Anima a tus data scientists a escribir código eficiente (por ejemplo, usar operaciones vectorizadas o funciones nativas de Spark en lugar de UDFs de Python pesadas cuando sea posible): código más rápido significa menos tiempo de clúster y menos coste para la misma tarea. Usa Photon (el motor optimizado de Databricks) para operaciones SQL y de DataFrame; puede acelerar las cargas de forma significativa, y viene activado por defecto en Serverless SQL y como opción en los clústeres (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Aunque Photon pueda tener una tarifa de DBU algo más alta, si reduce el tiempo de consulta a la mitad, sales ganando en coste. En una discusión de Reddit, un usuario mencionó que evaluó Photon: no ayudó a sus jobs concretos, pero merece la pena probarlo para tu carga (How did you reduce your Databricks costs ? : r/dataengineering). Por el lado del desarrollo, adopta CI/CD y testing en local. Usando herramientas como Databricks Asset Bundles o dbx, puedes correr muchos tests en local o en un entorno ligero, y usar un clúster solo para tests de integración completos y ejecuciones de producción. Esto significa menos experimentos ad hoc en clústeres caros. Un equipo contó que, al mover el desarrollo a un IDE con dbx y usar clústeres de job de vida corta, evitaron por completo el coste de los clústeres interactivos. El compromiso aquí es invertir tiempo en herramientas y posiblemente formar al equipo en nuevos flujos de trabajo, pero se amortiza con un uso más controlado y eficiente de los recursos.
• Almacenamiento y gestión de datos: Trata los datos como ciudadanos de primera clase en la optimización de coste. Particiona y compacta tus datos para que los jobs no malgasten tiempo en I/O excesivo. Usa Delta Lake y haz OPTIMIZE de las tablas con regularidad: esto puede reducir drásticamente los tiempos de consulta (hemos visto 2-3× más rápido en muchos casos tras la compactación), reduciendo directamente las horas de cómputo necesarias. Sí, correr el comando OPTIMIZE en sí tiene un coste, pero piénsalo como pagar una pequeña tarifa de mantenimiento para evitar una gran penalización de rendimiento en cada consulta. Además, archiva los datos fríos en almacenamiento más barato. Si tienes años de logs o tablas de features antiguas a las que los data scientists rara vez acceden, mantén solo los últimos meses en el workspace activo y mueve el resto a almacenamiento Archive (o incluso a un data warehouse de menor coste para almacenamiento a largo plazo). Podrías ahorrar del orden del 50-80% de los costes de almacenamiento de esos datos, aunque con el entendimiento de que recuperarlos es lento (lo cual está bien si se necesitan rara vez). Por último, no pases por alto la gobernanza de costes: implementa etiquetado en los recursos de Databricks (jobs, clústeres) para rastrear qué proyectos consumen qué (Best practices for cost optimization – Azure Databricks | Microsoft Learn). Esto no es un ahorro directo, pero ayuda a identificar puntos calientes que optimizar. Por ejemplo, podrías descubrir que un notebook de machine learning está usando el 60% del coste: esa es una señal para indagar y ver si se puede optimizar o correr en una instancia más barata. Revisa con regularidad los informes de coste (Azure Cost Management o los informes de coste de Databricks) para asegurar que las optimizaciones que implementas dan resultado realmente y para cazar cualquier regresión pronto.

Siguiendo estas buenas prácticas, un equipo de ingeniería de datos y ciencia de datos puede reducir significativamente los costes de Databricks sin dejar de cumplir los requisitos de su carga. En muchos casos, las organizaciones han logrado del orden de un 30-50% de ahorro de costes (o más) eliminando desperdicio (tiempo ocioso, clústeres sobreaprovisionados) y aprovechando opciones de cómputo más baratas (How did you reduce your Databricks costs ? : r/dataengineering) (How did you reduce your Databricks costs ? : r/dataengineering). Los compromisos suelen implicar algo más de planificación y automatización (por ejemplo, montar jobs y planificaciones en lugar de ejecuciones manuales, o coordinar recursos compartidos), pero el beneficio es un uso más sostenible y escalable de Databricks. Recuerda siempre: la optimización de costes es un proceso continuo. Monitoriza el uso de forma constante, experimenta con nuevas funciones (como serverless o tipos de instancia más nuevos) y refina tu enfoque a medida que las cargas evolucionan. Con disciplina y las técnicas descritas arriba, puedes mantener tu entorno de Databricks eficiente y rentable, permitiendo a tu equipo centrarse en las tareas de datos sin reventar el presupuesto.

Fuentes: Buenas prácticas para la optimización de costes en Azure Databricks (Best practices for cost optimization – Azure Databricks | Microsoft Learn) (Best practices for cost optimization – Azure Databricks | Microsoft Learn) (Best practices for cost optimization – Azure Databricks | Microsoft Learn) (Best practices for cost optimization – Azure Databricks | Microsoft Learn); perspectivas de la comunidad y el blog de Databricks sobre pools, serverless e instancias spot (Serverless vs pool : r/databricks) (Serverless vs pool : r/databricks) (Azure Spot Instances for Databricks AI | Databricks Blog) (Azure Spot Instances for Databricks AI | Databricks Blog); recomendaciones sobre compartir clústeres y autoescalado (Cost Breakdown of Databricks by job or user – Microsoft Q&A) (Databricks Cost Optimization: A Practical Guide | overcast blog); guía sobre Databricks Asset Bundles y desarrollo local (Simplify your workflow deployment with Databricks Asset Bundles: Part I – Xebia) (Local Development using Databricks Clusters – Pivotal BI); consejos sobre Delta Lake y optimización del almacenamiento (Databricks Cost Optimization: A Practical Guide | overcast blog) (Azure Cost Optimization: 12 Quick Tips for a Lower Bill).

Prompts y contexto para el LLM

Requisitos:

• La carga se basa en procesamiento batch con una configuración de tipo micro-batching. En la mayoría de los casos el proceso se hace usando UDFs.
• Investigación sobre distintos tipos de optimización de instancias
• El patrón de consumo es mayormente diario durante la noche europea.
• Sin restricción en la instancia, solo intentando explorar e investigar las posibilidades desde serverless hasta VMs dedicadas en Azure. Explorar instancias spot mezcladas con configuración de autoescalado y ver cómo se puede manejar la ejecución del job.
• No solo en cómputo, también explorar la optimización del tamaño de almacenamiento con foco en el almacenamiento en la nube como ADSLv2 (abfs) + dbfs.

Contexto:

El workspace lo usarán data engineers y data scientists. Los data scientists estarán corriendo notebooks la mayor parte del tiempo, mientras que los data engineers se encargarán de los workflows y las ejecuciones de jobs. También es buena idea explorar el uso de Databricks Asset Bundles para correr cosas en local y posiblemente desplegarlas al workspace.

Estas cargas suelen ser las más caras, ya que normalmente hay una instancia personal configurada por cada usuario. Sería estupendo explorar opciones compartidas para estos montajes, o el uso de cómputo local (cómputo no en la nube) para correr cosas durante el desarrollo, incluyendo Databricks Connect. Además, UC (Delta Sharing) se puede usar para descargar subconjuntos de datos para correr tests con los datos almacenados en la instancia.