Best Practices für Snowpipe Streaming Classic

Kostenoptimierung

Es empfiehlt sich, die API mit weniger Snowpipe Streaming-Clients aufzurufen, die mehr Daten pro Sekunde schreiben. Verwenden Sie eine Java- oder Scala-Anwendung, um Daten aus mehreren Quellen wie IoT-Geräten oder Sensoren zu aggregieren, und verwenden Sie dann das Snowflake Ingest SDK, um die API aufzurufen und die Daten mit höheren Datenflussraten zu laden. Die API aggregiert effizient Daten über mehrere Zieltabellen in einem Konto.

Ein einzelner Snowpipe Streaming-Client kann mehrere Kanäle zum Senden von Daten öffnen, aber die Kosten für den Client werden nur pro aktivem Client berechnet. Die Anzahl der Kanäle hat keinen Einfluss auf die Clientkosten. Daher empfehlen wir zur Leistungs- und Kostenoptimierung, pro Client mehrere Kanäle zu verwenden.

Die Nutzung derselben Tabellen sowohl für zur Batch- als auch zur Streaming-Erfassung kann aufgrund von vorweggenommenen Dateimigrationsoperationen ebenfalls zu geringeren Snowpipe Streaming-Computekosten führen. Wenn Automatic Clustering auch für dieselbe Tabelle aktiviert ist, in die Snowpipe Streaming eingefügt wird, können die Rechenkosten für die Dateimigration reduziert werden. Die Clustering-Operation optimiert und migriert die Daten in derselben Transaktion.

Performance-Empfehlungen

Für eine optimale Performance bei Bereitstellungen mit hohem Durchsatz empfehlen wir die folgenden Maßnahmen:

  • Wenn Sie mehrere Zeilen laden, ist die Verwendung von insertRows effizienter und kostengünstiger als der mehrfache Aufruf von insertRow, da weniger Zeit für Sperren aufgewendet wird.

    • Halten Sie die Größe jedes an insertRows übergebenen Zeilenbatches unter 16 MB komprimiert.

    • Die optimale Größe von Zeilenbatches liegt zwischen 10–16 MB.

  • Übergeben Sie Werte für TIME-, DATE- und alle TIMESTAMP-Spalten mit einem der unterstützten Typen aus dem java.time-Paket.

  • Wenn Sie einen Kanal mit OpenChannelRequest.builder erstellen, setzen Sie OnErrorOption auf OnErrorOption.CONTINUE und überprüfen Sie den Rückgabewert von insertRows manuell auf mögliche Datenaufnahmefehler. Dieser Ansatz führt derzeit zu einer besseren Performance als der Rückgriff auf Ausnahmen, die bei Verwendung von OnErrorOption.ABORT ausgelöst werden.

  • Wenn Sie den Standard-Protokolliergrad auf DEBUG setzen, müssen Sie sicherstellen, dass die folgenden Logger weiterhin mit INFO protokollieren: Dies ist erforderlich, da die Ausgabe von DEBUG sehr ausführlich ist, was erhebliche Auswirkungen auf die Performance haben kann.

    • net.snowflake.ingest.internal.apache.parquet

    • org.apache.parquet

  • Kanäle sind für eine lange Verwendungsdauer gedacht, wenn ein Client aktiv Daten einfügt, und sollten wiederverwendet werden, da die Informationen zu Offset-Token erhalten bleiben. Schließen Sie die Kanäle nicht, nachdem Sie Daten eingefügt haben, denn die Daten in den Kanälen werden automatisch auf der Grundlage der in MAX_CLIENT_LAG konfigurierten Zeit geleert.

Empfehlungen zur Latenz

Wenn Sie Snowpipe Streaming verwenden, bezieht sich die Latenz darauf, wie schnell die in einen Kanal geschriebenen Daten zur Abfrage in Snowflake zur Verfügung stehen. Snowpipe Streaming leert die Daten in Kanälen automatisch alle Sekunden, sodass Sie einen Kanal nicht explizit schließen müssen, damit die Daten geleert werden.

Konfigurieren der Latenz mit MAX_CLIENT_LAG Bei Snowflake Ingest-SDK ab Version 2.0.4 können Sie die Datenflush-Latenz mit der Option MAX_CLIENT_LAG konfigurieren:

  • Standard-Snowflake-Tabellen (nicht Iceberg): Die Standardeinstellung von MAX_CLIENT_LAG ist 1 Sekunde. Sie können dies überschreiben, um die gewünschte Flush-Latenz zwischen 1 Sekunde und maximal 10 Minuten einzustellen.

  • Snowflake-verwaltete Iceberg-Tabellen: Unterstützt von Snowflake Ingest SDK-Versionen 3.0.0 und höher, die Standardeinstellung von MAX_CLIENT_LAG ist 30 Sekunden. Diese Voreinstellung stellt sicher, dass optimierte Parquet-Dateien erstellt werden, was sich positiv auf die Abfrageleistung auswirkt. Sie können zwar einen niedrigeren Wert einstellen, aber das ist im Allgemeinen nicht empfehlenswert, es sei denn, Sie haben einen außergewöhnlich hohen Durchsatz.

Latenzempfehlungen für optimale Leistung Die effektive Einstellung von MAX_CLIENT_LAG kann die Abfrageleistung und den internen Migrationsprozess (bei dem Snowflake kleine Partitionen verdichtet) erheblich beeinflussen.

Bei Szenarien mit geringem Durchsatz, bei denen Sie vielleicht nur eine kleine Datenmenge (z. B. 1 Zeile oder 1 KB) pro Sekunde senden, kann häufiges Leeren zu zahlreichen kleinen Partitionen führen. Dadurch kann sich die Kompilierungszeit für Abfragen erhöhen, da Snowflake viele kleine Partitionen auflösen muss, insbesondere wenn Abfragen ausgeführt werden, bevor der Migrationsprozess sie komprimieren kann.

Daher sollten Sie MAX_CLIENT_LAG so hoch einstellen, wie es Ihre Ziel-Latenzanforderungen erlauben. Durch das längere Zwischenspeichern eingefügter Zeilen kann Snowpipe Streaming besser dimensionierte Partitionen erstellen, was die Abfrageleistung verbessert und den Migrationsaufwand reduziert. Wenn Sie zum Beispiel eine Aufgabe haben, die jede Minute ausgeführt wird, um Ihre gestreamten Daten zusammenzuführen oder umzuwandeln, könnte eine optimale MAX_CLIENT_LAG zwischen 50 und 55 Sekunden liegen. Dadurch wird sichergestellt, dass die Daten in größeren Blöcken geleert werden, kurz bevor Ihr nachgelagerter Prozess läuft.

Kafka Connector für Snowpipe Streaming Es ist wichtig zu wissen, dass der Kafka Connector für Snowpipe Streaming über einen eigenen internen Puffer verfügt. Wenn die Zeit zum Leeren des Kafka-Puffers erreicht ist, werden die Daten mit der Standard-Latenzzeit von einer Sekunde über Snowpipe Streaming an Snowflake gesendet. Für weitere Informationen siehe buffer.flush.time-Einstellung

Sprache: Deutsch