Optimieren der Leistung dynamischer Tabellen¶

Unter diesem Thema werden Techniken zur Optimierung der Leistung dynamischer Tabellen behandelt, die in Designänderungen und Anpassungen unterteilt sind.

Bevor Sie eine dynamische Tabelle optimieren, sollten Sie die Ursache für langsame Aktualisierungen diagnostizieren. Siehe Diagnose langsamer Aktualisierungen für einen schrittweisen Workflow.

Hintergrundinformationen zu den Leistungskategorien finden Sie unter Leistungsentscheidungen.

Designänderungen¶

Designänderungen erfordern, dass Sie eine dynamische Tabelle neu erstellen, aber größeren Einfluss auf die Leistung haben.

Bemerkung

Wir empfehlen, dass Sie Änderungen gruppieren und Tabellen gemeinsam neu erstellen, anstatt inkrementelle Änderungen vorzunehmen.

Auswählen eines Aktualisierungsmodus¶

Der von Ihnen gewählte Aktualisierungsmodus hat erheblichen Einfluss auf die Leistung, da er bestimmt, wie viele Daten Snowflake bei jeder Aktualisierung verarbeitet. Weitere Informationen zur Funktionsweise der einzelnen Modi finden Sie unter Aktualisierungsmodi für dynamische Tabellen.

Wichtig

Dynamische Tabellen mit inkrementeller Aktualisierung können nicht nachgelagert von dynamischen Tabellen mit vollständiger Aktualisierung sein.

Verwenden Sie den folgenden Entscheidungsprozess, um einen Aktualisierungsmodus auszuwählen:

Überprüfen Sie Ihre Abfrage mit der Liste von unterstützten Abfragekonstrukten. Nicht alle Abfrageoperatoren unterstützen die inkrementelle Aktualisierung. Für Operatoren, die unterstützt werden, siehe Optimieren von Abfragen für inkrementelle Aktualisierungen, um zu verstehen, wie sie sich auf die Leistung auswirken.
Schätzen Sie Ihr Änderungsvolumen, d. h. der Prozentsatz Ihrer Daten, der sich zwischen den Aktualisierungen ändert. Die inkrementelle Aktualisierung funktioniert zum Beispiel am besten, wenn sich weniger als fünf Prozent der Daten ändern.
Bewerten Sie Ihre Datenlokalität. Prüfen Sie, ob Ihre Quelltabellen nach den Schlüsseln gruppiert sind, die Sie in Verknüpfungen, GROUP BY- oder PARTITION BY-Klauseln in Ihrer Abfrage für dynamische Tabellen verwenden möchten. Eine schlechte Lokalität verringert die Effizienz der inkrementellen Aktualisierung. Informationen zur Verbesserung der Lokalität finden Sie unter Verbessern der Datenlokalität.

Wählen Sie einen Modus anhand der folgenden Tabelle aus:

Modus	Einsatzszenarios
Inkrementell	Ihre Abfrage verwendet unterstützte Operatoren, weniger als fünf Prozent der Daten ändern sich zwischen den Aktualisierungen, und Ihre Quelltabellen weisen eine gute Datenlokalität auf. Bemerkung Die inkrementelle Aktualisierung kann immer noch die Quelltabellen durchsuchen, nicht nur die Zeilen, die geändert wurden. Beispielsweise muss eine neue Zeile auf einer Seite einer Verknüpfung mit allen Zeilen in der anderen Tabelle übereinstimmen. Auch eine kleine Anzahl von Änderungen kann erheblichen Arbeitsaufwand auslösen.
Vollständig	Ein hoher Prozentsatz der Daten ändert sich, Ihre Abfrage verwendet nicht unterstützte Operatoren oder Ihre Daten sind nicht lokal.
Auto	Sie führen Prototyping oder Tests durch. Vermeiden Sie AUTO in der Produktion, da sich sein Verhalten zwischen verschiedenen Releases von Snowflake ändern kann.

