TL;DR
Los ahorros rápidos en la optimización de costos de Databricks (auto-termination, timeouts, autoescalado, cómputo bien dimensionado) son el mejor retorno que vas a obtener: suelen recortar entre un 20 y un 40 % de la factura y se aplican en minutos. Más allá de ellos, normalmente hay otro 20 a 40 % disponible, pero cuesta días o semanas de esfuerzo y solo rinde en los workloads donde los números cierran. Esta guía trata de ese segundo nivel: cómo encontrar los jobs que valen el esfuerzo y cómo hacer que trabajen menos antes de decidir en qué cómputo ejecutarlos.
Introducción
La mayoría de los consejos sobre costos de Databricks se quedan en la configuración. Configura la auto-termination, agrega timeouts, activa el autoescalado, deja de sobredimensionar tus clústeres. Ese consejo es correcto, y deberías aplicarlo todo primero, porque es genuinamente el trabajo de mayor retorno disponible. Según tu punto de partida, esos ahorros rápidos suelen recuperar entre el 20 y el 40 % de la factura, y la mayoría toma minutos. Nadie debería saltárselos, y este artículo no sostiene que sean poca cosa.
El punto es que tienen un techo. Una vez que desaparecen los clústeres inactivos, se configuran los timeouts y el cómputo queda bien dimensionado, ya capturaste un gran ahorro único y la curva se aplana. Los workloads en sí siguen haciendo exactamente el mismo trabajo que antes. Conseguir el siguiente 20 a 40 % implica cambiar lo que los jobs realmente hacen: un pipeline que reprocesa todo su historial cada noche, una consulta que escanea cien veces más datos de los que devuelve, un dashboard "en tiempo real" que nadie abre más de una vez al día. Nada de eso se abarata al redimensionar el clúster. Se abarata cuando se rediseña el trabajo, y eso cuesta días o semanas en lugar de minutos. Además, solo rinde en algunos workloads, y por eso el primer paso real es identificar cuáles. Esta guía trata de ese segundo nivel.
¿Por qué la mayoría de los esfuerzos de costos en Databricks se estancan después de los ahorros fáciles?
El primer repaso a los costos de Databricks casi siempre apunta al mismo puñado de controles, y con razón. Son los ajustes de mayor retorno y menor esfuerzo disponibles, y saltárselos es la receta para que la factura se dispare. Si todavía no los aplicaste, empieza por ahí: nuestro artículo Databricks Pricing Explained repasa en detalle la auto-termination, los timeouts y Job Compute frente a all-purpose. Considera ese artículo el prerrequisito y este, el paso siguiente.
Este es el problema de quedarse ahí. Cada uno de esos controles es una corrección única. La auto-termination evita que pagues por clústeres inactivos, pero cuando el tiempo inactivo llega a cero, no queda nada más que recuperar. Mover un pipeline de un clúster all-purpose a $0.55 por DBU a Jobs Classic a $0.30 por DBU recorta el precio de ese job en aproximadamente un 45 %, pero ese cambio solo se hace una vez. Son ahorros grandes y rápidos, con frecuencia entre una quinta y dos quintas partes de la factura, y luego se acaban. La curva se aplana y la factura se asienta en una nueva línea base, más baja, que deja de moverse.
Esa línea base la determina cuánto trabajo hacen tus jobs, y esa es la variable que los ahorros rápidos nunca tocan. Un pipeline diario que reescribe por completo una tabla de mil millones de filas es caro incluso en el clúster de Jobs más barato y mejor dimensionado que puedas aprovisionar. El siguiente nivel de ahorro vive en el workload mismo: procesar menos datos, ejecutar con menos frecuencia, calcular los resultados una vez en lugar de repetidamente. Eso es más difícil que cambiar un ajuste en la configuración, toma días o semanas en lugar de minutos y no rinde en todas partes. En un pipeline barato o poco frecuente, el tiempo de ingeniería costará más de lo que ahorra. Precisamente por eso el siguiente paso no es empezar a optimizar, sino descubrir qué workloads vale la pena optimizar.
¿Cómo encontrar los workloads que vale la pena optimizar?
Antes de optimizar nada, averigua qué es realmente caro. Esto importa más de lo que parece, porque el instinto de ingeniería y la factura rara vez apuntan a lo mismo. El pipeline que te resulta molesto suele ser barato. El que nadie tiene en mente corre en un clúster grande tres veces al día y domina la factura en silencio.
La forma más rápida de clasificar tu gasto son las tablas de sistema de facturación. Cruza system.billing.usage (cada DBU consumido) con system.billing.list_prices (el precio efectivo por SKU) para convertir cantidades en dólares, y luego une system.lakeflow.jobs para asociar un nombre de job legible, de modo que el ranking sea realmente accionable:
WITH price AS ( SELECT sku_name, pricing.effective_list.default AS price_effective FROM system.billing.list_prices WHERE price_end_time IS NULL),usage AS ( SELECT * FROM system.billing.usage WHERE usage.billing_origin_product = 'JOBS'Expandir código
Esto ordena tus jobs por costo diario con sus nombres, lo que responde la única pregunta que importa en esta etapa: ¿qué jobs concretos están inflando la factura? Por cierto, el join con system.lakeflow.jobs es lo que hace que etiquetar valga la pena. Las etiquetas nunca bajan una factura por sí solas, pero son las que te permiten agrupar este resultado por equipo, entorno o proyecto en lugar de ahogarte en IDs de jobs y nombres que cambian con el tiempo.
La razón para clasificar antes de actuar es que la optimización tiene un costo propio, y es fácil gastar más tiempo de ingeniería del que se ahorra. Reescribir un pipeline que representa el 1 % de tu factura es un ejercicio satisfactorio que nunca se verá reflejado en la factura, y las horas que le dediques normalmente superarán por mucho los ahorros durante años. Ordena por costo, mira el puñado de workloads más caros e ignora la cola larga hasta que los caros estén resueltos. Optimiza los casos atípicos, no todo.
Clasificar tu propio gasto por workload implica escribir y mantener estas consultas, y además mantener los dashboards al día a medida que los jobs cambian de nombre y los pipelines evolucionan. SELECT hace esa atribución de forma automática y muestra tus workloads más caros, el cómputo inactivo y los desajustes de tipo de cómputo sin que tengas que construir consultas a mano. Mira lo que encuentra en tu entorno.
¿Por qué optimizar el job rinde más que redimensionar el clúster?
Esta es la sección que justifica todo lo demás. Cuando un job es lento o caro, el arreglo instintivo es un clúster más grande, porque es un solo ajuste y suele funcionar. También es el arreglo más caro disponible, y deja intacta la pérdida subyacente. Un job que escanea más datos de los que necesita, hace shuffles innecesarios o reprocesa historial que ya procesó quemará cómputo de más con cualquier tamaño de clúster. Escalar solo paga ese impuesto más rápido.
Para hacerlo concreto: un cliente mío tenía un pipeline de datos IoT que redujimos en cerca de un 85 % en tiempo de ejecución y un 75 % en costo, unos $10,000 al año, en el mismo entorno. El cómputo no estaba mal dimensionado de entrada: no era óptimo, pero tampoco escandaloso. Redimensionarlo habría movido la factura en porcentajes de un solo dígito. El ahorro vino por completo de cambiar lo que hacía el pipeline: carga incremental de las capas bronze y silver en lugar de reprocesar todo, posponer un join caro con una tabla de hechos hasta después de que la agregación diaria hubiera reducido los datos, reescribir la transformación más pesada y servir el consumo mediante vistas en lugar de duplicar datos en tablas nuevas. Cada uno de esos puntos corresponde a una de las palancas de abajo. Ninguno por sí solo fue toda la historia, y el dimensionamiento del cómputo no estaba en la lista.
Lee el perfil de la consulta y rediseña la parte cara
Databricks expone un perfil de consulta detallado para cada ejecución, que muestra en qué se fue el tiempo en cada etapa del plan. Desde el historial de consultas, o directamente desde un job o una consulta SQL, puedes abrir el perfil y descargar el plan de ejecución completo como JSON. Ese JSON es el insumo del truco más potente y menos conocido del flujo moderno de ingeniería de datos: dárselo a un LLM.
Un LLM es muy bueno para leer un perfil de consulta y decirte dónde está el costo: qué etapa hizo spill, qué join explotó, dónde un shuffle corrió sobre muchas más particiones de las que los datos justificaban. En un job real, uno señaló que el cuello de botella era una transformación SQL que construía un calendario de fechas completo (una fila por entidad por día, a lo largo de unos catorce años de historial) y luego lo volvía a colapsar, produciendo decenas de millones de filas intermedias para calcular un resultado que necesitaba una fracción mínima de eso. Y no se quedó en el diagnóstico. Propuso una primera reescritura en PySpark con un enfoque basado en eventos, de barrido por intervalos, que nunca materializa el calendario, y a partir de ahí se convirtió en un verdadero colaborador en la solución. Yo señalaba un caso límite que la primera versión no manejaba, el modelo incorporaba la corrección, capturábamos ese caso como prueba unitaria, e iteramos ese ciclo durante dos o tres días hasta que los resultados fueron correctos en todos los frentes. El job diario pasó de unas dos horas a diez minutos, una reducción de aproximadamente 15x tanto en tiempo de ejecución como en costo de DBU.
El punto es la división del trabajo, y no es "la IA encuentra problemas y el humano hace el trabajo de verdad". El modelo encontró el cuello de botella, propuso el algoritmo y escribió la mayor parte del código. Mi trabajo fue dirigir: detectar los casos que se le escapaban, decidir cuándo la solución era realmente correcta y mantener la iteración honesta con pruebas. Ese es un uso genuinamente distinto y más capaz que pegar un mensaje de error. Si editas en el workspace de Databricks, Genie lo maneja bien; si estás en tu IDE, el asistente que ya tengas integrado funciona igual de bien. La herramienta importa menos que el hábito de leer el perfil y reconstruir la parte cara en lugar de recurrir a un clúster más grande.
Pasa a lo incremental en lugar de sobrescribir toda la tabla
La sobrescritura completa es el patrón de pipeline más simple, y para tablas pequeñas o medianas suele ser la decisión correcta. La complejidad del procesamiento incremental no siempre vale la pena. Pero cuando los volúmenes de datos son altos, especialmente con datos transaccionales, telemetría o series de tiempo, reprocesar toda la tabla en cada ejecución se vuelve más caro y más difícil de justificar cada vez que la tabla crece.
La alternativa incremental es agregar los registros nuevos cuando los datos son inmutables, o hacer merge de los registros modificados cuando los datos se actualizan, y llevar ese patrón a tantas capas de tu arquitectura medallion como sea posible. Solo cuando los datos se agregan hasta volverse pequeños, la sobrescritura completa vuelve a ser razonable. Spark Structured Streaming es la herramienta práctica aquí: combinado con Auto Loader para la ingesta de archivos o leyendo de forma nativa desde una tabla Delta, gestiona los checkpoints automáticamente, de modo que cada ejecución procesa solo lo que llegó desde la anterior. La mayor ganancia para la mayoría de los equipos no es el procesamiento continuo en tiempo real, sino el patrón confiable de batch incremental que el streaming facilita: procesar los datos nuevos sin volver a escanear lo que ya existe.
Cuestiona el requisito de "tiempo real" antes de aceptarlo
"Necesitamos datos casi en tiempo real" es uno de los requisitos más caros que un equipo de datos puede aceptar sin cuestionarlo, y rara vez es cierto. Los stakeholders casi nunca necesitan un flujo continuo de datos frescos. Necesitan una vista suficientemente reciente cuando realmente la consultan, que es algo completamente distinto y mucho más barato. Antes de construir para tiempo real, averigua con qué frecuencia se abre realmente el dashboard y con qué frecuencia se lee realmente el reporte. Las actualizaciones por hora, diarias o incluso semanales son suficientes mucho más a menudo de lo que el pedido original sugiere.
La diferencia de costo no es marginal. Toma un pipeline ilustrativo y mantén el trabajo constante cambiando solo la cadencia: ejecutarlo de forma continua podría costar 58 unidades; ejecutarlo cada hora reduce el mismo trabajo a unas 5 unidades; ejecutarlo tres veces al día te deja cerca de 1 unidad. Eso no es una diferencia de redondeo: es aproximadamente 12x de continuo a cada hora, y otro gran salto hacia abajo a partir de ahí.
La jugada práctica es construir cada pipeline con Structured Streaming sin importar la frecuencia que pidan al inicio, porque el streaming hace trivial alternar entre batch programado y operación continua. Luego empieza con la frecuencia más baja que satisfaga la necesidad real del negocio, y súbela solo cuando haya evidencia real de que se necesita más frescura. La capacidad de escalar está ahí cuando la necesites; el ahorro de no escalar prematuramente llega de inmediato.
Construye vistas en lugar de tablas
No toda tabla necesita contener datos físicamente. Una buena parte de las tablas en un entorno típico de Databricks no existe por transformaciones complejas, sino para exponer los datos con otra forma: otro esquema, un filtro, un subconjunto de columnas, otro conjunto de permisos de acceso. En esos casos, copiar los datos físicamente suma costo de almacenamiento, costo de cómputo y complejidad de pipelines sin un beneficio real.
Una vista es la herramienta adecuada para eso. Es una capa virtual definida por una consulta, sin nada copiado ni almacenado, y para una selección de columnas o un filtro sencillos, la experiencia de lectura es indistinguible de una tabla. Reserva las tablas físicas para los resultados de transformaciones realmente caras, donde materializar el resultado ahorra un recálculo significativo. Para todo lo demás, una vista mantiene el almacenamiento ligero y los pipelines más simples. Para profundizar en estos patrones de trabajo, nuestro ebook gratuito de optimización de costos los repasa con el diagrama de diagnóstico que usamos para decidir qué palanca aplica a cada workload.
¿Cómo elegir el cómputo correcto una vez que el job es eficiente?
Fíjate en el orden. La selección de cómputo viene después de optimizar el workload, no antes, y esa secuencia es el argumento central de este artículo. Dimensionar el cómputo para un job ineficiente solo fija la pérdida en la escala que hayas elegido. Una vez que el job hace la cantidad correcta de trabajo, la decisión de cómputo se vuelve más simple y hay menos en juego.
El default debería ser serverless, en todos los frentes: jobs, notebooks y SQL. Puede parecer contraintuitivo, porque serverless tiene un precio por DBU más alto: en Azure Premium, Jobs Serverless cuesta $0.45 por DBU frente a $0.30 de Jobs Classic, y el Serverless interactivo cuesta $0.95 frente a $0.55 del all-purpose clásico. Pero el precio por DBU es solo la mitad de la historia, y esta es la parte que los equipos más suelen pasar por alto al comparar. En el cómputo clásico, el cargo por DBU no es toda la factura. También le pagas por separado a tu proveedor de nube por las VMs subyacentes, y ese número es genuinamente difícil de estimar por adelantado. Serverless incluye la infraestructura en el precio por DBU, así que el precio que ves es el precio que pagas.
Ese empaquetado invierte la comparación ingenua más seguido de lo que esperarías. El pipeline ETL por hora de un cliente es un ejemplo limpio. En Job Classic a $0.30 por DBU consumía unos 44 DBU al día, lo que sumaba cerca de $13 en DBUs más otros $10 en cargos de VMs de la nube: unos $23 al día en total. La versión serverless del mismo workload usó menos DBUs (alrededor de 38, porque escaló más ajustado al trabajo real) a $0.45 por DBU, por unos $18 al día sin ninguna factura de nube aparte. La opción con el precio nominal más alto resultó ser la más barata una vez contado el cargo de las VMs, y no requirió ningún ajuste para llegar ahí.
Hay un segundo costo que nunca aparece en ninguna de las dos facturas: el tiempo de ingeniería para dimensionar y afinar correctamente un clúster clásico (tipo de instancia, relación memoria-núcleos, comportamiento de autoescalado, y revisar todo eso a medida que el workload evoluciona). Para la mayoría de los workloads, ese tiempo cuesta más que cualquier sobreprecio por DBU. Un día de afinación para recortar un 10 % de un pipeline modesto puede tardar un año en recuperarse. Serverless también elimina toda una clase de problemas operativos: sin arranque de clústeres, sin gestión de versiones, sin clústeres inactivos que olvidar.
Para ser honestos: serverless rara vez es la opción más barata para un pipeline concreto considerado de forma aislada, pero para la mayoría de los pipelines te lleva al 80 o 90 % del camino sin ningún esfuerzo de afinación. A lo largo de todo tu portfolio, eso gana en costo total de propiedad, porque la gran mayoría de tus pipelines termina razonablemente eficiente sin que les dediques un minuto. Luego usas tu ranking de costos para encontrar el puñado de jobs frecuentes y caros que corren de forma predecible, y esos son los que vale la pena mover a cómputo clásico y afinar a mano, cálculo de VMs de la nube incluido. Optimiza los casos atípicos y deja todo lo demás en serverless por default.
Cuando sí configures cómputo clásico, empieza con el recurso más pequeño que funcione y escala con evidencia. El sobredimensionamiento es el estado por default de la mayoría de los despliegues de Databricks, porque las configuraciones se copian de un colega, se heredan de un proyecto viejo o se dejan en lo que sugirió la interfaz. Elige el tamaño de SQL warehouse más pequeño y sube solo cuando los tiempos de consulta se vuelvan inaceptables; para los clústeres, empieza con un tipo de nodo de propósito general y autoescala de uno a dos o cuatro workers. Un cómputo del doble de tamaño no ejecuta los jobs al doble de velocidad, pero sí cuesta el doble, sin excepción.
¿Cómo evitar que los costos vuelvan a subir?
La optimización individual es un punto de partida, no un estado estable. Los equipos crecen, los workloads se multiplican, llegan nuevos ingenieros con sus propios hábitos, y los costos vuelven a subir a menos que algo los contenga. Ese algo es una capa de gobernanza, y es lo que convierte una limpieza puntual en una línea base duradera.
La medida individual más confiable es dejar de permitir que el cómputo se cree ad hoc. Cuando los ingenieros aprovisionan sus propios clústeres, los ajustes que importan (auto-termination, límites de escalado, tipos de instancia, etiquetas) se configuran de forma inconsistente o directamente no se configuran, y toda optimización cuidadosa hecha en otra parte se fuga. Define tus clústeres y warehouses como infraestructura como código, despliégalos vía CI/CD y haz que los ingenieros elijan de un conjunto preaprobado en lugar de construir los suyos. Para los usuarios avanzados que de verdad necesitan crear cómputo personalizado, las políticas de clúster son el punto medio: una política puede exigir auto-termination, limitar el tamaño del clúster y restringir los tipos de instancia, dejando margen para ajustar dentro de esos límites. La opción eficiente en costos se convierte en la única opción disponible. Para saber más sobre por qué creemos que este problema merece herramientas dedicadas, lee por qué construimos SELECT para Databricks.
La prevención no lo atrapa todo, así que acompáñala con alertas. Databricks tiene una función nativa de presupuestos en la consola de cuenta para umbrales de gasto, que es un buen punto de partida. Pero la señal más sensible es estadística, no un límite fijo: mide la desviación estándar del costo diario o semanal por workload y alerta ante desviaciones del rango normal. Un umbral fijo solo se dispara cuando el gasto ya cruzó una línea dura. Vigilar la deriva detecta el problema el mismo día en que un job empieza a comportarse mal, no al final del ciclo de facturación, cuando el daño ya está hecho. Esa visibilidad el mismo día es la diferencia entre una pequeña corrección y una factura fea.
La optimización de costos de Databricks no es un proyecto de una sola vez. La plataforma evoluciona, los equipos agregan workloads, y la línea base que te costó bajar volverá a subir sin visibilidad continua. SELECT les da a los equipos de plataforma de datos esa visibilidad en un solo lugar: clasifica el gasto por workload, detecta la deriva apenas comienza y muestra los ahorros que se acumulan con el tiempo. Agenda una demo para ver lo que encuentra en tu entorno.
FAQ
¿Cuál es la forma más rápida de reducir los costos de Databricks?
Dos cambios de configuración recuperan la mayor cantidad de dinero con el menor esfuerzo: configurar la auto-termination en cada clúster y SQL warehouse para que los recursos inactivos dejen de facturar, y mover los pipelines programados del cómputo all-purpose a Jobs Compute. En Azure Premium, eso lleva un job de $0.55 por DBU a $0.30, un recorte de aproximadamente el 45 % en el precio de ese workload. Ambos son cambios de una tarde. La advertencia honesta: ninguno toca un pipeline mal diseñado. Si un job reprocesa todo su historial cada noche o escanea muchos más datos de los que devuelve, seguirá siendo caro en el clúster más barato y mejor dimensionado que puedas darle. Los ahorros rápidos fijan una línea base más baja; bajarla aún más implica rediseñar el trabajo.
¿Serverless es más barato que el cómputo clásico?
No por DBU, y no siempre en total, así que no hay un sí o un no limpio. Serverless tiene un precio más alto (en Azure Premium, $0.45 por DBU para Jobs Serverless frente a $0.30 de Jobs Classic), pero incluye la infraestructura que de otro modo pagarías y afinarías por tu cuenta. Para la mayoría de los workloads, el tiempo de ingeniería ahorrado pesa más que el sobreprecio, y por eso serverless es un buen default. La trampa a tener en cuenta: serverless escala con tanta suavidad que los aumentos de costo se esconden mejor que en el cómputo clásico. Dos ejecuciones pueden tardar el mismo tiempo de reloj y consumir cantidades muy distintas de DBUs, porque serverless escaló silenciosamente para la más pesada. La duración se ve plana mientras la factura se duplica. Monitorea el consumo de DBUs, no solo el tiempo de ejecución.
¿Unity Catalog aumenta mi factura de Databricks?
Unity Catalog en sí no es un producto con precio aparte, pero habilitarlo cambia tu perfil de costos de maneras que conviene entender antes de migrar. Predictive Optimization, que ejecuta OPTIMIZE y VACUUM automáticamente en las tablas gestionadas de Unity Catalog, consume DBUs (en general se amortiza con los ahorros en consultas, pero es un renglón real de la factura). Las funciones de gobernanza, el mantenimiento de tablas gestionadas y el cómputo serverless en el que corren varias operaciones del catálogo aparecen todos en algún lugar. Cubrimos cómo Unity Catalog afecta el costo en su propia guía; la versión corta es que la gobernanza vale la pena, pero no es gratis, y deberías saber dónde cae en la factura antes de activarla.