Establece presupuestos y alertas para los costos de data warehouse en la nube

Todos los equipos de análisis han pasado por esto: llega la factura de fin de mes y un único SQL warehouse ha superado su presupuesto, tal vez porque un recurso de computación se quedó encendido toda la noche o por uno ad hoc que se autoescaló para dar servicio a 80 usuarios de Tableau durante una revisión trimestral. El coste es real, pero la frustración es aún mayor: nadie se enteró hasta que fue demasiado tarde.

La gestión proactiva de costes cambia por completo ese modelo. En lugar de realizar un análisis forense de las facturas a posteriori, se establecen límites antes de gastar un solo dólar: los presupuestos se vinculan a los warehouses, equipos o cargas de trabajo de BI. Alertas que se activan en los umbrales que elijas y dashboards que muestran las tendencias de uso en tiempo real, todo en la Databricks Data & AI Platform. Si estás en plena migración desde un sistema local o desde otro data warehouse en la nube, este es el momento de implementar esa gobernanza.

¿Por qué falla la gestión reactiva de costes?

Las cargas de trabajo de almacenamiento de datos presentan desafíos de costes únicos. Los SQL warehouses atienden cargas de trabajo interactivas y dirigidas por personas (dashboards de BI, análisis ad hoc, analítica integrada) donde la demanda es impredecible y variable. Una sola reunión general de directivos que active 200 actualizaciones simultáneas de dashboards puede disparar los costes en cuestión de minutos. La mayoría de las organizaciones comienzan su andadura en FinOps de la misma manera: alguien descarga el CSV de uso del mes pasado, abre una tabla dinámica y empieza a hacer preguntas. Este enfoque falla por cuatro razones:

• No puedes ver quién está gastando. El uso se acumula a nivel de plataforma, no del equipo o de la consulta que lo originó, por lo que nadie se hace responsable de una cifra.
• Nadie es responsable de un presupuesto. Sin objetivos de gasto vinculados a un warehouse o equipo, el analista que ejecuta SELECT * en una tabla de 2 TB nunca nota el coste. El equipo de la plataforma lo asume silenciosamente.
• Te enteras demasiado tarde. Para cuando los informes de Excel del mes pasado muestran el exceso de gasto, ya han pasado dos ciclos de facturación y la decisión que lo causó es invisible.
• La revisión manual no es escalable. Cinco warehouses pueden superar una revisión mensual de tablas dinámicas. Sin embargo, una vez que se escala a docenas, dar soporte a cientos de analistas en Tableau, Power BI y Looker se vuelve inmanejable.

La gestión proactiva de costes (atribución, presupuestos, alertas, dashboards y optimización) aborda estos cinco aspectos.

Empieza con serverless: la primera decisión de costes.

Antes de configurar los presupuestos, elige el tipo de warehouse adecuado. Los SQL Serverless warehouses son la opción recomendada por Databricks para la mayoría de las cargas de trabajo. Se inician en segundos, reducen su escala en cuanto finalizan las consultas y permiten que Intelligent Workload Management asigne la computación por ti, de modo que solo pagas por la ejecución real de las consultas, no por el tiempo de inactividad.

Si estás migrando desde un data warehouse en la nube heredado, este es un cambio importante. La mayoría de las plataformas heredadas cobran por la computación siempre activa o requieren decisiones de escalado manuales. Serverless elimina por completo este tipo de errores de costes.

Lumen Technologies lo comprobó de primera mano: la migración de dos sistemas de telecomunicaciones esenciales de un data warehouse local a SQL Serverless redujo los costes de computación entre un 30 y un 40 % y aumentó la velocidad de las consultas en un 90 %. Ahora el sistema se escala automáticamente para gestionar aproximadamente 7 GB cada 10 minutos, y Serverless elimina el "impuesto por estar siempre activo" que suele asociarse a las cargas de trabajo variables en tiempo real.

Los de cinco pilares de la gestión proactiva de costes

El marco de trabajo consta de cinco pilares. Los cuatro primeros hacen visible tu gasto; el quinto es el que realmente lo reduce:

• Atribución de costes. Etiqueta todo para saber quién ha gastado qué y en qué warehouse.
• Presupuestos. Define objetivos de gasto mensuales a nivel de cuenta, espacio de trabajo o equipo.
• Alertas. Recibe notificaciones en el momento en que el gasto se acerque o supere un umbral.
• Dashboards. Visualiza las tendencias de los warehouses y haz del coste una métrica operativa de primer nivel.
• Optimizaciones. Reduce el coste del trabajo en primer lugar.