Wenn Sie eine dynamische Tabelle erstellen, geben Sie den Modus mit REFRESH_MODE = INCREMENTAL oder REFRESH_MODE = FULL in Ihrer CREATE DYNAMIC TABLE-Anweisung an.

Um zu prüfen, welchen Aktualisierungsmodus eine dynamische Tabelle verwendet, siehe Aktualisierungsmodus.

Optimieren von Abfragen und Pipeline¶

Die Struktur Ihrer Abfragen für dynamische Tabellen und Ihrer Pipeline wirkt sich direkt auf die Aktualisierungsleistung aus. Verwenden Sie die folgenden Richtlinien, um den Aufwand bei jeder Aktualisierung zu reduzieren.

Vereinfachen einzelner Abfragen¶

Verwenden Sie innere Verknüpfungen anstelle von äußeren Verknüpfungen. Innere Verknüpfungen zeigen bei der inkrementellen Aktualisierung eine bessere Leistung. Überprüfen Sie die referenzielle Integrität Ihrer Quelldaten, um äußere Verknüpfungen zu vermeiden.
Vermeiden Sie unnötige Operationen. Entfernen Sie redundante DISTINCT-Klauseln und nicht verwendete Spalten. Schließen Sie breite Spalten aus (wie große JSON-Blobs), die nicht häufig abgefragt werden.
Entfernen Sie Duplikate effizient. Verwenden Sie nach Möglichkeit rangbezogene Funktionen anstelle von DISTINCT.

Detaillierte Hinweise dazu, wie sich bestimmte SQL-Operatoren auf die Leistung der inkrementellen Aktualisierung auswirken, finden Sie unter Optimieren von Abfragen für inkrementelle Aktualisierungen.

Bemerkung

Ein umfassendes Beispiel finden Sie unter Tutorial: Optimieren der Leistung dynamischer Tabellen für SCD-Workloads vom Typ 1.

Aufteilen von Transformationen auf dynamische Tabellen¶

Die Aufteilung komplexer Transformationen auf mehrere dynamische Tabellen erleichtert das Erkennen von Engpässen und verbessert das Debugging. Durch Unveränderlichkeitseinschränkungen können Sie auch verschiedene Aktualisierungsmodi für verschiedene Stagingbereiche verwenden.

Fügen Sie Filter frühzeitig hinzu. Verwenden Sie WHERE-Klauseln in den dynamischen Tabellen, die Ihren Quelldaten am nächsten liegen, sodass nachgelagerte Tabellen weniger Zeilen verarbeiten.
Um wiederholte DISTINCT-Operationen in nachgelagerten Tabellen zu vermeiden, entfernen Sie doppelte Zeilen zu einem früheren Zeitpunkt in Ihrer Pipeline.
Reduzieren Sie die Anzahl der Operationen pro Tabelle. Verschieben Sie Verknüpfungen, Aggregationen oder Fensterfunktionen in dynamische Zwischentabellen, anstatt sie alle in einer Abfrage zu kombinieren.
Materialisieren Sie zusammengesetzte Ausdrücke (wie DATE_TRUNC('minute', ts)) in eine Zwischentabelle, bevor sie nach ihnen gruppiert werden. Weitere Details dazu finden Sie unter Optimieren von Aggregationen.

Bemerkung

Das Finden optimaler Aufteilungspunkte erfordert die Versuchs-und-Irrtums-Methode.

Ziehen Sie eine Aufteilung zwischen Operationen in Betracht, die Daten auf verschiedenen Schlüsseln umverteilen, z. B. GROUP BY, DISTINCT, Fensterfunktionen mit PARTITION BY und Verknüpfungen. Dadurch kann jede dynamische Tabelle eine bessere Datenlokalität für ihre Schlüsseloperation beibehalten. Operatorspezifische Hinweise finden Sie unter Optimieren von Abfragen für inkrementelle Aktualisierungen.

Das folgende Beispiel zeigt, wie eine komplexe Abfrage in dynamische Zwischentabellen aufgeteilt wird.

