Laden von Daten¶
Unter diesem Thema sind bewährte Verfahren, allgemeine Richtlinien und wichtige Hinweise zum Laden von bereitgestellten Daten aufgeführt.
Unter diesem Thema:
Optionen für die Auswahl der Staging-Datendateien¶
Der COPY-Befehl unterstützt mehrere Optionen zum Laden von Datendateien aus einem Stagingbereich:
Nach Pfad (interne Stagingbereiche) / Präfix (Amazon S3-Bucket). Weitere Informationen finden Sie unter Daten nach Pfaden organisieren.
Angabe einer Liste bestimmter Dateien, die geladen werden sollen.
Verwendung der Mustererkennung, um bestimmte Dateien anhand von Mustern zu identifizieren.
Diese Optionen ermöglichen es Ihnen, einen Bruchteil der bereitgestellten Daten mit einem einzigen Befehl in Snowflake zu kopieren. Auf diese Weise können Sie gleichzeitige COPY-Anweisungen ausführen, die einer Teilmenge von Dateien entsprechen, wobei Sie die Vorteile paralleler Operationen nutzen.
Dateilisten¶
Der Befehl COPY INTO <Tabelle> beinhaltet einen FILES-Parameter zum Laden von Dateien unter einem bestimmten Namen.
Tipp
Von den drei Optionen zum Identifizieren/Spezifizieren von Datendateien, die von einem Stagingbereich geladen werden sollen, ist die Bereitstellung einer separaten Liste von Dateien im Allgemeinen die schnellste. Der FILES-Parameter unterstützt jedoch maximal 1.000 Dateien, was bedeutet, dass ein mit dem FILES-Parameter ausgeführter COPY-Befehl nur bis zu 1.000 Dateien laden kann.
Beispiel:
COPY INTO load1 FROM @%load1/data1/ FILES=('test1.csv', 'test2.csv', 'test3.csv')
Dateilisten können mit Pfaden kombiniert werden, um die weitere Steuerung des Datenladens zu ermöglichen.
Mustererkennung¶
Der Befehl COPY INTO <Tabelle> beinhaltet einen PATTERN-Parameter zum Laden von Dateien mithilfe eines regulären Ausdrucks.
Beispiel:
COPY INTO people_data FROM @%people_data/data1/ PATTERN='.*person_data[^0-9{1,3}$$].csv';
Die Mustererkennung mit einem regulären Ausdruck die langsamste der drei Optionen zum Identifizieren/Spezifizieren von Datendateien, die von einem Stagingbereich geladen werden sollen. Diese Option funktioniert jedoch gut, wenn Sie Ihre Dateien in benannter Reihenfolge aus Ihrer externen Anwendung exportiert haben und die Dateien in der gleichen Reihenfolge im Batch laden möchten.
Die Mustererkennung kann mit Pfaden kombiniert werden, um die weitere Steuerung des Datenladens zu ermöglichen.
Bemerkung
Der reguläre Ausdruck wird beim Massenladen von Daten anders angewendet als beim Laden von Daten mit Snowpipe.
Snowpipe schneidet alle Pfadsegmente in der Stagingbereichsdefinition vom Speicherort ab und wendet den regulären Ausdruck auf alle verbleibenden Pfadsegmente und Dateinamen an. Um die Stagingbereichsdefinition anzuzeigen, führen Sie den Befehl DESCRIBE STAGE für den Stagingbereich aus. Die URL-Eigenschaft besteht aus dem Namen des Buckets oder Containers und keinem, einem oder mehreren Pfadsegmenten. Wenn zum Beispiel der FROM-Speicherplatz in einer COPY INTO <Tabelle>-Anweisung
@s/path1/path2/ist und der URL-Wert für Stagingbereich@ss3://mybucket/path1/ist, dann schneidet Snowpipe/path1/aus dem Speicherort in der FROM-Klausel ab und wendet den regulären Ausdruck aufpath2/plus die Dateinamen im Pfad an.Beim Massenladen von Daten wird der reguläre Ausdruck auf den gesamten Speicherort in der FROM-Klausel angewendet.
Snowflake empfiehlt die Aktivierung der Cloudereignisfilterung für Snowpipe, um Kosten, Ereignisrauschen und Latenz zu reduzieren. Verwenden Sie die Option PATTERN nur dann, wenn das Ereignisfilter-Feature Ihres Cloudanbieters unzureichend ist. Weitere Informationen zum Konfigurieren der Ereignisfilterung für jeden Cloudanbieter finden Sie auf den folgenden Seiten:
Ausführen paralleler COPY-Anweisungen, die auf die gleichen Datendateien verweisen¶
Wenn eine COPY-Anweisung ausgeführt wird, setzt Snowflake einen Ladestatus in den Tabellenmetadaten für die in der Anweisung referenzierten Datendateien. Dadurch wird verhindert, dass parallele COPY-Anweisungen dieselben Dateien in die Tabelle laden und Datenduplikate werden vermieden.
Wenn die Verarbeitung der COPY-Anweisung abgeschlossen ist, passt Snowflake den Ladestatus für die Datendateien entsprechend an. Wenn eine oder mehrere Datendateien nicht geladen werden können, setzt Snowflake den Ladestatus für diese Dateien auf „Laden fehlgeschlagen“. Diese Dateien stehen für eine nachfolgende COPY-Anweisung zum Laden zur Verfügung.
Laden älterer Dateien¶
In diesem Abschnitt wird beschrieben, wie der Befehl COPY INTO <Tabelle> die Datenduplikation unterschiedlich verhindert, je nachdem, ob der Ladestatus einer Datei bekannt oder unbekannt ist. Wenn Sie Ihre Daten unter Verwendung logischer, granularer Pfade nach Datum (wie in Daten nach Pfaden organisieren empfohlen) in Stagingbereiche partitionieren und die Daten innerhalb kurzer Zeit nach der Bereitstellung laden, gilt dieser Abschnitt weitgehend für Sie nicht. Wenn der COPY-Befehl jedoch ältere Dateien (d. h. historische Datendateien) in einem Datenladevorgang überspringt, beschreibt dieser Abschnitt, wie Sie das Standardverhalten umgehen können.
Metadaten laden¶
Snowflake verwaltet detaillierte Metadaten für jede Tabelle, in die Daten geladen werden. Dazu gehören:
Name jeder Datei, aus der Daten geladen wurden
Dateigröße
ETag für die Datei
Anzahl der in der Datei analysierten Zeilen
Zeitstempel des letzten Ladevorgangs für die Datei
Informationen über Fehler, die beim Laden in der Datei aufgetreten sind.
Diese Lademetadaten verfallen nach 64 Tagen. Wenn das LAST_MODIFIED-Datum für eine Staging-Datendatei weniger oder gleich 64 Tage ist, kann der COPY-Befehl seinen Ladestatus für eine bestimmte Tabelle bestimmen und ein erneutes Laden (und eine Datenverdopplung) verhindern. Das LAST_MODIFIED-Datum ist der Zeitstempel, an dem die Datei ursprünglich bereitgestellt wurde oder wann sie zuletzt geändert wurde, je nachdem, welcher Zeitpunkt später liegt.
Wenn das LAST_MODIFIED-Datum älter als 64 Tage ist, ist der Ladestatus immer noch bekannt, wenn eines der folgenden Ereignisse weniger als oder gleich 64 Tage vor dem aktuellen Datum aufgetreten ist:
Die Datei wurde erfolgreich geladen.
Das anfängliche Dataset für die Tabelle (d. h. der erste Batch nach dem Erstellen der Tabelle) wurde geladen.
Der COPY-Befehl kann jedoch nicht endgültig feststellen, ob eine Datei bereits geladen wurde, wenn das LAST_MODIFIED-Datum älter als 64 Tage ist und das ursprüngliche Dataset mehr als 64 Tage früher in die Tabelle geladen wurde (und wenn die Datei in die Tabelle geladen wurde, was auch vor mehr als 64 Tagen der Fall war). In diesem Fall überspringt der Befehl die Datei standardmäßig, um ein versehentliches Neuladen zu verhindern.
Problemumgehungen¶
Um Dateien zu laden, deren Metadaten abgelaufen sind, setzen Sie die Kopieroption LOAD_UNCERTAIN_FILES auf „true“. Die Kopieroption verweist, falls vorhanden, auf Lademetadaten, um Datenduplikate zu vermeiden, versucht aber auch, Dateien mit abgelaufenen Lademetadaten zu laden.
Alternativ können Sie die Option FORCE so einstellen, dass alle Dateien geladen werden, wobei Sie Metadaten ignorieren, falls vorhanden. Beachten Sie, dass diese Option Dateien neu lädt und möglicherweise Daten in einer Tabelle dupliziert.
Beispiele¶
In diesem Beispiel:
Am 1. Januar wird eine Tabelle erstellt, und das initiale Laden der Tabelle erfolgt am selben Tag.
64 Tage sind vergangen. Am 7. März laufen die Lademetadaten ab.
Eine Datei wird bereitgestellt und am 27. Juli bzw. 28. Juli in die Tabelle geladen. Da die Datei einen Tag vor dem Laden bereitgestellt wurde, lag das LAST_MODIFIED-Datum innerhalb von 64 Tagen. Der Ladestatus war bekannt. Es gibt keine Daten- oder Formatierungsprobleme mit der Datei, und der COPY-Befehl lädt sie erfolgreich.
64 Tage sind vergangen. Am 28. September beträgt das LAST_MODIFIED-Datum für die bereitgestellte Datei mehr als 64 Tage. Am 29. September laufen die Lademetadaten für das erfolgreiche Laden der Datei ab.
Es wird versucht, die Datei am 1. November in dieselbe Tabelle neu zu laden. Da der COPY-Befehl nicht feststellen kann, ob die Datei bereits geladen wurde, wird die Datei übersprungen. Die Kopieroption LOAD_UNCERTAIN_FILES (oder die Kopieroption FORCE) ist erforderlich, um die Datei zu laden.
In diesem Beispiel:
Eine Datei wird am 1. Januar bereitgestellt.
64 Tage sind vergangen. Am 7. März beträgt das LAST_MODIFIED-Datum für die bereitgestellte Datei mehr als 64 Tage.
Am 29. September wird eine neue Tabelle erstellt und die bereitgestellte Datei in die Tabelle geladen. Da das anfängliche Laden der Tabelle weniger als 64 Tage zuvor erfolgte, kann der COPY-Befehl feststellen, dass die Datei noch nicht geladen wurde. Es gibt keine Daten- oder Formatierungsprobleme mit der Datei, und der COPY-Befehl lädt sie erfolgreich.
JSON-Daten: Entfernen von „null“-Werten¶
In einer VARIANT-Spalte werden NULL-Werte als Zeichenfolge gespeichert, die das Wort „null“ und nicht den SQL-NULL-Wert enthält. Wenn die „null“-Werte in Ihren JSON-Dokumenten auf fehlende Werte hinweisen und keine andere besondere Bedeutung haben, empfehlen wir, beim Laden der JSON-Dateien die Dateiformatoption STRIP_NULL_VALUES auf TRUE für den Befehl COPY INTO <Tabelle> zu setzen. Die Beibehaltung der „null“-Werte verschwendet oft Speicherplatz und verlangsamt die Abfrageverarbeitung.
CSV-Daten: Kürzen von führenden Leerzeichen¶
Wenn Ihre externe Software Felder exportiert, die in Anführungszeichen eingeschlossen sind, aber ein führendes Leerzeichen einfügt, liest Snowflake das führende Leerzeichen und nicht das öffnende Anführungszeichen als Anfang des Feldes. Die Anführungszeichen werden als Zeichenfolgendaten interpretiert.
Verwenden Sie das Dateiformat TRIM_SPACE, um unerwünschte Leerzeichen während des Datenladens zu entfernen.
Beispielsweise enthält jedes der folgenden Felder in der CSV-Beispieldatei ein führendes Leerzeichen:
"value1", "value2", "value3"
Der folgende COPY-Befehl schneidet das führende Leerzeichen ab und entfernt die Anführungszeichen, die jedes Feld einschließen:
COPY INTO mytable
FROM @%mytable
FILE_FORMAT = (TYPE = CSV TRIM_SPACE=true FIELD_OPTIONALLY_ENCLOSED_BY = '0x22');
SELECT * FROM mytable;
+--------+--------+--------+
| col1 | col2 | col3 |
+--------+--------+--------+
| value1 | value2 | value3 |
+--------+--------+--------+