Optimieren der Kosten¶
Unter diesem Thema werden Möglichkeiten zur Optimierung von Snowflake erörtert, um Kosten zu senken und Ihre Ausgaben zu maximieren.
Kosteneinblicke: Möglichkeiten für Einsparungen finden¶
Snowflake bietet Kosteneinblicke, die Möglichkeiten zur Optimierung von Snowflake für Kosten innerhalb eines bestimmten Kontos aufzeigen. Diese Einblicke werden wöchentlich berechnet und aktualisiert.
Jeder Einblick zeigt an, wie viele Credits oder TBs durch die Optimierung von Snowflake eingespart werden können.
Bemerkung
Sie müssen über die Rolle ACCOUNTADMIN verfügen, um Kosteneinblicke zu erhalten.
So greifen Sie auf die Kachel Cost Insights zu:
Melden Sie sich bei Snowsight an.
Wechseln Sie zur Rolle ACCOUNTADMIN.
Wählen Sie im Navigationsmenü die Option Admin » Cost Management aus.
Wählen Sie die Registerkarte Account Overview aus.
Suchen Sie die Kachel Cost insights.
Jeder der folgenden Einblicke enthält Vorschläge, wie Sie Ihre Ausgaben optimieren können.
Einblick: Selten verwendete Tabellen mit automatischem Clustering
Einblick: Tabellen über 100 GB, bei denen Daten geschrieben, aber nicht gelesen werden
- Einblick: Selten verwendete Tabellen mit automatischem Clustering
Dieser Einblick identifiziert Tabellen mit Automatic Clustering, die weniger als 100 Mal pro Woche von diesem Konto abgefragt werden.
Die Aktivierung des automatischen Clustering für eine Tabelle kann die Leistung von Abfragen über diese Tabelle erheblich verbessern. Da sich die Tabelle jedoch ändert, muss Snowflake serverlose Computeressourcen verwenden, um sie in einem gut geclusterten Zustand zu halten. Wenn die Anzahl der Abfragen, die auf der Tabelle ausgeführt werden, minimal ist, rechtfertigen die entstehenden Kosten möglicherweise nicht die Leistungsverbesserungen.
Empfehlung: Erwägen Sie, das automatische Clustering für diese Tabellen zu deaktivieren. Bevor Sie das automatische Clustering deaktivieren, sollten Sie feststellen, ob die Tabelle nur für die Notfallwiederherstellung oder für die Nutzung durch andere Snowflake-Konten über Data Sharing existiert, was erklären könnte, warum nicht so häufig darauf zugegriffen wird.
Um beispielsweise das automatische Clustering für eine Tabelle mit dem Namen
t1
zu deaktivieren, führen Sie den folgenden Befehl aus:ALTER TABLE t1 SUSPEND RECLUSTER;
- Einblick: Selten verwendete materialisierte Ansichten
Dieser Einblick identifiziert materialisierte Ansichten, die weniger als 10 Mal pro Woche von diesem Konto abgefragt werden.
Das Erstellen einer materialisierten Ansicht kann die Leistung bei bestimmten Abfragen erheblich verbessern. Materialisierte Ansichten verursachen jedoch zusätzliche Speicherkosten sowie Kosten für serverloses Computing, die damit verbunden sind, die materialisierte Ansicht mit neuen Daten aktuell zu halten. Wenn die Anzahl der Abfragen, die auf den materialisierten Ansicht ausgeführt werden, minimal ist, rechtfertigen die entstehenden Kosten möglicherweise nicht die Leistungsverbesserungen.
Empfehlung: Erwägen Sie, Aktualisierungen der materialisierten Ansichten zu entfernen oder auszusetzen. Bevor Sie eine materialisierte Ansicht löschen, sollten Sie feststellen, ob die Tabelle nur für die Notfallwiederherstellung oder für die Nutzung durch andere Snowflake-Konten über Data Sharing existiert, was erklären könnte, warum nicht so häufig darauf zugegriffen wird.
Um zum Beispiel eine materialisierte Ansicht mit dem Namen
mv1
zu löschen, führen Sie den folgenden Befehl aus:DROP MATERIALIZED VIEW mv1;
- Einblick: Selten genutzte Suchoptimierungspfade
Dieser Einblick identifiziert Suchzugriffspfade für die Suchoptimierung, die weniger als 10 Mal pro Woche von diesem Konto verwendet werden.
Bei der Suchoptimierung werden Suchzugriffspfade verwendet, um die Leistung bestimmter Typen von Point-Lookup- und analytischen Abfragen zu verbessern. Das Hinzufügen einer Suchoptimierung zu einer Tabelle kann die Leistung für diese Abfragen erheblich verbessern. Die Suchoptimierung verursacht jedoch zusätzliche Speicherkosten sowie Kosten für serverloses Computing, die damit verbunden sind, den Speicher aktuell zu halten. Wenn die Anzahl der Abfragen, die den durch die Suchoptimierung erstellten Suchzugriffspfad verwenden, minimal ist, rechtfertigen die entstehenden Kosten möglicherweise nicht die Leistungsverbesserungen.
Empfehlung: Entfernen der Suchoptimierung aus der Tabelle erwägen Bevor Sie die Suchoptimierung entfernen, sollten Sie feststellen, ob die Tabelle nur für die Notfallwiederherstellung oder für die Nutzung durch andere Snowflake-Konten über Data Sharing existiert, was erklären könnte, warum nicht so häufig darauf zugegriffen wird.
Um beispielsweise die Suchoptimierung vollständig von einer Tabelle mit dem Namen
t1
zu entfernen, führen Sie den folgenden Befehl aus:ALTER TABLE t1 DROP SEARCH OPTIMIZATION;
- Einblick: Große Tabellen, die nie abgefragt werden
Dieser Einblick identifiziert große Tabellen, die in der letzten Woche nicht von diesem Konto abgefragt wurden.
Empfehlung: Ziehen Sie in Erwägung, unbenutzte Tabellen zu löschen, um die Speicherkosten zu senken, ohne den Workload zu beeinträchtigen. Bevor Sie die Tabellen löschen, sollten Sie feststellen, ob die Tabelle nur für die Notfallwiederherstellung oder für die Nutzung durch andere Snowflake-Konten über Data Sharing existiert, was erklären könnte, warum nicht so häufig darauf zugegriffen wird.
Um zum Beispiel eine Tabelle mit dem Namen
t1
zu löschen, führen Sie den folgenden Befehl aus:DROP TABLE t1;
- Einblick: Tabellen über 100 GB, bei denen Daten geschrieben, aber nicht gelesen werden
Dieser Einblick identifiziert Tabellen, in die von diesem Konto Daten geschrieben, aber die gelesen werden.
Empfehlung: Es könnte eine Verschwendung sein, Daten zu speichern und neue Daten in Snowflake aufzunehmen, wenn die Daten nie gelesen werden. Ziehen Sie in Erwägung, diese Tabellen zu löschen, um Speicherkosten zu sparen, oder keine neuen Daten mehr zu schreiben, um die durch die Datenaufnahme verbrauchten Credits zu sparen. Bevor Sie die Tabellen löschen, sollten Sie feststellen, ob die Tabelle nur für die Notfallwiederherstellung oder für die Nutzung durch andere Snowflake-Konten über Data Sharing existiert, was erklären könnte, warum sie nicht gelesen werden.
Um zum Beispiel eine Tabelle mit dem Namen
t1
zu löschen, führen Sie den folgenden Befehl aus:DROP TABLE t1;
- Einblick: Kurzlebige permanente Tabellen
Dieser Einblick identifiziert Tabellen über 100 GB, die innerhalb von 24 Stunden nach ihrer Erstellung gelöscht wurden.
Empfehlung: Wenn Daten nur für eine kurze Zeit aufbewahrt werden müssen, sollten Sie eine temporäre Tabelle oder eine transiente Tabelle für zukünftige Tabellen verwenden. Die Verwendung einer temporären Tabelle oder einer transienten Tabelle kann Ihnen helfen, die Kosten für Fail-safe und Time Travel zu sparen.
Um zum Beispiel eine neue transiente Tabelle
t1
zu erstellen, führen Sie den folgenden Befehl aus:CREATE TRANSIENT TABLE t1;
Optimieren der Kosten von Clouddiensten¶
Wenn Sie feststellen, dass Ihre Nutzung von Clouddiensten höher ist als erwartet, prüfen Sie, ob Ihre Snowflake-Nutzung einem der folgenden Muster entspricht. Jedes Muster enthält eine Empfehlung, die Ihnen helfen kann, die mit Clouddiensten verbundenen Kosten zu senken.
Muster: Blockierte Abfragen aufgrund von Transaktionssperren
Muster: Hochfrequente SHOW-Befehle (durch Datenanwendungen und Drittanbietertools)
Muster: Einzeilige Inserts und fragmentierte Schemas (durch Datenanwendungen)
- Muster: Blockierte Abfragen aufgrund von Transaktionssperren
Bei Update- und Merge-Befehlen werden Transaktionssperren auf die betroffenen Tabellen gesetzt, die verhindern, dass gleichzeitig andere Befehle auf den Tabellen ausgeführt werden. Während die Abfragen darauf warten, dass die Sperren wieder freigegeben werden, verbrauchen sie Clouddienste-Credits. Je länger die Abfragen auf Clouddienste-Ebene auf die Sperre warten, desto mehr Credits verbrauchen sie.
Empfehlung: Transaktionssperren treten häufig auf, wenn Benutzer parallele Update-/Merge-Befehle für eine einzelne Tabelle ausführen, insbesondere wenn jeder Befehl nur wenige Zeilen aktualisiert. Sie können diese Sperren minimieren, indem Sie anstelle einzelner Aktualisierungen einen Batchbefehl verwenden. Bei dieser Strategie gehen Sie wie folgt vor:
Verwenden Sie eine INSERT-Batchanweisung, um neue Daten in eine temporäre Tabelle zu laden. Vermeiden Sie die Verwendung einzeiliger Inserts. Auch API-Aufrufe, die kontinuierlich neue Daten laden, sollten so designt sein, dass sie statt einzeiliger Einfügungen eher Batcheinfügungen übermitteln.
Verwenden Sie die temporäre Tabelle zum Update/Merge (Aktualisieren/Zusammenführen) der Zieltabelle.
Wenn die Quelle im Laufe des Tages ständig neue Daten sendet, sollten Sie eine Aufgabe (Task) verwenden, um die Zieltabelle in regelmäßigen Abständen zu aktualisieren.
- Muster: Kopierbefehle mit ungenügender Selektivität
Das Ausführen von Kopierbefehlen beinhaltet das Auflisten von Dateien aus dem Amazon Simple Storage Service (S3). Da für das Auflisten von Dateien nur Clouddienste-Computing erforderlich ist, kann das Ausführen von Kopierbefehlen mit geringer Selektivität zu einer hohen Nutzung der Clouddienste führen.
Empfehlung: Ziehen Sie in Erwägung, die Struktur Ihres S3-Buckets so zu ändern, dass er eine Art Datumspräfix enthält, damit Sie nur die benötigten Dateien auflisten.
- Muster: Hochfrequente DDL-Operationen und Klonen
Operationen mit der Datendefinitionssprache (DDL), insbesondere das Klonen, sind reine Metadaten-Operationen, d. h. sie nutzen nur Clouddienste-Computing. Das häufige Erstellen oder Löschen großer Schemas oder Tabellen oder das Klonen von Datenbanken für Backups kann zu einer erheblichen Nutzung von Clouddiensten führen.
Empfehlung: Das Klonen verbraucht nur einen Bruchteil der Ressourcen, die für tiefe Kopien benötigt werden, sodass Sie weiterhin klonen sollten. Überprüfen Sie Ihre Klonmuster, um sicherzustellen, dass sie so detailliert wie möglich sind und nicht zu häufig ausgeführt werden. So könnten Sie beispielsweise nur einzelne Tabellen und nicht ein ganzes Schema klonen.
- Muster: Hochfrequente einfache Abfragen
Die Inanspruchnahme von Clouddiensten durch eine einzige einfache Abfrage ist vernachlässigbar, aber die Ausführung von Abfragen wie
SELECT 1
,SELECT sequence1.NEXTVAL
oderSELECT CURRENT_SESSION()
mit extrem hoher Frequenz (Zehntausende pro Tag) kann zu einer erheblichen Nutzung von Clouddiensten führen.Empfehlung: Überprüfen Sie Ihre Abfragehäufigkeit und stellen Sie fest, ob die Häufigkeit für Ihren Anwendungsfall angemessen eingestellt ist. Wenn Sie eine hohe Frequenz von
SELECT CURRENT_SESSION()
-Abfragen beobachten, die von Partnertools stammen, die den JDBC-Treiber verwenden, überprüfen Sie, ob der Partner seinen Code aktualisiert hat, um diegetSessionId()
-Methode in der SnowflakeConnection-Schnittstelle zu verwenden. Dies nutzt die Vorteile der Zwischenspeicherung und reduziert die Nutzung von Clouddiensten.
- Muster: Hochfrequente INFORMATION_SCHEMA-Abfragen
Abfragen auf dem Snowflake Information Schema verbrauchen nur Ressourcen der Clouddienste. Die Inanspruchnahme von Clouddiensten durch eine einzelne Abfrage auf den INFORMATION_SCHEMA-Ansichten ist vernachlässigbar, aber die Ausführung dieser Abfragen in extrem hoher Frequenz (Zehntausende pro Tag) kann zu einer erheblichen Nutzung von Clouddiensten führen.
Empfehlung: Überprüfen Sie Ihre Abfragehäufigkeit und stellen Sie fest, ob die Häufigkeit für Ihren Anwendungsfall angemessen eingestellt ist. Alternativ können Sie auch eine Ansicht im ACCOUNT_USAGE-Schema anstelle einer INFORMATION_SCHEMA-Ansicht abfragen. Bei Abfragen auf dem ACCOUNT_USAGE-Schema wird ein virtuelles Warehouse anstelle von Clouddiensten verwendet.
- Muster: Hochfrequente SHOW-Befehle (durch Datenanwendungen und Drittanbietertools)
SHOW-Befehle sind ausschließlich Metadaten-Operationen, d. h. sie verbrauchen nur Ressourcen der Clouddienste. Dieses Muster tritt typischerweise auf, wenn Sie eine auf Snowflake aufbauende Anwendung erstellt haben, die SHOW-Befehle in hoher Frequenz ausführt. Diese Befehle können auch durch Drittanbietertools initiiert werden.
Empfehlung: Überprüfen Sie Ihre Abfragehäufigkeit und stellen Sie fest, ob die Häufigkeit für Ihren Anwendungsfall angemessen eingestellt ist. Im Falle von Partnertools sollten Sie sich bei Ihrem Partner erkundigen, ob er eine Anpassung der Nutzung plant.
- Muster: Einzeilige Inserts und fragmentierte Schemas (durch Datenanwendungen)
Snowflake ist kein OLTP-System, sodass das Einfügen einzelner Zeilen suboptimal ist und erhebliche Ressourcen für Clouddienste verbrauchen kann.
Der Aufbau einer Datenanwendung, die ein Schema pro Kunde definiert, kann zu mehreren Datenladeoperationen in einem bestimmten Zeitraum führen, was einen hohe Nutzung von Clouddiensten zur Folge haben kann.
Dieses Muster führt auch dazu, dass Snowflake sehr viel mehr Metadaten pflegen muss, und Metadatenoperationen verbrauchen Ressourcen der Clouddienste. Jede einzelne Metadatenoperation verbraucht nur minimale Ressourcen, aber der Gesamtverbrauch kann erheblich sein.
Empfehlung: Führen Sie generell eher Batch- oder Massenladeoperationen statt einzeiliger Insert-Operationen aus.
Die Verwendung eines gemeinsamen Schemas ist wesentlich effizienter und damit kostensparender. Sie möchten wahrscheinlich alle Tabellen auf der
customer_ID
clustern und sichere Ansichten verwenden.
- Muster: Komplexe SQL-Abfragen
Abfragen können eine erhebliche Menge an Clouddienst-Computing beanspruchen, wenn sie viele Join-Operationen oder Operationen mit kartesischen Produkten enthalten, den IN-Operator auf großen Listen verwenden, oder wenn die Abfragen sehr groß sind. Diese Typen von Abfragen haben alle hohe Kompilierungszeiten.
Empfehlung: Überprüfen Sie Ihre Abfragen, und vergewissern Sie sich, dass diese das tun, was sie tun sollen. Snowflake unterstützt diese Abfragen und berechnet Ihnen nur die verbrauchten Ressourcen.