Query-Timeouts sind ein wirksames Mittel, um in Snowflake die Kosten im Griff zu behalten und ungewollte Kostenspitzen zu verhindern. In diesem Beitrag erfahren Sie, warum sie sinnvoll sind und wie Sie sie konfigurieren.
Was sind Query-Timeouts in Snowflake?
Ein Query-Timeout ist eine Einstellung, die verhindert, dass Snowflake-Abfragen zu lange laufen. Überschreitet eine Abfrage die festgelegte Dauer, bricht Snowflake sie automatisch ab.
Warum überhaupt ein Timeout?
In Snowflake laufen Abfragen auf virtuellen Warehouses, und abgerechnet wird jede Sekunde, in der ein Warehouse aktiv ist. Wer also eine ineffiziente Abfrage auf einem großen Datensatz startet und dafür 2 Tage auf einem Extra-Large-Warehouse benötigt, zahlt für diese eine Abfrage knapp 2.000 US-Dollar.
Mit einem niedrigeren Query-Timeout behalten Snowflake-Kunden ihre Kosten im Griff und vermeiden unerwartete Gebühren durch lang laufende Abfragen.
Wie hoch ist das Standard-Query-Timeout in Snowflake?
Der Standardwert für Query-Timeouts in Snowflake liegt bei 2 Tagen (172.800 Sekunden) – sowohl für Sessions als auch für Warehouses (Quelle). Angesichts dieses sehr großzügigen Standardwerts sollten die meisten Snowflake-Kunden ihre Query-Timeouts deutlich verkürzen.
So konfigurieren Sie Query-Timeouts in Snowflake
Query-Timeouts lassen sich auf verschiedenen Ebenen setzen: kontoweit, pro Nutzer, für eine einzelne Session oder für ein bestimmtes Warehouse. Alle Varianten nutzen den Parameter STATEMENT_TIMEOUT_IN_SECONDS (Dokumentation).
Session-Query-Timeout
Den aktuellen Timeout-Wert für die laufende Session prüfen Sie mit folgendem Befehl:
1show parameters for session
Um das Query-Timeout der aktuellen Session auf 1 Stunde zu setzen, führen Sie aus:
1alter session set statement_timeout_in_seconds = 3600
Nutzer-Query-Timeout
Den aktuellen Timeout-Wert eines bestimmten Nutzers (analytics_user) zeigen Sie so an:
1show parameters for user analytics_user
Um das Query-Timeout dieses Nutzers auf 1 Stunde zu setzen, führen Sie aus:
1alter user analytics_user set statement_timeout_in_seconds = 3600
Kontoweites Timeout
Den aktuellen Timeout-Wert auf Kontoebene prüfen Sie mit:
1show parameters for account
Dieser steht in der Regel auf dem Standardwert von 2 Tagen (172.800). Um ihn auf 1 Tag zu reduzieren, führen Sie aus:
1alter account set statement_timeout_in_seconds = 86400
Warehouse-Query-Timeout
Den aktuellen Timeout-Wert eines bestehenden Warehouses prüfen Sie wie folgt. Im Beispiel heißt das Warehouse COMPUTE.
1show parameters for warehouse compute
Um das Query-Timeout des Warehouses auf 1 Stunde zu ändern, führen Sie aus:
1alter warehouse compute set statement_timeout_in_seconds = 3600
Das Timeout lässt sich auch direkt beim Anlegen eines neuen Warehouses festlegen:
create warehouse compute
warehouse_size = 'XSMALL'
statement_timeout_in_seconds = 3600
;
Welches Query-Timeout greift, wenn mehrere gesetzt sind?
Sind mehrere Timeout-Einstellungen gleichzeitig aktiv, setzt Snowflake stets den niedrigsten Wert durch. Hat eine Session beispielsweise ein Timeout von 1 Stunde und das Warehouse eines von 10 Minuten, bricht Snowflake jede Abfrage ab, die länger als 10 Minuten läuft.
So konfigurieren Sie Task-Timeouts in Snowflake
Timeouts für Snowflake-Tasks werden über den Parameter USER_TASK_TIMEOUT_MS (Dokumentation) gesteuert. Der Standardwert beträgt 1 Stunde (Quelle). Beachten Sie: Die Einheit ist hier Millisekunden – anders als bei Query-Timeouts, wo in Sekunden gerechnet wird.
Wie bei Warehouses und Sessions können Sie den aktuellen Wert mit show parameters for task my_task einsehen. Um das Task-Timeout auf 60 Sekunden zu setzen, führen Sie alter task my_task set user_task_timeout_ms = 60000 aus.
Werden durch Snowflake-Timeouts abgebrochene Abfragen und Tasks trotzdem berechnet?
Ja. Snowflake berechnet jede Sekunde, in der ein virtuelles Warehouse aktiv ist. Läuft eine Abfrage 4 Stunden lang, bevor Snowflake sie abbricht, werden dem Kunden die vollen 4 Stunden Warehouse-Aktivität in Rechnung gestellt.
Ian Whitestone·Co-founder & CEO von SELECT
Ian ist Co-founder und CEO von SELECT, einer SaaS-Plattform für Kostenmanagement und Optimierung in Snowflake. Vor SELECT leitete er 6 Jahre lang Full-Stack-Teams für Data Science und Engineering bei Shopify und Capital One. Bei Shopify verantwortete er die Optimierung des Data Warehouse und den Ausbau der Kostentransparenz.