Erste komplexe Abfrage:

CREATE DYNAMIC TABLE final_result
  TARGET_LAG = '1 hour'
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM large_table a
  JOIN dimension_table b ON ...
  JOIN another_table c ON ...
  GROUP BY ...;

Copy

Teilen Sie die komplexe Pipeline auf, indem Sie eine dynamische Zwischentabelle hinzufügen:

CREATE DYNAMIC TABLE intermediate_joined
  TARGET_LAG = DOWNSTREAM
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM large_table a
  JOIN dimension_table b ON ...;

CREATE DYNAMIC TABLE final_result
  TARGET_LAG = '1 hour'
  WAREHOUSE = my_warehouse
AS
  SELECT ...
  FROM intermediate_joined
  JOIN another_table c ON ...
  GROUP BY ...;

Copy

Ausführliche Informationen und Beispiele dazu, wie sich Operatoren auf die Leistung auswirken, finden Sie unter Optimieren von Abfragen für inkrementelle Aktualisierungen.

Markieren von historischen Daten als unveränderlich¶

Verwenden Sie die IMMUTABLE WHERE-Klausel, um Snowflake mitzuteilen, dass sich bestimmte Zeilen nicht ändern werden. Dies reduziert den Arbeitsumfang bei jeder Aktualisierung.

Syntax, Beispiele und detaillierte Anleitungen finden Sie unter Verwenden von Unveränderlichkeitseinschränkungen.

Anpassungen¶

Für die Anpassungen müssen Sie die dynamischen Tabellen nicht neu erstellen. Sie können Anpassungen vornehmen, während Ihre Pipeline ausgeführt wird.

Anpassen Ihrer Warehouse-Konfiguration¶

Das Warehouse, das Sie in Ihrer CREATE DYNAMIC TABLE-Anweisung angeben, führt alle Aktualisierungen für diese Tabelle aus. Größe und Konfiguration des Warehouse wirken sich direkt auf die Aktualisierungsdauer und die Kosten aus.

Weitere Informationen zu Warehouses und dynamischen Tabellen finden Sie unter Erläuterungen zur Nutzung von Warehouses für dynamische Tabellen. Allgemeine Strategien zur Optimierung der Warehouse-Leistung finden Sie unter Optimieren von Warehouses für bessere Performance.

Verwenden eines separaten Warehouses für die Initialisierung¶

Bei erstmaligen Aktualisierungen werden oft wesentlich mehr Daten verarbeitet als bei inkrementellen Aktualisierungen. Verwenden Sie INITIALIZATION_WAREHOUSE, um Initialisierungen auf einem größeren Warehouse auszuführen. Reservieren Sie ein kleineres, kostengünstigeres Warehouse für regelmäßige Aktualisierungen:

CREATE DYNAMIC TABLE my_dynamic_table
  TARGET_LAG = 'DOWNSTREAM'
  WAREHOUSE = 'XS_WAREHOUSE'
  INITIALIZATION_WAREHOUSE = '4XL_WAREHOUSE'
  AS <query>;

Copy

So können Sie das Initialisierungs-Warehouse für eine bestehende dynamische Tabelle hinzufügen oder ändern:

ALTER DYNAMIC TABLE my_dynamic_table SET INITIALIZATION_WAREHOUSE = '4XL_WAREHOUSE';

Copy

So entfernen Sie das Initialisierungs-Warehouse und verwenden das primäre Warehouse für alle Aktualisierungen:

ALTER DYNAMIC TABLE my_dynamic_table UNSET INITIALIZATION_WAREHOUSE;

Copy

Um die Konfiguration des Warehouses anzuzeigen, verwenden Sie SHOW DYNAMIC TABLES, oder überprüfen Sie die Tabellenfunktion DYNAMIC_TABLE_REFRESH_HISTORY.

Ändern der Größe bei Bedarf¶