Pilar 1: Atribución de costes a dos niveles

No se puede gestionar lo que no se puede atribuir, y con los warehouses eso significa dos niveles: el propio warehouse y la consulta individual. Uno te indica qué warehouse gastó el dinero; el otro te dice quién lo hizo dentro de él.

Nivel 1: Etiquetado del warehouse

Los SQL warehouses admiten etiquetas personalizadas como pares key:value que se propagan a system.billing.usage, vinculando cada DBU consumida a un equipo, proyecto o centro de costes. El etiquetado funciona de la misma manera para todos los tipos de warehouse (Classic, Pro y Serverless se etiquetan a nivel de warehouse), por lo que solo tienes que aprender un patrón y aplicarlo en todas partes.

Configura las etiquetas en la UI en SQL Warehouses > tu warehouse > Edit > Tags, o crea el warehouse a través de la REST API:

Etiquetado a través de la REST API

Aplica al menos tres dimensiones: equipo (quién es el propietario), centro de costes (quién paga) y caso de uso (servicio de BI, ad hoc, actualización programada).

Actualmente no existe una política nativa que obligue a usar etiquetas de warehouse, por lo que cualquiera puede crear uno sin etiquetar. En su lugar, integra la obligatoriedad en tu proceso de aprovisionamiento: crea warehouses con Terraform, Declarative Automation Bundles o la REST API con etiquetas en la definición, y trata la UI como la excepción. La consulta de brecha de atribución que veremos más adelante en esta publicación detectará cualquier cosa que se pase por alto.

Nivel 2: Etiquetado de la consulta

Las etiquetas de warehouse te indican que un warehouse costó 4000 USD el mes pasado. Pero no te dicen que el 60 % de ese coste provino de un único dashboard de Power BI que se actualiza cada 15 minutos. Esa brecha es importante porque los warehouses se comparten: un único warehouse de BI da servicio a docenas de dashboards, varios modelos de dbt y un flujo de consultas ad hoc.

Query tags (Public Preview) solucionan esto al adjuntar contexto de negocio a sentencias SQL individuales:

Las etiquetas se registran en la columna query_tags de system.query.history (Public Preview), junto con executed_by y statement_id, de modo que puedes agrupar el gasto por dashboard, modelo o centro de costes en lugar de por warehouse. Algunas herramientas las configuran por ti: a partir de dbt-databricks 1.11.0, las consultas de modelo se etiquetan automáticamente con el nombre del modelo de dbt, y Power BI pasa los identificadores de espacio de trabajo y conjunto de datos a través del controlador ADBC.

Dos advertencias: las etiquetas de consulta solo se aplican a las consultas de SQL warehouses y, dado que se encuentran en el historial de consultas en lugar de en los datos de facturación, debe combinarlas usted mismo para obtener el costo por consulta.

Antes de escribir cualquier instrucción SQL, consulte la página de costos en Governance Hub (Beta), una vista a nivel de cuenta de los gastos, los factores de costo, los presupuestos y la cobertura de etiquetas, y la forma más rápida de ver qué parte de su uso es atribuible. Un administrador de cuenta puede habilitarla desde la página Previews de la consola de la cuenta.

Pilar 2: Configuración de presupuestos en la consola de la cuenta

Creación de un presupuesto

En la consola de la cuenta, vaya a Uso > Presupuestos, haga clic en Agregar presupuesto y configure:

• Nombre: descriptivo (por ejemplo, "SQL Warehouses de análisis, mensual")
• Monto: objetivo mensual en USD
• Alcance: filtre por espacios de trabajo o etiquetas (por ejemplo, Equipo:Análisis)
• Notificaciones por correo electrónico: destinatarios a los que se notificará cuando el gasto alcance el monto del presupuesto

Ejemplos de configuración de presupuestos

El patrón clave son los presupuestos escalonados: presupuestos a nivel de equipo para la rendición de cuentas, además de un presupuesto para toda la cuenta como red de seguridad que detecta cualquier imprevisto. 

Tenga en cuenta que los presupuestos son un mecanismo de monitoreo, no un límite estricto. No detienen el uso ni evitan los cargos, por lo que su factura aún puede superar el monto establecido. El objetivo es la concientización y la respuesta rápida, no los cortes que podrían interrumpir la actualización de un panel de producción.

