Einführung in Cloud Storage-Übertragungen
Mit BigQuery Data Transfer Service für Cloud Storage können Sie wiederkehrende Datenladevorgänge von Cloud Storage-Buckets nach BigQuery planen. Der Pfad zu den in Cloud Storage gespeicherten Daten und die Zieltabelle kann beide parametrisiert werden, sodass Sie Daten aus Cloud Storage-Buckets nach Datum geordnet laden können.
Unterstützte Dateiformate
Derzeit unterstützt BigQuery Data Transfer Service das Laden von Daten aus Cloud Storage mit den folgenden Formaten:
- Kommagetrennte Werte (CSV)
- JSON (durch Zeilenumbruch getrennt)
- Avro
- Parquet
- ORC
Unterstützte Komprimierungstypen
Der BigQuery Data Transfer Service für Cloud Storage unterstützt das Laden komprimierter Daten. Die Komprimierungstypen, die vom BigQuery Data Transfer Service unterstützt werden, sind mit denen identisch, die von BigQuery-Ladejobs unterstützt werden. Weitere Informationen finden Sie unter Komprimierte und unkomprimierte Daten laden.
Datenaufnahme für Cloud Storage-Übertragungen
Sie können angeben, wie Daten in BigQuery geladen werden, indem Sie eine Schreibeinstellung in der Übertragungskonfiguration auswählen, wenn Sie eine Cloud Storage-Übertragung einrichten.
Es gibt zwei Arten von Schreibeinstellungen: inkrementelle Übertragungen und abgeschnittene Übertragungen.Inkrementelle Übertragungen
Eine Übertragungskonfiguration mit der Schreibeinstellung APPEND
oder WRITE_APPEND
, auch inkrementelle Übertragung genannt, fügt inkrementell neue Daten seit der letzten erfolgreichen Übertragung an eine BigQuery-Zieltabelle an. Wenn eine Übertragungskonfiguration mit der Schreibeinstellung APPEND
ausgeführt wird, filtert BigQuery Data Transfer Service nach Dateien, die seit dem letzten erfolgreichen Übertragungslauf geändert wurden. Um zu ermitteln, wann eine Datei geändert wird, prüft BigQuery Data Transfer Service die Dateimetadaten auf das Attribut „Zeitpunkt der letzten Änderung“. BigQuery Data Transfer Service prüft beispielsweise das Zeitstempelattribut updated
in einer Cloud Storage-Datei. Wenn BigQuery Data Transfer Service Dateien mit einem „Zeitpunkt der letzten Änderung“ findet, der nach dem Zeitstempel der letzten erfolgreichen Übertragung aufgetreten ist, überträgt BigQuery Data Transfer Service diese Dateien inkrementell.
Sehen Sie sich das folgende Beispiel für eine Cloud Storage-Übertragung an, um die Funktionsweise inkrementeller Übertragungen zu veranschaulichen. Ein Nutzer erstellt zum Zeitpunkt 2023-07-01T00:00Z in einem Cloud Storage-Bucket eine Datei namens file_1
. Der Zeitstempel updated
für file_1
ist der Zeitpunkt, zu dem die Datei erstellt wurde. Der Nutzer erstellt dann eine inkrementelle Übertragung aus dem Cloud Storage-Bucket, der ab 2023-07-01T03:00Z einmal täglich um 03:00Z ausgeführt wird.
- Zum Zeitpunkt 2023-07-01T03:00Z beginnt die erste Übertragungsausführung. Da dies die erste Übertragungsausführung für diese Konfiguration ist, versucht BigQuery Data Transfer Service, alle Dateien, die mit dem Quell-URI übereinstimmen, in die BigQuery-Zieltabelle zu laden. Die Übertragungsausführung ist erfolgreich und BigQuery Data Transfer Service lädt
file_1
erfolgreich in die BigQuery-Zieltabelle. - Die nächste Übertragungsausführung zum Zeitpunkt 2023-07-02T03:00Z erkennt keine Dateien, bei denen das Zeitstempelattribut
updated
größer als die letzte erfolgreiche Übertragungsausführung ist (2023-07-01T03:00Z). Die Übertragungsausführung ist erfolgreich, ohne zusätzliche Daten in die BigQuery-Zieltabelle zu laden.
Das vorherige Beispiel zeigt, wie BigQuery Data Transfer Service das Zeitstempelattribut updated
der Quelldatei prüft, um festzustellen, ob Änderungen an den Quelldateien vorgenommen wurden, und um diese Änderungen zu übertragen, falls welche erkannt wurden.
Angenommen, der Nutzer erstellt dann zum Zeitpunkt 2023-07-03T00:00Z im Cloud Storage-Bucket eine weitere Datei mit dem Namen file_2
. Der Zeitstempel updated
für file_2
ist der Zeitpunkt, zu dem die Datei erstellt wurde.
- Die nächste Übertragungsausführung zum Zeitpunkt 2023-07-03T03:00Z erkennt, dass
file_2
einenupdated
-Zeitstempel hat, der größer als die letzte erfolgreiche Übertragungsausführung ist (2023-07-01T03:00Z). Angenommen, die Übertragungsausführung schlägt aufgrund eines vorübergehenden Fehlers fehl. In diesem Szenario wirdfile_2
nicht in die BigQuery-Zieltabelle geladen. Der Zeitstempel der letzten erfolgreichen Übertragungsausführung bleibt bei 2023-07-01T03:00Z. - Die nächste Übertragungsausführung zum Zeitpunkt 2023-07-04T03:00Z erkennt, dass
file_2
einenupdated
-Zeitstempel hat, der größer als die letzte erfolgreiche Übertragungsausführung ist (2023-07-01T03:00Z). Dieses Mal wird die Übertragung ohne Probleme abgeschlossen. Daher wirdfile_2
erfolgreich in die BigQuery-Zieltabelle geladen. - Die nächste Übertragungsausführung zum Zeitpunkt 2023-07-05T03:00Z erkennt keine Dateien, bei denen der
updated
-Zeitstempel größer als die letzte erfolgreiche Übertragungsausführung ist (2023-07-04T03:00Z). Die Übertragungsausführung ist erfolgreich, ohne zusätzliche Daten in die BigQuery-Zieltabelle zu laden.
Das vorherige Beispiel zeigt, dass bei einer fehlgeschlagenen Übertragung keine Dateien in die BigQuery-Zieltabelle übertragen werden. Alle Dateiänderungen werden bei der nächsten erfolgreichen Übertragungsausführung übertragen. Alle nachfolgenden erfolgreichen Übertragungen nach einer fehlgeschlagenen Übertragung verursachen keine doppelten Daten. Bei einer fehlgeschlagenen Übertragung können Sie auch außerhalb der regelmäßig geplanten Zeit eine Übertragung manuell auslösen.
Abgeschnittene Übertragungen
Eine Übertragungskonfiguration mit der Schreibpräferenz MIRROR
oder WRITE_TRUNCATE
, auch als abgeschnittene Übertragung bezeichnet, überschreibt die Daten in der BigQuery-Zieltabelle bei jedem Übertragungslauf mit Daten aus allen Dateien, die dem Quell-URI entsprechen. MIRROR
überschreibt eine neue Kopie der Daten in der Zieltabelle. Wenn die Zieltabelle einen Partitions-Decorator verwendet, überschreibt die Übertragungsausführung nur Daten in der angegebenen Partition. Eine Zieltabelle mit einem Partitions-Decorator hat das Format my_table${run_date}
, z. B. my_table$20230809
.
Die Ausführung derselben inkrementellen oder abgeschnittenen Übertragungen pro Tag führt nicht zu doppelten Daten. Wenn Sie jedoch mehrere verschiedene Übertragungskonfigurationen ausführen, die sich auf dieselbe BigQuery-Zieltabelle auswirken, kann der BigQuery Data Transfer Service dazu führen, dass Daten dupliziert werden.
Cloud Storage-Ressourcenpfad
Wenn Sie Daten aus einer Cloud Storage-Datenquelle laden möchten, müssen Sie den Pfad zu den Daten angeben.
Der Cloud Storage-Ressourcenpfad enthält den Bucket-Namen und das Objekt (Dateiname). Wenn der Cloud Storage-Bucket beispielsweise den Namen mybucket
hat und die Datendatei den Namen myfile.csv
hat, lautet der Bucket-URI gs://mybucket/myfile.csv
.
BigQuery unterstützt keine Cloud Storage-Ressourcenpfade, die nach dem anfänglichen doppelten Schrägstrich weitere, aufeinanderfolgende Schrägstriche enthalten.
Cloud Storage-Objektnamen können mehrere aufeinanderfolgende Schrägstriche ("/") enthalten. BigQuery wandelt diese jedoch in einen einzelnen Schrägstrich um. Der folgende Ressourcenpfad ist beispielsweise in Cloud Storage gültig, funktioniert aber nicht in BigQuery: gs://bucket/my//object//name
So rufen Sie den Cloud Storage-Ressourcenpfad ab:
Öffnen Sie die Cloud Storage-Konsole.
Gehen Sie zum Speicherort des Objekts (Datei), das die Quelldaten enthält.
Klicken Sie auf den Namen des gewünschten Objekts.
Die Seite Objektdetails wird geöffnet.
Kopieren Sie den Wert im Feld gsutil URI, der mit
gs://
beginnt.
Unterstützung von Platzhaltern für Cloud Storage-Ressourcenpfade
Wenn Cloud Storage-Daten auf mehrere Dateien verteilt sind, die einen gemeinsamen Basisnamen haben, können Sie beim Laden der Daten einen Platzhalter im Ressourcenpfad verwenden.
Im Cloud Storage-Ressourcenpfad hängen Sie dabei als Platzhalter ein Sternchen (*) an den Basisnamen an. Wenn Sie beispielsweise zwei Dateien mit den Namen fed-sample000001.csv
und fed-sample000002.csv
haben, wäre der Ressourcenpfad gs://mybucket/fed-sample*
. Dieser Platzhalter kann dann in der Google Cloud Console oder der Google Cloud CLI verwendet werden.
Sie können mehrere Platzhalter für Objekte (Dateinamen) in Buckets verwenden. Der Platzhalter kann dabei an einer beliebigen Stelle im Objektnamen stehen.
Platzhalter erweitern kein Verzeichnis in einem gs://bucket/
. So findet gs://bucket/dir/*
beispielsweise Dateien im Verzeichnis dir
, findet aber keine Dateien im Unterverzeichnis gs://bucket/dir/subdir/
.
Auch die Verwendung von Präfixen ohne Platzhalter ist nicht möglich. So führt beispielsweise gs://bucket/dir
weder zu einer Übereinstimmung mit gs://bucket/dir/file.csv
noch mit gs://bucket/file.csv
.
Allerdings können Sie mehrere Platzhalter für Dateinamen in Buckets verwenden.
Beispielsweise führt gs://bucket/dir/*/*.csv
zu Übereinstimmungen mit gs://bucket/dir/subdir/file.csv
.
Beispiele für die Unterstützung von Platzhaltern in Kombination mit parametrisierten Tabellennamen finden Sie unter Laufzeitparameter in Übertragungen.
Überlegungen zum Standort
Ihr Cloud Storage-Bucket muss sich in einer Region oder in mehreren Regionen befinden, die mit der Region oder mit dem multiregionalen Standort des Ziel-Datasets in BigQuery kompatibel ist bzw. sind.
- Wenn sich Ihr BigQuery-Dataset in einer Multiregion befindet, muss sich der Cloud Storage-Bucket mit den Daten, die Sie übertragen, am selben Standort oder an einem Standort befinden, der sich in derselben Multiregion befindet. Wenn sich Ihr BigQuery-Dataset zum Beispiel in der Multiregion "EU" befindet, kann sich der Cloud Storage-Bucket in der Region "europe-west1" innerhalb der EU befinden.
- Wenn sich Ihr Dataset in einer Region befindet, muss sich der Cloud Storage-Bucket in derselben Region befinden. Wenn sich Ihr Dataset zum Beispiel in der Region „asia-northeast1“ in Tokio befindet, kann sich der Cloud Storage-Bucket nicht am multiregionalen Standort „ASIA“ befinden.
Ausführliche Informationen zu Übertragungen und Regionen finden Sie unter Dataset-Standorte und Übertragungen.
Weitere Informationen zu Cloud Storage-Standorten finden Sie unter Bucket-Standorte in der Cloud Storage-Dokumentation.
Preise
Es gelten alle standardmäßigen BigQuery-Kontingente und -Limits.
Nach der Übertragung von Daten in BigQuery gelten die Standardpreise für das Speichern und Abfragen in BigQuery.
Daten werden nicht automatisch aus einem Cloud Storage-Bucket gelöscht, nachdem sie in BigQuery hochgeladen wurden, es sei denn, Sie geben beim Einrichten der Übertragung das Löschen an. Siehe Cloud Storage-Übertragung einrichten.
Weitere Informationen finden Sie auf der Seite Preise für Übertragungen.
Kontingente und Limits
BigQuery Data Transfer Service nutzt Ladejobs, um Cloud Storage-Daten in BigQuery zu laden.
Alle BigQuery-Kontingente und -Limits für Ladejobs gelten für wiederkehrende Cloud Storage-Ladejobs. Sie müssen jedoch Folgendes beachten:
Wert | Limit |
---|---|
Maximale Größe pro Ladejob-Übertragungsausführung | 15 TB |
Maximale Anzahl an Dateien pro Übertragungsausführung | 10.000 Dateien |
Nächste Schritte
- Mehr zum Einrichten einer Cloud Storage-Übertragung
- Laufzeitparameter in Cloud Storage-Übertragungen
- Weitere Informationen zum BigQuery Data Transfer Service