Un heartbeat de Tableau le costó 14.000 dólares a un equipo en Databricks
La integración de BI mantuvo activo un almacén SQL sin que se detuviera, agotando el consumo mensual en 48 horas por una configuración de permisos demasiado amplia.
Un equipo de ingeniería de datos vio cómo su factura de Databricks subía de forma exponencial durante un fin de semana, alcanzando el 80% del gasto mensual previsto en solo 48 horas. La causa no fue un fallo de código ni un bucle infinito en la carga, sino una interacción silenciosa entre una herramienta de Business Intelligence y el servicio Databricks Serverless SQL Warehouse.
El incidente surgió tras desplegar una nueva tubería de datos el viernes. Las pruebas de integración pasaron y los datos llegaron a tiempo, pero el consumo de DBU (Databricks Units) se disparó. Al revisar los logs del clúster y el historial de consultas, no se detectó nada anómalo. La primera pista errónea apuntaba al parámetro "Auto-stop", configurado para 10 minutos de inactividad. Sin embargo, el almacén no estaba inactivo: estaba siendo mantenido vivo por un "ghost".
El culpable era la conexión de Tableau. El dashboard realizaba consultas a system.information_schema como pulso de actividad cada 8 minutos. Como Databricks interpreta cualquier actividad de sesión como "consulta activa", el temporizador de 10 minutos se reiniciaba constantemente, evitando que el almacén entrara en estado de reposo. El problema se agravó por dos factores: se utilizaba un principal de servicio con permisos amplios de CAN USE, lo que permitía acceder a catálogos de sistema costosos, y el almacén estaba dimensionado como "Large", con una tasa de consumo mucho mayor que la necesaria para un simple ping de latencia sub-milisegundo.
La solución inmediata fue cortar la conexión desde la herramienta de BI y reducir el "Auto-stop" a 1 minuto. A largo plazo, el equipo reestructuró las políticas de infraestructura. Separaron las cargas de trabajo, asignando un almacén "Small" para los dashboards con alta frecuencia de pulsos y reservando el "Large" para consultas ad-hoc y transformaciones ELT pesadas. Además, restringieron los permisos de los principales de servicio a esquemas específicos de Unity Catalog con acceso solo de lectura, eliminando la capacidad de consultar el information_schema general.
Para prevenir recidivas, implementaron controles en el código. Establecieron una política de dimensionamiento estricta donde ningún almacén de producción puede superar la talla "Medium" sin una exención documentada en un Pull Request, validada mediante una estimación de costos usando la API de facturación. También añadieron una alarma de presupuesto basada en una función Lambda que monitoriza la tasa de quemado diaria y alerta en Slack si supera un 20% de variación respecto a la media móvil de 7 días.
El caso subraya que "serverless" no exime la gestión del ciclo de vida de las sesiones. Al eliminar la administración de nodos, la responsabilidad recae en monitorizar las conexiones y los permisos. Un heartbeat inofensivo puede convertirse en un gasto descontrolado si no se controla la duración de la sesión y el alcance de los accesos.
