Best Practices für Snowpipe Streaming¶

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 außerdem für die Tabelle, in die Snowpipe Streaming die Einfügungen vornimmt, Automatic Clustering aktiviert ist, können die Computekosten für die Dateimigration reduziert werden. Die Clustering-Operation optimiert und migriert 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 das mehrmalige Aufrufen 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 manuell den Rückgabewert von insertRows auf mögliche Erfassungsfehler. 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 nach dem Einfügen von Daten nicht, da die Daten in den Kanälen automatisch auf der Grundlage der unter MAX_CLIENT_LAG konfigurierten Zeit gelöscht werden.

Empfehlungen zur Latenz¶

Bei Snowflake Ingest SDK ab Version 2.0.4 können Sie MAX_CLIENT_LAG verwenden, um die Datenflush-Latenz zu konfigurieren. Standardmäßig werden die Daten bei Snowpipe Streaming alle 1 Sekunde geleert. Mit der Konfiguration von MAX_CLIENT_LAG können Sie dies überschreiben und die gewünschte Flush-Latenz von 1 Sekunde bis 10 Minuten einstellen.

In Szenarios mit geringem Durchsatz, in denen nicht viele Daten generiert werden, senden Sie vielleicht nur 1 Zeile oder 1 KB Daten pro Sekunde. Dies kann zu einer längeren Kompilierungszeit der Abfrage führen, wenn viele kleine Partitionen aufgelöst werden müssen, um Ihre Abfrageergebnisse zurückzugeben, insbesondere wenn die Abfrage ausgelöst wird, bevor der Migrationsprozess die Partitionen komprimiert. Wenn Sie MAX_CLIENT_LAG höher einstellen, kann Snowpipe Streaming die eingefügten Zeilen für die konfigurierte Zeitdauer puffern und Partitionen mit besserer Größe erstellen. Das hilft bei Abfrageleistung und Migration erheblich.

Stellen Sie daher MAX_CLIENT_LAG so hoch ein, wie es Ihre Ziel-Latenz erlaubt. Wenn Sie zum Beispiel eine Aufgabe haben, die alle 1 Minute ausgeführt werden, um Ihre gestreamten Daten zusammenzuführen oder umzuwandeln, wäre es optimal, MAX_CLIENT_LAG auf 50 oder 55 Sekunden einzustellen.