Um ein ausgewogenes Verhältnis zwischen Kosten und Leistung zu finden, wählen Sie eine Warehouse-Größe, die das Überlaufen von Bytes verhindert, aber nicht das überschreitet, was Ihr Workload parallel nutzen kann. Wenn schnellere Aktualisierungen entscheidend sind, erhöhen Sie die Größe leicht über den kostenoptimalen Punkt hinaus.

Hinweise zum Aktualisieren dynamischer Tabellen:

Übergelaufene Bytes: Wenn der Abfrageverlauf zeigt, dass Bytes in den lokalen oder Remotespeicher übergelaufen sind, hatte das Warehouse während der Aktualisierung nicht mehr genügend Arbeitsspeicher. Ein größeres Warehouse bietet mehr Arbeitsspeicher, um ein Überlaufen zu verhindern. Weitere Details dazu finden Sie unter Abfragen, die zu groß für den Arbeitsspeicher sind.
Langsame erstmalige Aktualisierung: Wenn die erstmalige Aktualisierung langsam ist, sollten Sie INITIALIZATION_WAREHOUSE für die erste Erstellung einstellen, oder Sie ändern die Größe des Warehouses vorübergehend und verkleinern es, nachdem die Tabelle erstellt wurde.
Überflüssige Parallelität: Ab einem bestimmten Punkt nimmt der Nutzen zusätzlicher Parallelität jedoch ab. Eine Verdoppelung der Warehouse-Größe kann zu doppelten Kosten führen, ohne dass die Laufzeit halbiert wird. Um zu prüfen, wie Ihre Aktualisierung die Parallelität nutzt, überprüfen Sie das Abfrageprofil.

Weitere Informationen zum Ändern der Größe eines Warehouses finden Sie unter Erhöhen der Warehouse-Größe.

Hinweise zu Kosten finden Sie unter Credit-Nutzung für virtuelle Warehouses und Verwenden von Warehouses.

Verarbeiten von parallelen Aktualisierungen mit Multi-Cluster-Warehouses¶

Wenn sich mehrere dynamische Tabellen ein Warehouse teilen und die Warteschlange häufig aktualisiert wird, sollten Sie die Verwendung eines Multi-Cluster-Warehouses in Betracht ziehen. Multi-Cluster-Warehouses fügen Cluster automatisch hinzu, wenn Abfragen in die Warteschlange gestellt werden, und entfernen sie, wenn die Nachfrage sinkt. Dies verbessert die Aktualisierungslatenz während Spitzenzeiten, ohne für ungenutzte Kapazität in Ruhezeiten zu bezahlen.

Hinweise zum Identifizieren und Reduzieren von Warteschlangen finden Sie unter Reduzieren von Warteschlangen.

Multi-Cluster-Warehouses erfordern Enterprise Edition oder höher. Hinweise zu Kosten finden Sie unter Einstellen der Skalierungsrichtlinie für ein Multi-Cluster-Warehouse.

Identifizieren der richtigen Zielverzögerung¶

Die Zielverzögerung steuert, wie oft Ihre dynamische Tabelle aktualisiert wird. Eine geringere Zielverzögerung bedeutet neuere Daten, aber häufigere Aktualisierungen und höhere Computekosten. Weitere Informationen zur Funktionsweise von Zielverzögerungen finden Sie unter Die Zielverzögerung dynamischer Tabellen verstehen.

Verwenden Sie die folgenden Empfehlungen, um die Zielverzögerung für Ihren Workload zu optimieren:

Verwenden Sie DOWNSTREAM für Zwischentabellen, die keine unabhängigen Aktualitätsgarantien benötigen. Diese Tabellen werden nur aktualisiert, wenn nachgelagerte Tabellen sie benötigen.
Überprüfung des Aktualisierungsverlaufs, um die richtige Verzögerung zu finden: Verwenden Sie DYNAMIC_TABLE_REFRESH_HISTORY oder Snowsight, um die Aktualisierungsdauer und übersprungene Aktualisierungen zu analysieren. Stellen Sie eine Zielverzögerung ein, die etwas höher ist als Ihre typische Aktualisierungsdauer.