GetYourGuide probó esto directamente: consolidar todas sus cargas de trabajo de Looker en SQL Serverless redujo los costos de servicio de BI en aproximadamente un 20% y aceleró las consultas en un 35%, a pesar de que el equipo esperaba que los clústeres Classic fueran más económicos. La elección del tipo de SQL warehouse es una decisión presupuestaria que vale la pena volver a validar, no una decisión que se toma una sola vez.

Lectura de su ritmo de consumo

Haga clic en cualquier presupuesto para ver el gasto actual frente al objetivo, el presupuesto restante y una visualización del ritmo de consumo día a día. Para el almacenamiento de datos, este gráfico es especialmente revelador:

• El consumo diario lineal significa costos estables de servicio de BI.
• El patrón de dientes de sierra con picos los lunes y viernes indica que la exploración ad hoc se concentra en los días laborables.
• Un aumento repentino a mitad de mes significa que se implementó un nuevo panel sin una revisión de costos.
• Una tendencia gradual al alza significa que la adopción orgánica está superando sus estimaciones presupuestarias.

Pilar 3: Alertas, el sistema nervioso de la gobernanza de costos

Los presupuestos le indican dónde se encuentra. Las alertas le indican cuándo actuar.

Alertas de presupuesto por correo electrónico

Cuando cree un presupuesto, agregue destinatarios de correo electrónico para que reciban una notificación cuando el gasto supere el monto del presupuesto. No se necesita código.

Para las alertas basadas en umbrales, cree Databricks SQL Alerts que consulten directamente `system.billing.usage`. Estos son los patrones más importantes:

Alerta cuando el gasto diario de SQL warehouse supera un umbral

Alerta de ritmo: el gasto proyectado para el final del mes superará el presupuesto

Este es el patrón del que los equipos obtienen el mayor valor. En lugar de alertar después de que se supere el límite, proyecta el gasto de fin de mes y se activa antes de que esa proyección supere su presupuesto, mientras aún tiene tiempo de actuar:

Programe esto cada cuatro horas y envíelo a Slack o por correo electrónico. Esto les da a los equipos días para reaccionar (ajustar el tamaño de un SQL warehouse, optimizar una consulta costosa, posponer un lote) antes de que se supere el presupuesto.

Detección de costos ocultos en las actualizaciones de vistas materializadas

Los costos de actualización de las vistas materializadas son los que los equipos suelen pasar por alto con más frecuencia, ya que se facturan como uso de pipelines serverless en lugar de uso de SQL warehouse. Una vista configurada para actualizarse cada 15 minutos con respecto a un origen que se actualiza dos veces al día genera un gasto innecesario por la diferencia sin obtener ningún beneficio. Adapte el programa de actualización a la frecuencia con la que realmente cambian los datos subyacentes y, luego, controle directamente el gasto del pipeline:

Pilar 4: Paneles y monitoreo continuo

Las alertas son activadores puntuales. Los paneles ofrecen un contexto continuo. Databricks ofrece paneles de uso precompilados que los administradores de cuentas pueden importar en cualquier espacio de trabajo habilitado para Unity Catalog. Estos cubren tendencias de gasto, análisis de los N principales, filtrado de etiquetas y desgloses por almacén. Para el monitoreo personalizado, dos consultas son especialmente útiles:

Costo de SQL warehouse por equipo

Uso de SQL no atribuido (brecha de atribución)

El uso de SQL sin etiquetar es su brecha de atribución, un gasto de almacén que no se puede rastrear a ningún equipo. Redúzcalo a cero.

Raiffeisen Bank International creó su propia plataforma de monitoreo y previsión de costos directamente sobre las tablas del sistema de Databricks, con visibilidad por almacén, por usuario y por carga de trabajo. El beneficio fue tanto cultural como técnico: cargas de trabajo de 3 a 4 veces más rápidas y, lo que es más importante, cuando los equipos pueden ver su propio gasto y se espera que lo expliquen, el comportamiento cambia sin necesidad de mandatos.

Pilar 5: Optimización, el pilar que realmente cambia la factura

Los primeros cuatro pilares consisten en ver su gasto. Este se centra en reducirlo, y es el que la mayoría de los equipos omiten. Comience con los dos cambios que mejoran el costo y el rendimiento al mismo tiempo.

