Snowflake Kosten optimieren ohne Performanceverlust
Dieser Leitfaden konzentriert sich auf das Snowflake Kosten optimieren für Data Engineers, Analytics Engineers und Snowflake Administratoren, die für das Design und den Betrieb von Snowflake Workloads verantwortlich sind. Er setzt Vertrautheit mit Warehouses, Tabellen und Query Ausführung voraus und fokussiert sich auf praktische Änderungen, die den Credit Verbrauch direkt reduzieren.
Snowflake macht das Skalieren von Analytics einfach. Genau diese Flexibilität kann jedoch unbemerkt zu steigenden Kosten führen, wenn sie nicht aktiv gesteuert wird.
Die meisten Snowflake Ausgaben werden durch drei zentrale Faktoren bestimmt:
- Compute: Virtual Warehouses, die Queries ausführen, Daten laden oder Transformationen durchführen
- Storage: Aktive Daten, Time Travel, Fail Safe und historische Micro Partitions
- Services: Metadatenoperationen und Hintergrunddienste
In der Praxis ist Compute nahezu immer der dominante Kostentreiber, insbesondere wenn Warehouses überdimensioniert sind, unnötig lange laufen oder ineffiziente Workloads ausführen.
Um die Kontrolle zu behalten, stellt Snowflake integrierte Kostentransparenz über die Cost Management Views in der Benutzeroberfläche bereit. Dort können Sie:
- Credit Verbrauch im Zeitverlauf nachverfolgen
- Ausgaben pro Warehouse aufschlüsseln
- Kostenanstiege und langlaufende Workloads identifizieren
- Erwartungen und Budgets auf Basis realer Daten definieren
Monitoring ist der erste Schritt. Nachhaltige Einsparungen entstehen jedoch durch bewusste Design und Konfigurationsentscheidungen.
In diesem ersten Teil unserer Blog-Serie zeigen wir, wie Sie Snowflake Kosten optimieren können durch gezielte Anpassungen an Virtual Warehouses und Tabellenkonfigurationen.
Im zweiten Blogbeitrag analysieren wir, wie Workload Konfiguration, Datenlade Muster und integrierte Snowflake Kontrollmechanismen dabei helfen können, Snowflake Kosten zu optimieren.
1. Snowflake Compute Kosten optimieren durch Warehouse Konfiguration
1.1 Auto Suspend Einstellungen optimieren, um Snowflake Kosten zu reduzieren
Compute wird für jede Sekunde berechnet, in der ein Virtual Warehouse läuft, mit einer Mindestabrechnung von 60 Sekunden pro Start. Snowflake suspendiert ein Virtual Warehouse automatisch nach einer definierten Leerlaufzeit. Der Standardwert für Auto Suspend beträgt 10 Minuten, also 600 Sekunden.
Ist der Auto Suspend Wert höher als 60 Sekunden gesetzt, läuft das Warehouse weiter und verursacht Kosten, auch wenn es keine Queries verarbeitet. Daher ist die korrekte Einstellung von Auto Suspend entscheidend für die Kostenkontrolle.
Für ETL und Batch Workloads sollte Auto Suspend typischerweise auf 60 Sekunden gesetzt werden, um Leerlaufkosten zu minimieren. BI und interaktive Workloads profitieren hingegen von 90 bis 120 Sekunden, um Cache zu erhalten und die Benutzererfahrung zu verbessern. Die effektivste Strategie besteht darin, ETL und BI in separate Warehouses mit jeweils angepassten Auto Suspend Einstellungen zu trennen, um sowohl Kosten als auch Performance zu optimieren.
Warum Auto Suspend unter 60 Sekunden zu doppelten Kosten führen kann
Ein Auto Suspend Wert unter 60 Sekunden wird nicht empfohlen, da er unbeabsichtigt zu höheren Kosten durch wiederholte Mindestabrechnungen führen kann.
Angenommen, ein Warehouse ist auf 30 Sekunden Auto Suspend konfiguriert. Eine Query läuft 10 Sekunden, danach wird das Warehouse nach 30 Sekunden Inaktivität suspendiert. Obwohl das Warehouse nur 30 Sekunden aktiv war, berechnet Snowflake dennoch die volle Mindestlaufzeit von 60 Sekunden. Wenn kurz darauf eine weitere Query eingeht, muss das Warehouse erneut gestartet werden, wodurch eine weitere Mindestabrechnung von 60 Sekunden entsteht. Zwei kurze Aktivitätsphasen können so zu 120 Sekunden berechnetem Compute führen, obwohl das Warehouse nur einen Bruchteil dieser Zeit tatsächlich genutzt wurde.
Best Practice: Auto Suspend auf 60 Sekunden für ETL und Batch Workloads und auf 90 bis 120 Sekunden für BI und interaktive Workloads setzen.
1.2 Virtual Warehouses richtig dimensionieren
Überdimensionierte Virtual Warehouses verursachen häufig einen erheblichen Anteil der Snowflake Compute Kosten.
Da Snowflake Preise auf Basis von Ausführungszeit multipliziert mit Credit Verbrauchsrate berechnet, kostet eine Query, die auf einem Medium Warehouse doppelt so schnell läuft wie auf einem Small Warehouse, in der Regel gleich viel. Sobald jedoch die Performance ein Plateau erreicht, erhöhen größere Warehouses lediglich die Kosten, ohne nennenswerte Geschwindigkeitsverbesserungen zu liefern. Dieses Verhalten zeigt sich typischerweise darin, dass die Ausführungszeit abflacht, während die Kosten mit zunehmender Warehouse Größe weiter steigen.
Empfohlene Vorgehensweise zur Bestimmung der optimalen Warehouse Größe
- Wenn möglich mit einem X Small Warehouse starten
- Die Warehouse Größe schrittweise erhöhen und die Query Laufzeit beobachten
- Das Hochskalieren beenden, sobald die Ausführungszeit nicht mehr proportional sinkt, zum Beispiel nicht mehr halbiert wird. Das zeigt, dass das Warehouse nicht mehr vollständig ausgelastet ist
- Für das beste Verhältnis aus Kosten und Performance sollte eine Größe unterhalb des Punkts mit abnehmendem Grenznutzen gewählt werden. –> Beispiel: Wenn eine Erhöhung von Medium auf Large die Query Laufzeit nur um 25 Prozent reduziert, ist Medium in der Regel die kosteneffizientere Wahl.
- Größere Warehouses sollten nur dann eingesetzt werden, wenn explizit schnellere Performance erforderlich ist, wobei zu beachten ist, dass der Nutzen ab einem bestimmten Punkt abnimmt.
Best Practice: Klein starten, schrittweise skalieren und dort stoppen, wo die Performancegewinne abflachen. Die kleinste Größe wählen, die die Anforderungen erfüllt.
1.3 Minimum Cluster Count auf 1 setzen
In der Snowflake Enterprise Edition und höher ermöglichen Multi Cluster Warehouses das parallele Starten zusätzlicher Cluster, um Lastspitzen bei gleichzeitigen Abfragen abzufangen. Um unnötige Compute Kosten zu vermeiden, sollte der Minimum Cluster Count stets auf 1 gesetzt werden.
Snowflake provisioniert bei steigender Last automatisch zusätzliche Cluster bis zum definierten Maximum und tut dies mit minimaler Startzeit. Wird der Minimum Cluster Count höher als 1 gesetzt, bleiben zusätzliche Cluster dauerhaft aktiv, auch wenn sie nicht benötigt werden, und verursachen vollständig abrechenbare Compute Kosten.
Durch das Festlegen des Minimum Cluster Count auf 1 wird sichergestellt, dass zusätzliche Cluster nur dann gestartet werden, wenn die Last dies rechtfertigt. So wird Überprovisionierung vermieden und gleichzeitig Performance bei Lastspitzen sichergestellt.
Best Practice: Minimum Cluster Count immer auf 1 setzen und Snowflake nur bei tatsächlichem Parallelitätsbedarf skalieren lassen.
1.4 Virtual Warehouses konsolidieren
Ein häufiges Kostenproblem in Snowflake Umgebungen ist Warehouse Sprawl. Wenn zu viele Warehouses existieren, sind viele davon unterausgelastet, führen nur selten Queries aus oder befinden sich im Leerlauf, verbrauchen aber dennoch Credits. Die Kosteneffizienz steigt, wenn Workloads in so wenige Warehouses wie praktikabel konsolidiert werden und diese gut ausgelastet sind.
Anstatt Warehouses nach Daten Domänen zu strukturieren, zum Beispiel getrennt für Marketing und Finance, ist es in der Regel effizienter, sie nach Workload Typ zu organisieren. Beispielsweise führt ein Warehouse für Datenladung, eines für Transformationen und eines für BI oder Nutzerabfragen meist zu besserer Auslastung und geringeren Gesamtkosten.
Workloads innerhalb derselben Kategorie weisen oft ähnliche Performance Eigenschaften auf. Datenlade Jobs tolerieren beispielsweise Warteschlangen und können effizient auf einem gemeinsamen Multi Cluster X Small Warehouse laufen. Interaktive oder nutzernahe Abfragen profitieren dagegen typischerweise von größeren Warehouses, um Latenz zu minimieren.
Best Practice: Warehouses nach Workload Typ strukturieren, nicht nach Team oder Fachbereich.
2. Wie Tabellenkonfiguration Snowflake Storage und Query Kosten beeinflusst
2.1 Tabellen korrekt clustern
Eine der effektivsten Methoden zur Optimierung von Query Performance und zur Reduzierung von Kosten ist Query Pruning. Dabei wird die Anzahl der gescannten Micro Partitions begrenzt.
Das Lesen von Micro Partitions ist einer der teuersten Schritte in Snowflake Queries, da der Datenzugriff remote über das Netzwerk erfolgt.
Query Pruning funktioniert, wenn Filter in WHERE Klauseln, Joins oder Subqueries irrelevante Micro Partitions ausschließen können. Damit dies effektiv funktioniert, muss die Tabelle auf Spalten geclustert sein, die den Query Mustern entsprechen, sodass jede Micro Partition einen engen Wertebereich enthält.
Beispiel für eine orders Tabelle mit häufigem Filter auf created_at:
CREATE TABLE my_schema.my_table (
id NUMBER,
created_at TIMESTAMP_NTZ,
data VARIANT
)
CLUSTER BY (created_at);Clustering lohnt sich insbesondere für Tabellen mit einem hohen Verhältnis von Abfragen zu DML Operationen wie INSERT, UPDATE oder DELETE. Das bedeutet, dass die Tabelle häufig gelesen und nur selten verändert wird. Vor Einführung von Clustering empfiehlt Snowflake ausdrücklich, repräsentative Queries zu testen und Performance Baselines zu definieren.
Korrektes Clustering reduziert die pro Query gescannten Daten, verbessert die Performance und senkt Compute Kosten.
Best Practice: Auf Spalten clustern, die häufig in Filtern oder Joins verwendet werden.
2.2 Unbenutzte Tabellen löschen
Unbenutzte Tabellen und Time Travel Sicherungen verbrauchen Storage und tragen langfristig zu Snowflake Kosten bei. Eine regelmäßige Identifikation und Entfernung nicht mehr benötigter Tabellen kann den Credit Verbrauch reduzieren.
Wie man ungenutzte Tabellen identifiziert
Sie können Snowflakes INFORMATION_SCHEMA.TABLES abfragen, um Änderungen an der Tabellenstruktur (z. B. hinzugefügte Spalten, geänderte Datentypen) oder das Auftreten von datenverändernden DML-Anweisungen (INSERT, UPDATE, DELETE, MERGE) zu ermitteln.
SELECT table_schema,
table_name,
last_altered,
created
FROM information_schema.tables
ORDER BY last_altered ASC;Wenn festgestellt werden soll, welche Tabellen in letzter Zeit nicht abgefragt wurden, sollte zusätzlich die Query Historie genutzt werden, beispielsweise die QUERY_HISTORY View im SNOWFLAKE.ACCOUNT_USAGE Schema.
Hier ist ein einfaches Beispiel:
SELECT DISTINCT
t.table_schema,
t.table_name,
MAX(q.start_time)AS last_query_time
FROM snowflake.account_usage.tables t
LEFT JOIN snowflake.account_usage.query_history q
ON q.query_text ILIKE'%'|| t.table_name||'%'
WHERE t.table_schema='YOUR_SCHEMA'
GROUP BY t.table_schema, t.table_name
ORDER BY last_query_timeDie Kombination aus INFORMATION_SCHEMA.TABLES und Query Historie liefert das genaueste Bild über ungenutzte Tabellen.
Best Practice: Metadaten und Query Historie kombinieren, um unbenutzte Tabellen sicher zu identifizieren und zu entfernen.
2.3 Data Retention durch Time Travel reduzieren
Die Time Travel Funktion von Snowflake speichert Kopien aller Änderungen an einer Tabelle für einen konfigurierten Zeitraum und erhöht dadurch Storage Nutzung und Kosten. Die Standard Retention beträgt einen Tag und ist für alle Snowflake Accounts automatisch aktiviert. Eine Retention von 0 Tagen deaktiviert Time Travel für das jeweilige Objekt.
Die Reduzierung der Time Travel Retention senkt Storage Verbrauch und damit verbundene Snowflake Credits, ohne aktive Workloads zu beeinträchtigen.
Für nicht kritische Tabellen wie Staging, Zwischenlayer oder Entwicklungsumgebungen kann Time Travel auf 0 Tage gesetzt werden, wenn Daten temporär sind und leicht aus Quellsystemen reproduziert werden können. Für produktive und geschäftskritische Tabellen sollte die Standard Retention von einem Tag bestehen bleiben, um versehentliche Löschungen oder fehlerhafte Merges abzusichern.
Um die Datenaufbewahrungsfrist für eine bestimmte Tabelle zu verkürzen:
alter table my_non_critical_table set data_retention_time_in_days=0;Best Practice: Retention Perioden für nicht kritische Tabellen reduzieren.
2.4 Transient Tabellen für nicht kritische Daten verwenden
Die Fail Safe Funktion ist die letzte Schutzschicht in Snowflake. Fail Safe wird erst nach Ablauf der Time Travel Retention aktiv, gilt sieben Tage für permanente Tabellen und kann nicht konfiguriert werden.
Für Tabellen, die im Rahmen von ETL Prozessen regelmäßig gelöscht oder neu erstellt werden oder deren Daten extern gesichert sind, bietet Fail Safe oft wenig Mehrwert, erhöht jedoch Storage Kosten.
Durch die Verwendung von Transient Tabellen statt permanenter Tabellen:
- wird Fail Safe nicht angewendet, wodurch sich der Storage Verbrauch reduziert wird.
- können auch Time Travel Kosten minimiert werden.
Transient Tabellen eignen sich ideal für Zwischenlayer oder temporäre ETL Tabellen, die keine vollständige historische Wiederherstellung benötigen.
Best Practice: Transient Tabellen für reproduzierbare oder nicht kritische ETL Daten verwenden.
Fazit
Dieser Beitrag beschreibt praktische Techniken zur Kostenoptimierung in Snowflake, die sich auf die Konfiguration virtueller Warehouses und Tabellen konzentrieren und sich an technische Teams richten, die Snowflake in der Produktion einsetzen. Er zeigt, wie kleine, bewusste Konfigurationsentscheidungen den Kreditverbrauch erheblich reduzieren können, ohne die Leistung oder Zuverlässigkeit zu beeinträchtigen.
Die wichtigsten Erkenntnisse:
- Compute ist der primäre Kostentreiber in Snowflake. Die größten Einsparungen entstehen durch korrekt dimensionierte Warehouses, richtig gesetztes Auto Suspend, Minimum Cluster Count von 1 und Konsolidierung nach Workload Typ.
- Tabellendesign beeinflusst sowohl Performance als auch Kosten. Korrektes Clustering verbessert Query Pruning. Das Löschen ungenutzter Tabellen, das Reduzieren von Time Travel Retention und die Nutzung von Transient Tabellen senken unnötigen Storage Overhead.
- Monitoring allein genügt nicht. Nachhaltige Kostensenkung erfordert die konsequente Ausrichtung von Warehouse und Tabellenkonfiguration auf reale Workload Muster und Nutzungsverhalten.
Im nächsten Beitrag werden wir uns mit Techniken zur Kostensenkung in drei weiteren Bereichen befassen: Workload-Konfiguration, Datenladungsmuster und Nutzung der integrierten Snowflake-Kontrollmechanismen.
Möchten Sie verstehen, woher Ihre Snowflake-Kosten wirklich stammen?
Wir helfen technischen Teams dabei, ihre Snowflake-Nutzung zu überprüfen und konkrete Möglichkeiten zur Kosteneinsparung zu identifizieren, ohne die Leistung oder Zuverlässigkeit zu beeinträchtigen. Nehmen Sie hier Kontakt mit uns auf.
FAQ zu Snowflake Kosten optimieren
Die wichtigsten Kostentreiber sind Compute, Storage und Cloud Services. Compute über Virtual Warehouses ist in den meisten Umgebungen der größte Faktor, insbesondere bei überdimensionierten oder lange laufenden Warehouses.
Durch korrekt dimensionierte Warehouses, Auto Suspend auf 60 Sekunden, reduzierte Job Frequenz und inkrementelle Verarbeitung statt Full Refreshes. Zusätzlich helfen Query Optimierung und Konsolidierung von Warehouses.
Ja, bei korrekter Konfiguration. 60 Sekunden verhindern unnötige Leerlaufzeiten. Werte unter 60 Sekunden können durch wiederholte Mindestabrechnungen Mehrkosten verursachen.
Für temporäre oder reproduzierbare Daten, die keinen erweiterten Schutz benötigen. Sie reduzieren Storage Kosten, da Fail Safe nicht angewendet wird.
Clustering verbessert das Query Pruning. Weniger gelesene Micro Partitions bedeuten geringere Compute Nutzung und schnellere Abfragen. Besonders wirksam ist es bei großen Tabellen mit häufigen Filtern auf bestimmten Spalten.