TL;DR
La optimización de costos en Databricks se reduce a cinco hábitos: saber de dónde viene realmente el costo (el precio por DBU más una factura aparte de infraestructura en la nube), eliminar el cómputo inactivo con auto-terminación y timeouts, dimensionar bien el cómputo usando serverless por defecto y reservando el cómputo clásico para tus workloads más costosos, replantear los workflows en función de la frecuencia de ejecución y el procesamiento incremental, y dejar bien fijada la configuración de almacenamiento y gobernanza para que los avances no se diluyan con el tiempo. Números reales del webinar: un clúster de GPU sin monitoreo sumó $4,000 a una factura mensual de $20,000 antes de que alguien lo notara, y reducir la frecuencia de ejecución de un job de 472 veces al día a una vez por hora ahorró el 95% de su costo, unos $19,000 al año.
Por qué es tan difícil controlar los costos de Databricks
Databricks les da a los equipos de datos una libertad poco común. Puedes ejecutar el mismo pipeline como clúster interactivo, como job programado o como job serverless, en cómputo clásico o serverless, con una docena de tipos de nodo y configuraciones de escalado para elegir. Esa flexibilidad es justamente lo que complica el control de costos. Más opciones significan más formas de configurar algo mal, y las facturas de Databricks no siempre dejan en evidencia cuándo eso ocurre.
Ese fue el punto de partida de un webinar reciente presentado por Ian Whitestone, cofundador de SELECT, y Olivier Soucy, consultor de Databricks que pasó años construyendo plataformas de datos desde cero, incluyendo una etapa como head of data en un exchange de criptomonedas, donde montó un entorno de Databricks desde el primer día. Hoy Soucy dirige su propia consultora enfocada en costo y rendimiento de Databricks, y aprovechó la sesión para repasar cinco estrategias concretas para controlar el gasto en Databricks, cada una respaldada con números reales de proyectos con clientes.
Aquí va un resumen de lo que cubrió.
Empieza por entender a dónde se va realmente el dinero
Antes de optimizar nada, necesitas saber qué es lo que estás pagando, y Databricks lo hace más difícil de lo que debería. El costo proviene de dos lugares distintos: el precio por Databricks Unit (DBU) que cobra el propio Databricks, y el cómputo de nube subyacente que cobran AWS, Azure o GCP por las instancias que Databricks aprovisiona.
El precio por DBU por sí solo puede ser engañoso. Soucy mostró un mismo pipeline de ETL con tres precios distintos: ejecutado como clúster interactivo cuesta 55 centavos por DBU; como job en cómputo clásico, 30 centavos por DBU; como job en serverless, 45 centavos por DBU. Mirando solo el precio por DBU, serverless parece la opción cara. Pero el cómputo clásico también suma una factura aparte de infraestructura en la nube que serverless no tiene, así que el panorama completo suele verse muy distinto cuando se combinan ambos costos.
La mayoría de los equipos nunca los combina. Soucy lo dijo sin rodeos cuando Whitestone preguntó si los clientes rastrean juntos el costo de DBU y el de infraestructura en la nube a nivel de job: normalmente no, porque cada parte está en manos de un equipo distinto. Un equipo de Databricks monitorea las tablas de sistema y los workflows; un equipo de nube mira la factura de AWS o Azure y trata a Databricks como un solo renglón. Unir las dos fuentes de datos con las etiquetas correctas implica suficiente esfuerzo como para que la mayoría de las organizaciones lo omita, incluso sabiendo que importa.
Databricks sí expone tablas de sistema con datos de uso y precios, lo que alcanza para construir un modelo de costos razonablemente preciso del gasto en DBU. Para el cómputo clásico (no serverless), la regla práctica de Soucy es asumir que el costo de infraestructura en la nube subyacente es aproximadamente igual al costo en DBU, así que una factura de $50,000 en DBU suele acercarse a $100,000 una vez sumado el cómputo de nube. Es una estimación a grandes rasgos, y varía mucho con workloads de GPU, pero es un punto de partida razonable si todavía no tienes un modelo mejor. Para un desglose más profundo de cómo funcionan realmente los precios de Databricks, SELECT ya cubrió en más detalle los tres controles que más importan.
Elimina la pérdida antes de optimizar cualquier otra cosa
El cómputo inactivo es, en palabras de Soucy, el error más caro que puede cometer un equipo, porque estás pagando por recursos que no aportan ningún valor mientras corren. Compartió dos ejemplos de su propio trabajo con clientes. En un caso, un pasante nuevo levantó un clúster de GPU sin auto-terminación y sin ningún control de por medio. Corrió durante semanas, sumando unos $4,000 a una factura mensual de $20,000, antes de que alguien lo notara. En otro, un job que corría bien en QA en unos 20 minutos se topó con datos distintos en producción y corrió 47 horas antes de que alguien lo detectara.
Las soluciones son simples y vale la pena aplicarlas sin importar nada más de esta lista:
- Configura la auto-terminación en cada clúster y warehouse. Soucy sugirió unos 30 minutos de inactividad para clústeres y 10 minutos para warehouses como valores por defecto razonables, aunque el número exacto importa menos que el hecho de tener uno.
- Activa el auto-escalado para que el cómputo crezca y se reduzca según la demanda real, en lugar de quedar aprovisionado al máximo las 24 horas.
- Define timeouts para jobs y consultas. El timeout por defecto de las sentencias SQL en Databricks es de dos días, un valor que ambos presentadores coincidieron en que es demasiado largo. Whitestone lo dijo directo: si una consulta lleva más de un día corriendo, probablemente no debería seguir corriendo, y vale la pena bajar ese valor por defecto a nivel de cuenta.
- Usa políticas de clúster para hacerlo cumplir. En lugar de confiar en que cada persona recuerde la auto-terminación, las políticas de clúster pueden exigirla a nivel de cuenta.
Dimensiona el cómputo según el trabajo
Con la pérdida bajo control, el siguiente error común es el sobreaprovisionamiento: asignar más cómputo del que un workload necesita. La recomendación por defecto de Soucy, que él mismo reconoce como algo polémica, es usar serverless por defecto salvo que tengas una razón concreta para no hacerlo.
Lo respaldó con el ejemplo del pipeline de ETL por hora de un cliente. En cómputo clásico, el job usaba unos 44 DBU al día a 30 centavos por DBU (cerca de $13 diarios en costo de DBU), más otros $10 diarios en infraestructura de nube, para un total cercano a $23 por día. Al moverlo a serverless, el mismo job usó 38 DBU a un precio por DBU más alto, pero el costo total resultó similar —en este caso, ligeramente menor—, sobre todo porque serverless elimina los dos a cuatro minutos de arranque de clúster que el cómputo clásico paga en cada ejecución. Esa eliminación del arranque también redujo el tiempo total de ejecución del job de 20 a 12 minutos.
El consejo práctico de Soucy: si recién empiezas con Databricks o todavía no has afinado tus workflows, usa serverless en todas partes por defecto, identifica luego los cinco a diez workloads que concentran la mayor parte de tu factura y considera mover solo esos de vuelta a cómputo clásico, donde tienes más palancas para equilibrar costo y rendimiento. El resto normalmente no justifica el tiempo de ajuste. El punto de inflexión suele ser la duración del workload: los jobs que corren durante horas seguidas tienen más probabilidades de beneficiarse del cómputo clásico, donde puedes ajustar directamente el tipo de nodo, el autoescalado y la cantidad de workers.
Para el cómputo clásico, Soucy recomienda comenzar con el tamaño de instancia más pequeño disponible y escalar solo cuando aparezcan cuellos de botella reales, usando métricas del Spark UI como la utilización de CPU y de nodos para guiar la decisión. Empezar demasiado grande tiende a producir lo que él llamó una "factura silenciosa": sin errores, sin fallas, solo un costo consistentemente más alto de lo necesario. También conviene alinear el tipo de cómputo con el workload. El trabajo puramente SQL va en SQL warehouses, la lógica general de jobs va en cómputo de jobs, y los clústeres interactivos o de propósito general deberían reservarse para trabajo realmente interactivo. Whitestone comentó que este es uno de los tropiezos más comunes que ve SELECT: ejecutar un job programado contra un clúster interactivo en lugar de un clúster de jobs dedicado puede casi duplicar el costo en Databricks de ese job sin ningún beneficio.
Replantea el workflow en sí
Más allá del dimensionamiento del cómputo, varios cambios en la forma de construir los pipelines destacaron entre las optimizaciones de mayor impacto disponibles.
La frecuencia de ejecución pesa más de lo que la mayoría de los equipos asume. Tomando una actualización diaria como línea base, pasar a ejecuciones por hora multiplica el costo por cinco aproximadamente, y las actualizaciones casi en tiempo real cuestan alrededor de 60 veces más. El consejo de Soucy es cuestionar los requisitos de tiempo real o casi tiempo real de los stakeholders del negocio, ya que la mayoría de los pedidos de dashboards "en tiempo real" en realidad solo significan que el reporte debe reflejar un momento específico, no un flujo continuo.
Usa vistas en lugar de duplicar tablas. Para filtros simples o selecciones de columnas, crear una vista en lugar de una nueva tabla física evita copiar datos y el costo continuo de mantener esa copia, sin ninguna desventaja real para quien la consulta.
Procesa de forma incremental en vez de reprocesar todo. El Auto Loader de Databricks puede identificar automáticamente archivos nuevos o modificados en el almacenamiento en la nube, y combinado con structured streaming, esto permite que un pipeline procese solo lo que cambió en lugar del conjunto de datos completo en cada ejecución. Soucy lo describió como más complejo de configurar, pero esencial para cualquier workload de alto volumen.
Perfila y reescribe las consultas costosas. La vista de perfil de consultas de Databricks muestra cómo Spark ejecutó realmente una transformación, incluyendo shuffles y spills que son fáciles de pasar por alto. Soucy señaló que alimentar esa información de perfil, junto con el código de la transformación, a un asistente de código con IA le ha producido reescrituras reales y utilizables en su propio trabajo, convirtiendo una tarea que antes exigía experiencia profunda en Spark en algo mucho más accesible.
No descuides el almacenamiento, y haz que todo perdure
En el lado del almacenamiento, el consejo de Soucy fue evitar el ajuste manual de particionamiento y Z-ordering y apoyarse en las tablas administradas de Unity Catalog, que soportan la optimización predictiva. La optimización predictiva ejecuta operaciones de vacuum, optimize y analyze de forma automática y programada, limpiando archivos obsoletos, compactando archivos pequeños en otros más grandes y refrescando los metadatos para que las consultas puedan saltarse archivos que no necesitan leer. Ejecutarla tiene un costo, pero el efecto neto suele ser una factura menor que la que produciría el mantenimiento manual. El liquid clustering, que en gran medida ha reemplazado al Z-ordering manual, ofrece una ventaja similar: no requiere reescribir los datos existentes cuando hay que cambiar las columnas de clustering.
Nada de esto se sostiene en el tiempo sin gobernanza. La recomendación de Soucy es gestionarlo todo como código, con herramientas como Terraform o Databricks Asset Bundles, desplegado vía CI/CD, para que las configuraciones se mantengan consistentes entre entornos y no se desvíen silenciosamente. Las políticas de clúster son la palanca principal aquí: define valores por defecto sensatos para la mayoría de los usuarios, exige la auto-terminación y límites de tipo de nodo, y deja espacio para que los usuarios avanzados que de verdad necesiten más flexibilidad la soliciten. Los pools de clústeres también ayudan al mantener un conjunto de instancias listas del lado del proveedor de nube, para que los jobs no esperen el arranque del clúster, aunque esa capacidad inactiva se la sigues pagando al proveedor de nube incluso si Databricks no te la cobra.
Soucy también advirtió sobre una categoría de costo fácil de pasar por alto: las funciones más nuevas de Databricks como apps, endpoints de model serving, vector search y quality monitors. Contó que él mismo configuró mal un quality monitor sobre una tabla grande, lo que aumentó la factura diaria de esa tabla en un 50% antes de que lo detectara. Whitestone agregó que las funciones relacionadas con IA probablemente se conviertan en un renglón cada vez mayor en las facturas de Databricks en general, señalando la reciente decisión de Databricks de empezar a cobrar por herramientas antes gratuitas como Genie. La conclusión de ambos: configura alertas de costo antes de activar algo nuevo, no después.
El hilo conductor
En las cinco estrategias aparece el mismo patrón: cuando se trata de costos, Databricks rara vez falla haciendo ruido. Los clústeres inactivos corren en silencio, los jobs sobreprogramados corren en silencio, el cómputo sobredimensionado corre en silencio, y las funciones nuevas se activan sin que nadie revise lo que van a costar hasta que llega la factura. Ninguna de las soluciones aquí es exótica. La auto-terminación, los timeouts sensatos, alinear el tipo de cómputo con el workload y tratar la configuración como código se encargan de la mayor parte del gasto evitable para la mayoría de los equipos.
Para los equipos que prefieren que esto se maneje de forma automática en lugar de manual, SELECT para Databricks saca a la luz este tipo de pérdida directamente, señalando la auto-terminación faltante, los jobs sobreprogramados (en un ejemplo real compartido durante la sesión, reducir un job de 472 ejecuciones diarias a una por hora ahorró el 95% de su costo, unos $19,000 al año) y los warehouses o jobs responsables de una porción desproporcionada del gasto, hasta el nivel de la consulta individual. Puedes ver cómo funciona en select.dev.
FAQ
¿Qué es lo que más genera costos innecesarios en Databricks? El cómputo inactivo. Los clústeres y warehouses que quedan corriendo sin auto-terminación, o los jobs que se cuelgan sin un timeout, generan cargos sin devolver ningún valor. Corregir esto antes que cualquier otra cosa de la lista suele dar el retorno más rápido.
¿Debería usar serverless o cómputo clásico por defecto en Databricks? Serverless es un valor por defecto razonable para la mayoría de los workloads, ya que elimina el tiempo de arranque del clúster y ubica a la mayoría de los equipos en el rango de costos correcto sin ajustes manuales. La excepción son tus cinco a diez workloads más costosos por gasto, que normalmente se benefician del control adicional que el cómputo clásico te da sobre el tipo de nodo, el autoescalado y la cantidad de workers.
¿Cuál es la diferencia entre el costo de DBU y el costo de infraestructura en la nube? El precio por DBU (Databricks Unit) es lo que el propio Databricks cobra por el cómputo, y varía según el tipo de cómputo. El cómputo clásico además genera una factura aparte de infraestructura en la nube de AWS, Azure o GCP por las instancias subyacentes, algo que el cómputo serverless no tiene. Como regla práctica, asume que el costo de infraestructura en la nube es casi igual al costo de DBU en el cómputo clásico.
¿Cuánto ahorra realmente la auto-terminación? Varía según el workload, pero el costo de omitirla puede ser grande. En un ejemplo real, un clúster de GPU mal configurado y sin auto-terminación sumó unos $4,000 a la factura de un solo mes antes de que alguien lo notara.
¿Cómo afecta la frecuencia de ejecución de los jobs al costo de Databricks? De forma significativa. Tomando una actualización diaria como línea base, ejecutar el mismo job cada hora cuesta aproximadamente cinco veces más, y las actualizaciones casi en tiempo real cuestan alrededor de 60 veces más. Cuestionar si un workload realmente necesita ejecutarse con esa frecuencia suele ser la corrección de costos de mayor impacto disponible.
¿Databricks cobra por funciones de IA como Genie? Databricks ha empezado a cobrar por herramientas que antes eran gratuitas, incluida Genie, y se espera que las funciones relacionadas con IA se conviertan en un renglón cada vez mayor en las facturas de Databricks. Configurar alertas de costo antes de habilitar funciones nuevas es la mejor defensa contra sorpresas.