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. Dazu wählen Sie beim Einrichten einer Cloud Storage-Übertragung in der Übertragungskonfiguration eine Schreibeinstellung aus.

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 einen updated-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 wird file_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 einen updated-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 wird file_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:

  1. Öffnen Sie die Cloud Storage-Konsole.

    Cloud Storage-Konsole

  2. Gehen Sie zum Speicherort des Objekts (Datei), das die Quelldaten enthält.

  3. Klicken Sie auf den Namen des gewünschten Objekts.

    Die Seite Objektdetails wird geöffnet.

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

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