Snowflake fällt fast nie aus. Abfragen laufen durch, Dashboards laden und der nächtliche dbt-Lauf wird grün, und genau deshalb merkt niemand, wenn der Account still und leise doppelt so teuer wird. Die üblichen Sicherheitsnetze, Resource Monitors, Auto-Suspend und das eine oder andere Kosten-Dashboard, sind für Ausfälle und Kontingente gebaut, nicht für langsame, leise Verhaltensänderungen.

digna ist eine Data Quality & Observability Plattform, und eines der Dinge, die Sie damit beobachten können, ist die Plattform, auf der Ihre Daten laufen. Dieses Video nimmt sechs Annahmen, die viele Snowflake-Teams über ihre Rechnung haben, und prüft jede davon anhand der Account-Usage-Views eines fiktiven Pharmaunternehmens in dignas Demo-Projekt.

Alles steht in Account Usage

Snowflake erfasst bereits alles, was Sie brauchen, in SNOWFLAKE.ACCOUNT_USAGE: Warehouse-Metering, Query-Historie, Warehouse-Last, Serverless-Credits, Speicher, Task-Läufe und Logins. digna liest diese Views direkt dort, wo sie liegen, und lernt, wie normal für jedes Warehouse, jedes dbt-Modell und jeden Bericht aussieht, einschließlich Wochenrhythmus und Monatsabschluss.

Sechs Annahmen, und was die Daten sagen

„Ein Resource Monitor wird es uns sagen.“ Das tut er, sobald ein Kontingent aufgebraucht ist. Ein Transformations-Warehouse, das jede Woche ein wenig wächst, löst nie etwas aus: In der Demo stieg es von etwa 17 Credits pro Tag im Februar auf über 30 im Juli, ohne einen einzigen roten Tag, und dignas Analytics setzte es an die Spitze des Trend-Rankings, lange bevor irgendein Kontingent gegriffen hätte.

„Ein größeres Warehouse läuft einfach schneller.“ Es rechnet auch nach Größe ab. Als das Warehouse der Analysten für eine Demo von Small auf Extra Large vergrößert und danach von niemandem zurückgesetzt wurde, stiegen seine Credits pro aktiver Stunde über Nacht auf mehr als das Siebenfache, und digna meldete es noch am selben Tag.

„Auto-Suspend kümmert sich um Leerlauf.“ Bis jemand es ändert. Als das Auto-Suspend der Analysten auf sechzig Minuten erhöht wurde, erkannte eine einfache Regel auf dem täglichen Warehouse-Snapshot, kein Warehouse über zehn Minuten, es noch am selben Tag.

„Wenn eine Abfrage durchgelaufen ist, ist alles in Ordnung.“ Ein kartesischer Join lief sechs Stunden und scannte rund zehn Terabyte auf einem Warehouse, das normalerweise ein halbes Terabyte am Tag liest, und drei Wochen später verlor ein Bericht sein Partition Pruning und scannte fast das Dreifache seiner üblichen Datenmenge. Beide liefen durch, und beide wurden gemeldet.

„Serverless kümmert sich um sich selbst.“ Das tut es, und es stellt es in Rechnung. Als Search Optimization für große Vertriebstabellen eingeschaltet wurde, stiegen die Credits an einem Tag auf mehr als das Achtfache, und als ein neues semantisches Modell riesiges SQL zu erzeugen begann, stiegen die Cloud Services auf dem Reporting-Warehouse von etwa 10 auf 60 % seiner Rechenleistung.

„Wenn etwas kaputtgeht, erfahren wir davon.“ Manchmal. Zwölf von siebenunddreißig dbt-Tasks scheiterten in einer Nacht am selben Kompilierungsfehler, eine Änderung an einem Vertriebs-View legte 176 Dashboard-Abfragen lahm, und ein Tag brachte 238 fehlgeschlagene Logins mehr als der Vortag. digna erkannte alle drei mit einfachen Regeln auf den Account-Usage-Views.

Die Metriken hinter diesen Prüfungen finden Sie unter wie Sie Nutzung, Kosten und Performance von Snowflake verfolgen.

Was digna in Ruhe lässt

Genauso wichtig ist, was nicht gemeldet wird. Zum Monatsende verbraucht das Finance-Warehouse fast anderthalbmal so viel wie an einem normalen Tag, und weil digna den Abschlusskalender gelernt hat, bleibt es grün, während ein fester Alarm jeden einzelnen Monat auslösen würde.

Eine Seite am Morgen, oder eine Frage an Ihren Assistenten

All das landet jeden Morgen auf einer Seite, fast überall grün und nur dort rot, wo sich über Nacht etwas bewegt hat. Und wenn Sie lieber fragen als schauen, fragen Sie Ihren KI-Assistenten, welche Snowflake-Warehouses in diesem Jahr teurer geworden sind: Mit dem digna-Skill fragt er dignas MCP-Server und antwortet aus dignas eigenen Ergebnissen, Warehouse für Warehouse, ohne jemals die Daten selbst zu lesen.

Alles läuft in Ihrer eigenen Umgebung, direkt neben den Account-Usage-Views, die es liest, sodass nichts jemals Ihr Unternehmen verlässt.

Buchen Sie eine Demo und sehen Sie es auf Ihrem eigenen Snowflake-Account.

Häufig gestellte Fragen

Welche Snowflake-Views nutzt digna?

In der Demo: WAREHOUSE_METERING_HISTORY für Credits pro Warehouse und aktiver Stunde, QUERY_HISTORY für Laufzeit, gescannte Bytes und Fehler, WAREHOUSE_LOAD_HISTORY für Warteschlangen, METERING_DAILY_HISTORY für Serverless-Credits, Speicher, TASK_HISTORY für dbt-Tasks und LOGIN_HISTORY für fehlgeschlagene Logins, dazu ein täglicher Snapshot von SHOW WAREHOUSES.

Reicht ein Resource Monitor nicht aus?

Ein Resource Monitor greift, wenn ein Credit-Kontingent aufgebraucht ist. Er sagt Ihnen nicht, dass ein Warehouse in fünf Monaten um 80 % gewachsen ist, während jeder Tag normal aussah; dignas Trend-Ranking tut das, lange bevor das Kontingent erreicht ist.

Wie bemerkt digna einen vergessenen Warehouse-Resize?

Es verfolgt die Credits pro aktiver Stunde für jedes Warehouse. Eine Größenstufe verdoppelt diesen Wert, sodass ein Resize noch am selben Tag als Sprung gegenüber der gelernten Baseline des Warehouses sichtbar wird, unabhängig davon, wie ausgelastet es war.

Lösen Spitzen zum Monats- und Quartalsende Alarme aus?

Nein. Saisonalität ist Teil der gelernten Baseline, deshalb bleibt ein Finance-Warehouse, das zum Monatsende anderthalbmal so viel verbraucht, grün, während derselbe Sprung an einem gewöhnlichen Tag gemeldet würde.

Ist Snowflake die einzige Plattform, die digna beobachten kann?

Nein. Die Datenplattform zu beobachten ist ein Anwendungsfall von digna, der Data Quality & Observability Plattform; derselbe Ansatz funktioniert für Databricks, Teradata und andere Warehouses, zusätzlich zur Überwachung der Daten selbst.