Ändern der Zielverzögerung¶

ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = '1 hour';

Copy

So stellen Sie eine dynamische Tabelle ein, die auf der Grundlage einer nachgelagerten Nachfrage aktualisiert wird:

ALTER DYNAMIC TABLE my_dynamic_table SET TARGET_LAG = DOWNSTREAM;

Copy

Verbessern der Datenlokalität¶

Lokalität beschreibt, wie genau Snowflake Zeilen mit denselben Schlüsselwerten speichert. Wenn sich Zeilen mit übereinstimmenden Schlüsseln über weniger Mikropartitionen erstrecken (gute Lokalität), werden bei inkrementellen Aktualisierungen weniger Daten gescannt. Wenn sich übereinstimmende Schlüssel über viele Mikropartitionen erstrecken (schlechte Lokalität), kann die inkrementelle Aktualisierung länger dauern als die vollständige Aktualisierung.

Weitere Informationen darüber, wie Snowflake Daten speichert, finden Sie unter Mikropartitionen und Daten-Clustering.

Cluster-Quelltabellen¶

Der effektivste Weg, die Lokalität zu verbessern, ist das Clustering Ihrer Quelltabellen nach den Schlüsseln, die in Ihrer Abfrage der dynamischen Tabelle (JOIN-, GROUP BY- oder PARTITION BY-Schlüssel) verwendet werden:

ALTER TABLE my_source_table CLUSTER BY (join_key_column);

Copy

Wenn Sie über mehrere Spalten verknüpfen und nicht nach allen gruppieren können:

Priorisieren Sie das Clustering größerer Tabellen nach den selektiven Schlüsseln.
Erwägen Sie, separate Kopien derselben Daten zu erstellen, die nach verschiedenen Schlüsseln gruppiert werden, um sie in verschiedenen dynamischen Tabellen zu verwenden.

Weitere Informationen dazu finden Sie unter Gruppierungsschlüssel und geclusterte Tabellen. Informationen zum Aktivieren des automatischen Reclustering finden Sie unter Automatic Clustering.

Faktoren, die die Lokalität beeinflussen¶

Neben dem Gruppieren von Quelltabellen gibt es zwei weitere Faktoren, die die Lokalität beeinflussen. Diese hängen von Ihren Datenmustern ab und sind schwieriger direkt zu ändern:

Wie neue Daten mit Partitionsschlüsseln angepasst werden: Die inkrementelle Aktualisierung ist schneller, wenn neue Zeilen nur einen kleinen Teil der Tabelle betreffen. Dies hängt von Ihren Datenaufnahmemustern ab, nicht von Ihrer Abfragestruktur.

Beispielsweise haben nach Stunden gruppierte Zeitreihendaten eine gute Lokalität, da neue Zeilen aktuelle Zeitstempel teilen. Daten, die nach einer Spalte gruppiert sind und Werte über die gesamte Tabelle verteilt haben, haben eine schlechte Lokalität.
Wie Änderungen an die Gruppierung dynamischer Tabellen angepasst werden: Wenn Snowflake Aktualisierungen oder Löschungen auf einer dynamischen Tabelle anwendet, muss es die betroffenen Zeilen lokalisieren. Dies ist schneller, wenn die geänderten Zeilen nahe beieinander gespeichert sind.

Beispielsweise funktionieren Aktualisierungen der jüngsten Zeilen gut, wenn die dynamische Tabelle natürlich nach Zeit geordnet ist. Über die gesamte Tabelle verschachtelte Aktualisierungen sind langsamer. Dieser Faktor hängt von Ihren Workload-Mustern ab. Dazu gehört auch, welche Zeilen sich ändern und wie oft sie sich ändern.

Wenn Sie aufgrund dieser Faktoren eine schlechte Lokalität feststellen, sollten Sie überlegen, ob Sie Ihr Datenmodell oder Ihre Datenaufnahmemuster vorgelagert anpassen können.