Active la optimización predictiva para las tablas administradas de Unity Catalog. Databricks ejecuta OPTIMIZE, VACUUM y ANALYZE por usted según cómo se consulta realmente cada tabla, y con CLUSTER BY AUTO ajusta las claves de agrupación a medida que cambian los patrones de consulta. Menos datos escaneados significan consultas más rápidas y menos DBUs, sin necesidad de mantener un programa de mantenimiento. Está activado por defecto para las cuentas creadas a partir del 11 de noviembre de 2024, y llegará a las cuentas más antiguas a lo largo de 2026.

Use por defecto almacenes serverless para aprovechar las ventajas económicas de inicio y tiempo de inactividad descritas anteriormente; para la mayoría de los equipos, ahí radica la mayor parte del ahorro, sin esfuerzo continuo.

A partir de ahí, vale la pena ajustar algunas configuraciones:

• Reduzca el tiempo de parada automática. Pro y Classic tienen por defecto 45 minutos de inactividad antes de detenerse; serverless tiene por defecto 10, y puede bajarlo a 5 en la UI o a 1 a través de la API. Cada minuto de inactividad en un almacén de BI después de que se cierra el último panel es un desperdicio.
• Establezca un tiempo de espera de instrucciones (Beta: habilite la vista previa y luego configúrelo por almacén a través de la API). Una consulta descontrolada no debería consumir un fin de semana entero de cómputo; manténgalo corto en los almacenes de BI y más largo en los de ETL.
• Asigne un almacén predeterminado (Admin Settings > Compute) para que un vistazo rápido a diez filas no active un clúster del tamaño de ETL, y comience con Small o Medium en lugar de sobredimensionar.
• Escale vertical u horizontalmente con un propósito. Escalar verticalmente (tamaños más grandes, ahora hasta 5X-Large [Public Preview]) hace que una sola consulta pesada sea más rápida; escalar horizontalmente (un número máximo de clústeres más alto) atiende a más usuarios simultáneos. Elegir la opción incorrecta es un error común y costoso.

La capa de datos también importa: OPTIMIZE, VACUUM y liquid clustering reducen, cada uno, el cómputo que necesita una consulta, y eso se acumula en miles de consultas de BI al día.

En el fondo, la mayoría de los problemas de costos son problemas de consultas. Una clave de combinación faltante o un SELECT * contra una tabla ancha cuesta lo mismo sin importar cómo esté configurado el almacén, y la atribución del Pilar 1 es lo que le indica qué consultas y paneles debe corregir.

Conclusiones clave

1. Integre serverless y la atribución en la plataforma desde el primer día. Use por defecto almacenes SQL Serverless para obtener un inicio instantáneo, escalado automático y sin costos por tiempo de inactividad, y aplique etiquetas personalizadas desde el principio, porque el uso no atribuido es invisible y el uso invisible siempre crece.

2. Presupueste y alerte de manera proactiva, en más de un nivel. Combine presupuestos por equipo para fomentar la responsabilidad con un presupuesto para toda la cuenta para detectar anomalías, y reciba alertas sobre el ritmo de gasto, no solo sobre los límites, de modo que se entere de un exceso de costos con tiempo para actuar en lugar de después de que ocurra.

3. Haga que el gasto sea visible y conviértalo en parte de la cultura.  El ahorro más duradero proviene de la transparencia, no de las restricciones, así que coloque los paneles de costos donde trabajan los equipos. Como descubrió RBI, cuando los equipos pueden ver su propio gasto, el comportamiento cambia sin necesidad de mandatos.

Primeros pasos

Esta es la forma más rápida de comenzar y controlar las facturas antes de que se disparen:

• Cree su primer presupuesto en la consola de la cuenta. 
• Atribuya el uso etiquetando sus consultas y SQL warehouse
• Monitoree los costos con las tablas del sistema, consulte system.billing.usage para obtener información específica del almacén
• Comportamiento de escalado y dimensionamiento de SQL warehouse, comprenda la economía de IWM y serverless
• Mejores prácticas de optimización de costos, dimensionamiento de almacenes, Photon y optimización de Delta Lake
• Del caos al control: un viaje de madurez de costos con Databricks, el marco de trabajo crawl-walk-run para la madurez de FinOps

¿Está listo para tomar el control de los costos de su almacén de datos en la nube? Configure una cuenta de prueba gratuita de Databricks, cree su primer almacén SQL Serverless y configure un presupuesto con alertas por correo electrónico en la consola de la cuenta. Toma cinco minutos y no cuesta nada.

Para profundizar en la observabilidad de costos, explore la documentación de las tablas del sistema de facturación e importe el panel de uso precompilado para comenzar a monitorear el gasto desde el primer día.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original