Vorbereiten Ihrer 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 und Einschränkungen für 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 Ladeoperationen, die parallel ausgeführt werden, 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 etwa 10 MB bis 100 MB zu erstellen. 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 Server des aktiven Warehouse zu verteilen. Die Anzahl der Datendateien, die parallel verarbeitet werden, wird durch die Anzahl und Kapazität der Server in einem Warehouse bestimmt. Wir empfehlen ein zeilenweises Aufteilen der Dateien, um Datensätze zu vermeiden, die sich über Blöcke verteilen.

Wenn Ihre Quelldatenbank es Ihnen nicht erlaubt, Datendateien in kleineren Blöcken zu exportieren, können Sie das Dienstprogramm eines Drittanbieters verwenden, um große CSV-Dateien aufzuteilen.

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 Einzeldatei ist 8 GB groß und enthält 10 Millionen Zeilen. Durch 100.000 geteilt, ist jede der 100 kleineren Dateien 80 MB groß (10 Millionen / 100.000 = 100). Die aufgeteilten Dateien haben den Namen pages<Suffix>.

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.

Teilstrukturierte Datengrößenbeschränkungen

Der Datentyp VARIANT erlegt den einzelnen Zeilen eine Größenbeschränkung von 16 MB (komprimiert) auf.

Im Allgemeinen sind JSON- und Avro-Datasets eine einfache Verkettung mehrerer Dokumente. Die JSON- oder Avro-Ausgabe einer Software besteht aus einem einzigen großen Array, das mehrere Datensätze enthält. Es ist nicht erforderlich, die Dokumente durch Zeilenumbrüche oder Kommas zu trennen, obwohl beide unterstützt werden.

Stattdessen empfehlen wir, die Dateiformatoption STRIP_OUTER_ARRAY für den Befehl COPY INTO <Tabelle> zu aktivieren, um die äußere Array-Struktur zu entfernen und die Datensätze in separate Tabellenzeilen zu laden:

COPY INTO <table>
FROM @~/<file>.json
FILE_FORMAT = (TYPE = 'JSON' STRIP_OUTER_ARRAY = true);

Größenbeschränkungen für Parquet-Daten

Derzeit kann es beim Laden großer Parquet-Dateien (z. B. größer als 3 GB) zu einem Timeout kommen. Teilen Sie große Dateien zum Laden in Dateien von 1 GB (oder kleiner) auf.

Kontinuierliches Laden von Daten (z. B. 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. Diese Betriebskosten steigen in Abhängigkeit von der Anzahl der Dateien, die zum Laden in die Warteschlange gestellt werden. Snowpipe berechnet 0,06 Credits pro 1000 Dateien in der Warteschlange.

Für ein möglichst effizientes und kostengünstiges Laden mit Snowpipe wird empfohlen, die unter Best Practices und Einschränkungen für Dateigrößen (unter diesem Thema) bereitgestellten Empfehlungen zur Dateigröße zu befolgen. Wenn es länger als eine Minute dauert, MBs von Daten in Ihrer Quellanwendung zu sammeln, 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 Reduzierung der Latenzzeit zwischen Staging und Laden der 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 Kinesis 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 Kinesis 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 erhöhen. 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 Spaltenbildung

Wenn semistrukturierte Daten in eine VARIANT-Spalte eingefügt werden, extrahiert Snowflake so viele der Daten wie möglich in eine spaltenweise Form, basierend auf bestimmten Regeln. Der Rest wird als eine einzige Spalte in einer geparsten, semistrukturierten Struktur gespeichert. Derzeit werden Elemente mit den folgenden Eigenschaften 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. die Differenz zwischen VARIANT-„null“-Werten und SQL NULL-Werten wird nicht verschleiert.

  • 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"}
    

Wenn ein semistrukturiertes Element abgefragt wird:

  • Wenn das Element in eine Spalte extrahiert wurde, scannt das Ausführungsmodul von Snowflake (das spaltenweise vorgeht) nur die extrahierte Spalte.

  • Wenn das Element nicht in eine Spalte extrahiert wurde, muss das Ausführungsmodul die gesamte JSON-Struktur scannen und dann für jede Zeile die Struktur durchlaufen, um Werte auszugeben, was sich auf die Leistung auswirkt.

So vermeiden Sie diese Leistungseinbuße:

  • 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 semistrukturierter Datendateien die Dateiformatoption STRIP_NULL_VALUES auf TRUE zu setzen. Mit dieser Option werden Objektelemente oder Array-Elemente, die „null“-Werte enthalten, entfernt.

  • Stellen Sie sicher, dass jedes eindeutige Element Werte eines einzelnen nativen Datentyps speichert (Zeichenfolge oder Zahl).

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 Skalierung, d. h. sie akzeptieren Werte mit dezimalen Komponenten, auch wenn der Datentyp nicht mit einer Genauigkeit oder Skalierung definiert wurde. In Snowflake hingegen müssen Spalten, die für Werte mit Dezimalkomponenten ausgelegt sind, mit einer Skala definiert werden, um den Dezimalanteil zu erhalten.

Richtlinien für Datums- und Zeitstempel-Daten

  • Datums-, Zeit- und Zeitstempeldaten sollten auf der Grundlage der folgenden Komponenten formatiert werden:

    Format

    Beschreibung

    YYYY

    Vierstellige Jahresangabe.

    YY

    Zweistellige Jahresangabe, gesteuert durch den Sitzungsparameter TWO_DIGIT_CENTURY_START, z. B. wenn dieser auf 1980 gesetzt ist, die Werte 79 und 80, die als 2079 bzw. 1980 geparst werden.

    MM

    Zweistellige Monatsangabe (01=Januar usw.).

    MON

    Vollständiger oder abgekürzter Monatsname.

    DD

    Zweistellige Tagesangabe des Monats (01 bis 31).

    DY

    Abgekürzter Wochentag.

    HH24

    Zwei Ziffern für die Stunde (00 bis 23); am/pm nicht erlaubt.

    HH12

    Zwei Ziffern für die Stunde (01 bis 12); „am“/„pm“ NICHT erlaubt.

    AM, PM

    Ante Meridiem (am) / Post Meridiem (pm); zur Verwendung mit HH12.

    MI

    Zwei Ziffern für die Minute (00 bis 59).

    SS

    Zwei Ziffern für die Sekunde (00 bis 59).

    FF

    Sekundenbruchteile mit einer Genauigkeit von 0 (Sekunden) bis 9 (Nanosekunden), z. B. FF, FF0, FF3, FF9. Die Angabe von FF entspricht FF6 (Mikrosekunden).

    TZH:TZM, TZHTZM, TZH

    Zeitzonenstunde und -minute, Offset von UTC. Kann +/- als Vorzeichen erhalten.

  • 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.