Vorbereiten von Datendateien¶
Dieses Thema enthält bewährte Verfahren, allgemeine Richtlinien und wichtige Hinweise für die Vorbereitung Ihrer Datendateien zum Laden.
Unter diesem Thema:
Best Practices für die Dateigrößen¶
Beachten Sie für eine optimale Ladeleistung und zur Vermeidung von Größenbeschränkungen die folgenden Richtlinien für die Dimensionierung von Dateien. Beachten Sie, dass diese Empfehlungen sowohl für das Laden von Massendaten als auch für das kontinuierliche Laden mit Snowpipe gelten.
Allgemeine Empfehlungen für Dateigrößen¶
Die Anzahl der parallel laufenden Operationen darf die Anzahl der zu ladenden Datendateien nicht überschreiten. Um die Anzahl der parallelen Operationen für das Laden zu optimieren, empfehlen wir, Datendateien mit einer komprimierten Größe von 100–250 MB zu erstellen.
Bemerkung
Das Laden sehr großer Dateien (z. B. 100 GB oder größer) wird nicht empfohlen.
Wenn Sie eine große Datei laden müssen, sollten Sie den Wert der Kopieroption ON_ERROR sorgfältig prüfen. Der Abbruch oder das Überspringen einer Datei aufgrund einer geringen Anzahl von Fehlern kann zu Verzögerungen und verschwendeten Credits führen. Wenn eine Datenladeoperation über die maximal zulässige Dauer von 24 Stunden hinaus andauert, kann sie außerdem abgebrochen werden, ohne dass die Übertragung von Teilen der Datei bestätigt (Commit) wird.
Fassen Sie kleinere Dateien zusammen, um den Verarbeitungsaufwand für jede Datei zu minimieren. Teilen Sie große Dateien in eine größere Anzahl kleinerer Dateien auf, um die Last auf die Computeressourcen des aktiven Warehouses zu verteilen. Die Anzahl der Datendateien, die parallel verarbeitet werden, wird durch die Anzahl der Computeressourcen in einem Warehouse bestimmt. Wir empfehlen ein zeilenweises Aufteilen der Dateien, um Datensätze zu vermeiden, die sich über Blöcke verteilen.
Wenn Ihre Datenquelle den Export von Datendateien in kleineren Blöcken nicht zulässt, können Sie ein Dienstprogramm eines Drittanbieters verwenden, um große CSV-Dateien aufzuteilen.
Wenn Sie große unkomprimierte CSV-Dateien (die größer als 128MB sind) laden, die der RFC4180-Spezifikation folgen, unterstützt Snowflake das parallele Scannen dieser CSV-Dateien, wenn MULTI_LINE auf FALSE
, COMPRESSION auf NONE
und ON_ERROR auf ABORT_STATEMENT
oder CONTINUE
gesetzt ist.
Linux oder macOS¶
Das Dienstprogramm split
ermöglicht es Ihnen, eine CSV-Datei in mehrere kleinere Dateien aufzuteilen.
Syntax:
split [-a suffix_length] [-b byte_count[k|m]] [-l line_count] [-p pattern] [file [name]]
Weitere Informationen erhalten Sie, wenn Sie man split
in ein Terminalfenster eingeben.
Beispiel:
split -l 100000 pagecounts-20151201.csv pages
In diesem Beispiel wird eine Datei mit dem Namen pagecounts-20151201.csv
nach Zeilenlänge aufgeteilt. Angenommen, die große einzelne Datei ist 8 GB groß und enthält 10 Millionen Zeilen. Geteilt durch 100.000, ist jede der 100 kleineren Dateien 80 MB groß (10 Millionen / 100.000 = 100). Die aufgeteilten Dateien haben den Namen pagessuffix
.
Windows¶
Windows enthält kein natives Dienstprogramm zur Dateiaufteilung; Windows unterstützt jedoch viele Tools und Skripte von Drittanbietern, die große Datendateien aufteilen können.
Größenbeschränkungen für Datenbankobjekte¶
Wenn Sie eine der verfügbaren Methoden zum Laden von Daten in Snowflake verwenden, können Sie Objekte mit Größen bis zu den folgenden Grenzwerten speichern:
Datentyp |
Speichergrenze |
---|---|
ARRAY |
128 MB |
BINARY |
64 MB |
GEOGRAPHY |
64 MB |
GEOMETRY |
64 MB |
OBJECT |
128 MB |
VARCHAR |
128 MB |
VARIANT |
128 MB |
Die Standardgröße für VARCHAR-Spalten beträgt 16 MB (8 MB für Binärwerte). Um Tabellen mit Spaltengrößen größer als 16 MB zu erstellen, geben Sie die Größe explizit an. Beispiel:
CREATE OR REPLACE TABLE my_table (
c1 VARCHAR(134217728),
c2 BINARY(67108864));
Um die neuen Grenzen für VARCHAR-Spalten zu nutzen, können Sie Tabellen ändern, um die Spaltengröße anzupassen. Beispiel:
ALTER TABLE my_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);
Um die neue Größe auf Spalten des Typs BINARY in diesen Tabellen anzuwenden, erstellen Sie die Tabellen neu. Sie können die Länge einer Spalte BINARY in einer bestehenden Tabelle nicht ändern.
Für Spalten des Typs ARRAY, GEOGRAPHY, GEOMETRY, OBJECT und VARIANT können Sie Objekte, die größer als 16 MB sind, in bestehenden Tabellen und neuen Tabellen speichern, ohne die Länge anzugeben. Beispiel:
CREATE OR REPLACE TABLE my_table (c1 VARIANT);
Wenn Sie Prozeduren und Funktionen haben, die in der Vergangenheit erstellt wurden und VARIANT-, VARCHAR- oder BINARY-Werte als Eingabe verwenden, müssen Sie diese möglicherweise (ohne angegebene Länge) neu erstellen, um Objekte zu unterstützen, die größer als 16 MB sind. Beispiel:
CREATE OR REPLACE FUNCTION udf_varchar(g1 VARCHAR)
RETURNS VARCHAR
AS $$
'Hello' || g1
$$;
Für extern verwaltete Iceberg-Tabellen beträgt die Standardlänge für VARCHAR- und BINARY- Spalten 128 MB. Diese Standardlänge gilt für neu erstellte oder aktualisierte Tabellen. Wenn Sie Tabellen haben, die in der Vergangenheit erstellt wurden, gelten möglicherweise niedrigere Größenbeschränkungen für diese. Sie können diese Tabellen aktualisieren, sodass sie höhere Größenbeschränkungen unterstützen.
Bei verwalteten Iceberg-Tabellen beträgt die Standardlänge für die Spalten VARCHAR und BINARY 128 MB. Tabellen, die vor der Aktivierung der neuen Größenbeschränkungen erstellt wurden haben weiterhin die bisherigen Standardlängen. Um die neue Größe auf Spalten des Typs VARCHAR in diesen Tabellen anzuwenden, erstellen Sie die Tabellen neu oder ändern Sie die Spalten. Das folgende Beispiel ändert eine Spalte, um die neue Größenbeschränkung zu verwenden:
ALTER ICEBERG TABLE my_iceberg_table ALTER COLUMN col1 SET DATA TYPE VARCHAR(134217728);
Um die neue Größe auf Spalten des Typs BINARY in diesen Tabellen anzuwenden, erstellen Sie die Tabellen neu. Sie können die Länge einer Spalte BINARY in einer bestehenden Tabelle nicht ändern.
Treiberversionen, die große Objekte im Resultset unterstützen¶
Treiber unterstützen Objekte, die größer sind als 16 MB (8 MB für BINARY, GEOMETRY und GEOGRAPHY). Möglicherweise müssen Sie Ihre Treiber auf die Versionen aktualisieren, die größere Objekte unterstützen. Die folgenden Treiberversionen sind erforderlich:
Treiber |
Unterstützte Mindestversion |
Releasedatum |
---|---|---|
Snowpark-Bibliothek für Python |
1.21.0 |
August 19, 2024 |
Snowflake Connector für Python |
3.10.0 |
April 29, 2024 |
JDBC |
3.17.0 |
July 8, 2024 |
ODBC |
3.6.0 |
March 17, 2025 |
Go-Snowflake-Treiber |
1.1.5 |
April 17, 2022 |
.NET |
2.0.11 |
March 15, 2022 |
Snowpark-Bibliothek für Scala und Java |
1.14.0 |
September 14, 2024 |
Node.js |
1.6.9 |
April 21, 2022 |
Spark-Konnektor |
3.0.0 |
July 31, 2024 |
PHP |
3.0.2 |
August 29, 2024 |
SnowSQL |
1.3.2 |
August 12, 2024 |
Wenn Sie versuchen, einen Treiber zu verwenden, der größere Objekte nicht unterstützt, wird ein Fehler ähnlich dem folgenden Beispiel zurückgegeben:
100067 (54000): The data length in result column <column_name> is not supported by this version of the client.
Actual length <actual_size> exceeds supported length of 16777216.
Kontinuierliches Laden von Daten (d. h. Snowpipe) und Dateigrößen¶
Snowpipe wurde entwickelt, um neue Daten typischerweise innerhalb einer Minute nach dem Senden einer Dateibenachrichtigung zu laden. Das Laden kann jedoch bei wirklich großen Dateien erheblich länger dauern oder in Fällen, in denen eine ungewöhnliche Menge an Computeressourcen erforderlich ist, um die neuen Daten zu dekomprimieren, zu entschlüsseln und zu transformieren.
Zusätzlich zum Ressourcenverbrauch sind Betriebskosten für die Verwaltung von Dateien in der internen Ladewarteschlange in den Nutzungskosten für Snowpipe enthalten. Dieser Overhead steigt in Abhängigkeit von der Anzahl der Dateien, die der Warteschlange zum Laden hinzugefügt werden. Diese Overhead-Kosten erscheinen auf der Abrechnung als Snowpipe-Gebühren, da Snowpipe für die Ereignisbenachrichtigungen bei der automatischen Aktualisierung der externen Tabellen verwendet wird.
Für eine möglichst effiziente und kostengünstige Nutzung von Snowpipe empfehlen wir, die Empfehlungen zur Dateigröße unter Best Practices für die Dateigrößen (unter diesem Thema) zu befolgen. Das Laden von Datendateien, die etwa 100-250 MB oder größer sind, reduziert die Overhead-Kosten im Verhältnis zur Menge der insgesamt bis zu dem Punkt geladenen Daten, an dem die Overhead-Kosten unerheblich werden.
Wenn es länger als eine Minute dauert, MBs von Daten in Ihrer Quellanwendung zusammenzufassen, sollten Sie erwägen, einmal pro Minute eine neue (möglicherweise kleinere) Datendatei zu erstellen. Dieser Ansatz führt in der Regel zu einem ausgewogenen Verhältnis zwischen Kosten (d. h. Ressourcen, die für die Verwaltung der Snowpipe-Warteschlange und den eigentlichen Ladevorgang benötigt werden) und Leistung (d. h. Latenzzeit beim Laden).
Das Erstellen von kleineren Datendateien und deren Staging im Cloudspeicher häufiger als einmal pro Minute hat folgende Nachteile:
Eine Verkürzung der Latenzzeit zwischen Staging und Laden von Daten kann nicht garantiert werden.
Die Betriebskosten für die Verwaltung von Dateien in der internen Ladewarteschlange sind in den Nutzungskosten für Snowpipe enthalten. Diese Verwaltungskosten steigen in Abhängigkeit von der Anzahl der Dateien, die zum Laden in die Warteschlange eingefügt werden.
Verschiedene Tools können Datendateien aggregieren und stapeln. Eine praktische Option ist Amazon Data Firehose. Firehose ermöglicht es, sowohl die gewünschte Dateigröße, die sogenannte Puffergröße, als auch das Warteintervall zu definieren, nach dem eine neue Datei gesendet wird (in diesem Fall an den Cloudspeicher), das sogenannte Pufferintervall. Weitere Informationen dazu finden Sie in der Amazon Data Firehose-Dokumentation. Wenn Ihre Quellanwendung normalerweise innerhalb einer Minute genug Daten sammelt, um Dateien zu füllen, die über dem empfohlenen Maximum für eine optimale Parallelverarbeitung liegen, können Sie die Puffergröße verringern, um die Bereitstellung kleinerer Dateien auszulösen. Wenn Sie die Einstellung des Pufferintervalls bei 60 Sekunden (dem Minimalwert) belassen, vermeiden Sie, zu viele Dateien zu erstellen oder die Latenzzeit zu erhöhen.
Vorbereiten von durch Trennzeichen getrennten Textdateien¶
Beachten Sie die folgenden Richtlinien, wenn Sie Dateien mit durch Trennzeichen getrenntem Text (CSV) zum Laden vorbereiten:
UTF-8 ist der Standardzeichensatz, es werden jedoch auch zusätzliche Codierungen unterstützt. Verwenden Sie die Dateiformatoption ENCODING, um den Zeichensatz für die Datendateien festzulegen. Weitere Informationen dazu finden Sie unter CREATE FILE FORMAT.
Felder, die Trennzeichen enthalten, sollten in Anführungszeichen (einfach oder doppelt) gesetzt werden. Wenn die Daten einfache oder doppelte Anführungszeichen enthalten, müssen diese Anführungszeichen in Escape-Zeichen eingeschlossen werden.
Zeilenumbrüche werden auf Windows-Systemen häufig in Verbindung mit einem Zeilenvorschubzeichen verwendet, um das Ende einer Zeile zu markieren (
\r \n
). Felder, die Zeilenumbrüche enthalten, sollten ebenfalls in Anführungszeichen (einfach oder doppelt) gesetzt werden.Die Anzahl der Spalten in jeder Zeile sollte konsistent sein.
Semistrukturierte Datendateien und Subkolumnarisierung¶
Wenn semistrukturierte Daten in eine VARIANT-Spalte eingefügt werden, verwendet Snowflake bestimmte Regeln, um so viele der Daten wie möglich in eine spaltenweise Form zu extrahieren. Der Rest der Daten wird als eine einzige Spalte in einer geparsten, semistrukturierten Struktur gespeichert.
Standardmäßig extrahiert Snowflake maximal 200 Elemente pro Partition und Tabelle. Wenn Sie dieses Limit erhöhen möchten, wenden Sie sich an den Snowflake-Support.
Elemente, die nicht extrahiert werden¶
Elemente mit den folgenden Eigenschaften werden nicht in eine Spalte extrahiert:
Elemente, die auch nur einen einzigen „null“-Wert enthalten, werden nicht in eine Spalte extrahiert. Beachten Sie, dass dies für Elemente mit „Null“-Werten gilt und nicht für Elemente mit fehlenden Werten, die in Spaltenform dargestellt werden.
Diese Regel stellt sicher, dass keine Informationen verloren gehen (d. h., dass der Unterschied zwischen VARIANT-„null“-Werten und SQL-NULL-Werten erhalten bleibt).
Elemente, die verschiedene Datentypen enthalten. Beispiel:
Das
foo
-Element in einer Zeile enthält eine Nummer:{"foo":1}
Das gleiche Element in einer anderen Zeile enthält eine Zeichenfolge:
{"foo":"1"}
Auswirkung der Extraktion auf Abfragen¶
Wenn Sie ein semistrukturiertes Element abfragen, verhält sich die Ausführungs-Engine von Snowflake unterschiedlich, je nachdem, ob ein Element extrahiert wurde.
Wenn das Element in eine Spalte extrahiert wurde, wird nur die extrahierte Spalte durchsucht.
Wenn das Element nicht in eine Spalte extrahiert wurde, muss die Engine die gesamte JSON-Struktur scannen und dann für jede Zeile die Struktur durchlaufen, um Werte auszugeben. Dies hat Auswirkungen auf die Verarbeitungsleistung.
Um die Auswirkungen auf die Leistung für nicht extrahierte Elemente zu vermeiden, gehen Sie wie folgt vor:
Extrahieren Sie semistrukturierte Datenelemente, die „null“-Werte enthalten, in relationale Spalten, bevor Sie sie laden.
Wenn die „null“-Werte in Ihren Dateien fehlende Werte anzeigen und keine andere besondere Bedeutung haben, empfehlen wir Ihnen, beim Laden von Dateien mit semistrukturierten Daten die Dateiformatoption STRIP_NULL_VALUES auf TRUE zu setzen. Mit dieser Option werden OBJECT-Elemente oder ARRAY-Elemente, die „null“-Werte enthalten, entfernt.
Stellen Sie sicher, dass jedes einzelne Element Werte eines einzigen Datentyps speichert, der dem Format eigen ist (z. B. Zeichenfolge oder Zahl für JSON).
Richtlinien für numerische Daten¶
Vermeiden Sie eingebettete Zeichen wie Kommas (z. B.
123,456
).Wenn eine Zahl eine gebrochene Komponente enthält, sollte sie vom gesamten Zahlenabschnitt durch einen Dezimalpunkt getrennt werden (z. B.
123456.789
).Nur Oracle. Die Oracle-Typen NUMBER oder NUMERIC erlauben eine beliebige Dezimalstellenzahl, d. h. sie akzeptieren Werte mit dezimalen Komponenten, auch wenn der Datentyp nicht mit einer Genauigkeit oder Dezimalstellenzahl definiert wurde. In Snowflake hingegen müssen Spalten, die für Werte mit Dezimalkomponenten ausgelegt sind, mit einer Dezimalstellenzahl definiert werden, um den Dezimalanteil zu erhalten.
Richtlinien für Datums- und Zeitstempel-Daten¶
Weitere Informationen zu den unterstützten Formaten für Datums-, Uhrzeit- und Zeitstempeldaten finden Sie unter Eingabe- und Ausgabeformate für Datum und Uhrzeit.
Nur Oracle. Der Oracle-Datentyp DATE kann Datums- oder Zeitstempelinformationen enthalten. Wenn Ihre Oracle-Datenbank DATE-Spalten enthält, die auch zeitbezogene Informationen speichern, ordnen Sie diese Spalten in Snowflake einem TIMESTAMP-Datentyp statt DATE zu.
Bemerkung
Snowflake überprüft Zeitdatenwerte zum Zeitpunkt des Ladevorgangs. Ungültige Werte für Datum, Uhrzeit und Zeitstempel (z. B. 0000-00-00
) führen zu einem Fehler.