Snowflake casi nunca falla. Las consultas terminan, los dashboards cargan y la ejecución nocturna de dbt sale en verde, y precisamente por eso nadie se da cuenta cuando la cuenta se vuelve, sin hacer ruido, el doble de cara. Las redes de seguridad habituales, los resource monitors, el auto-suspend y algún que otro dashboard de costes, están pensadas para fallos y cuotas, no para cambios de comportamiento lentos y silenciosos.

digna es una plataforma de Data Quality & Observability, y una de las cosas que puede vigilar con ella es la plataforma sobre la que se ejecutan sus datos. Este vídeo toma seis creencias que muchos equipos de Snowflake tienen sobre su factura y contrasta cada una con las vistas de account usage de una farmacéutica ficticia en el proyecto de demostración de digna.

Todo está en account usage

Snowflake ya registra todo lo que necesita en SNOWFLAKE.ACCOUNT_USAGE: medición de warehouses, historial de consultas, carga de warehouses, créditos serverless, almacenamiento, ejecuciones de tasks y logins. digna lee esas vistas donde están y aprende cómo es lo normal para cada warehouse, cada modelo de dbt y cada informe, incluido el ritmo semanal y el cierre de mes.

Seis creencias, y lo que dicen los datos

«Un resource monitor nos avisará». Lo hará, cuando se agote una cuota. Un warehouse de transformación que crece un poco cada semana nunca dispara nada: en la demo pasó de unos 17 créditos al día en febrero a más de 30 en julio sin un solo día en rojo, y la analítica de digna lo colocó en lo más alto del ranking de tendencias mucho antes de que ninguna cuota hubiera saltado.

«Un warehouse más grande simplemente va más rápido». También factura según su tamaño. Cuando el warehouse de los analistas se amplió de small a extra large para una demo y nadie lo volvió a reducir, sus créditos por hora activa se multiplicaron por más de siete de la noche a la mañana, y digna lo señaló ese mismo día.

«El auto-suspend se ocupa del tiempo inactivo». Hasta que alguien lo cambia. Cuando el auto-suspend de los analistas se subió a sesenta minutos, una regla sencilla sobre la instantánea diaria de warehouses, ningún warehouse por encima de diez minutos, lo detectó ese mismo día.

«Si una consulta terminó, está bien». Un join cartesiano se ejecutó durante seis horas y escaneó unos diez terabytes en un warehouse que normalmente lee medio terabyte al día, y tres semanas después un informe perdió su partition pruning y escaneó casi el triple de sus datos habituales. Ambas terminaron, y ambas se señalaron.

«Serverless se cuida solo». Lo hace, y lo factura. Cuando se activó search optimization en grandes tablas de ventas, sus créditos se multiplicaron por más de ocho en un día, y cuando un nuevo modelo semántico empezó a generar SQL enorme, los cloud services del warehouse de reporting pasaron de alrededor del 10 al 60 % de su cómputo.

«Si algo se rompe, nos enteraremos». A veces. Doce de treinta y siete tasks de dbt fallaron una noche por el mismo error de compilación, un cambio en una vista de ventas rompió 176 consultas de dashboards y un día trajo 238 logins fallidos más que el anterior. digna detectó los tres con reglas sencillas sobre las vistas de account usage.

Para conocer las métricas detrás de estas comprobaciones, consulte cómo seguir el uso, el coste y el rendimiento de Snowflake.

Lo que digna deja en paz

Igual de importante es lo que no se señala. A fin de mes, el warehouse de finanzas consume casi la mitad más que un día normal y, como digna ha aprendido el calendario de cierre, sigue en verde, mientras que una alerta fija saltaría todos y cada uno de los meses.

Una página por la mañana, o una pregunta a su asistente

Todo ello llega cada mañana a una sola página, en verde casi en todas partes y en rojo solo donde algo se movió durante la noche. Y si prefiere preguntar en lugar de mirar, pregunte a su asistente de IA qué warehouses de Snowflake se encarecieron este año: con el skill de digna, consulta el servidor MCP de digna y responde a partir de los propios resultados de digna, warehouse por warehouse, sin leer nunca los datos.

Todo se ejecuta dentro de su propio entorno, junto a las vistas de account usage que lee, de modo que nada sale nunca de su organización.

Reserve una demo y véalo en su propia cuenta de Snowflake.

Preguntas frecuentes

¿Qué vistas de Snowflake utiliza digna?

En la demo: WAREHOUSE_METERING_HISTORY para créditos por warehouse y hora activa, QUERY_HISTORY para tiempo de ejecución, bytes escaneados y fallos, WAREHOUSE_LOAD_HISTORY para colas, METERING_DAILY_HISTORY para créditos serverless, almacenamiento, TASK_HISTORY para tasks de dbt y LOGIN_HISTORY para logins fallidos, además de una instantánea diaria de SHOW WAREHOUSES.

¿No basta con un resource monitor?

Un resource monitor actúa cuando se agota una cuota de créditos. No le dice que un warehouse ha crecido un 80 % en cinco meses mientras cada día parecía normal; el ranking de tendencias de digna sí, mucho antes de que se alcance la cuota.

¿Cómo detecta digna un resize de warehouse olvidado?

Sigue los créditos por hora activa de cada warehouse. Cada escalón de tamaño duplica esa cifra, así que un resize aparece el mismo día como un salto frente a la línea base aprendida del warehouse, independientemente de lo ocupado que estuviera.

¿Los picos de fin de mes y de trimestre disparan alertas?

No. La estacionalidad forma parte de la línea base aprendida, por lo que un warehouse de finanzas que consume la mitad más a fin de mes sigue en verde, mientras que el mismo salto en un día cualquiera se señalaría.

¿Es Snowflake la única plataforma que digna puede observar?

No. Observar la plataforma de datos es un caso de uso de digna, la plataforma de Data Quality & Observability; el mismo enfoque funciona con Databricks, Teradata y otros warehouses, además de la monitorización de los propios datos.