Einführung in Amazon S3-Übertragungen

Mit BigQuery Data Transfer Service für Amazon S3 können Sie wiederkehrende Ladejobs von Amazon S3 in BigQuery automatisch planen und verwalten.

Unterstützte Dateiformate

BigQuery Data Transfer Service unterstützt das Laden von Daten aus Amazon S3 in einem der folgenden Formate:

  • Kommagetrennte Werte (CSV)
  • JSON (durch Zeilenumbruch getrennt)
  • Avro
  • Parquet
  • ORC

Unterstützte Komprimierungstypen

BigQuery Data Transfer Service für Amazon S3 unterstützt das Laden komprimierter Daten. Die Komprimierungstypen, die von BigQuery Data Transfer Service unterstützt werden, sind mit jenen identisch, die von BigQuery-Ladejobs unterstützt werden. Weitere Informationen finden Sie unter Komprimierte und unkomprimierte Daten laden.

Voraussetzungen für Amazon S3

Wenn Sie Daten aus einer Amazon S3-Datenquelle laden möchten, gehen Sie folgendermaßen vor:

  • Geben Sie den Amazon S3-URI für Ihre Quelldaten an
  • Halten Sie Ihre Zugangsschlüssel-ID bereit
  • Halten Sie Ihren geheimen Zugangsschlüssel bereit
  • Richten Sie mindestens die AWS-Verwaltungsrichtlinie AmazonS3ReadOnlyAccess für Ihre Amazon S3-Quelldaten ein

Amazon S3-URIs

Wenn Sie den Amazon S3-URI angeben, muss der Pfad das Format s3://bucket/folder1/folder2/... haben. Nur der Bucket-Name der obersten Ebene ist erforderlich. Ordnernamen sind optional. Wenn Sie einen URI angeben, der nur den Bucket-Namen enthält, werden alle Dateien im Bucket übertragen und in BigQuery geladen.

Laufzeitparametrisierung für Amazon S3-Übertragungen

Der Amazon S3-URI und die Zieltabelle lassen sich parametrisieren, um Daten nach Datum organisiert aus Amazon S3-Buckets zu laden. Beachten Sie, dass der Bucket-Teil des URI nicht parametrisiert werden kann. Die von Amazon S3-Übertragungen verwendeten Parameter sind die gleichen wie die von Cloud Storage-Übertragungen.

Weitere Informationen finden Sie unter Laufzeitparameter in Übertragungen verwenden.

Datenaufnahme für Amazon S3-Übertragungen

Sie können angeben, wie Daten in BigQuery geladen werden. Wählen Sie dazu beim Einrichten einer Amazon S3-Übertragung eine Schreibeinstellung in der Übertragungskonfiguration 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.

Unterstützung von Platzhaltern für Amazon S3-URIs

Wenn Ihre Quelldaten in mehrere Dateien mit einem gemeinsamen Basisnamen aufgeteilt sind, können Sie beim Laden der Daten im URI einen Platzhalter verwenden. Ein Platzhalter besteht aus einem Sternchen (*) und kann mit Ausnahme des Bucket-Namens überall im Amazon S3 URI verwendet werden.

Obwohl im Amazon S3-URI mehr als ein Platzhalter verwendet werden kann, ist eine Optimierung möglich, wenn der Amazon S3-URI nur einen einzelnen Platzhalter angibt:

  • Es gibt ein höheres Limit für die maximale Anzahl von Dateien pro Übertragungsausführung.

  • Der Platzhalter reicht über Verzeichnisgrenzen hinweg. Zum Beispiel schließt der Amazon S3-URI s3://my-bucket/*.csv die Datei s3://my-bucket/my-folder/my-subfolder/my-file.csv ein.

Beispiele für Amazon S3-URIs

Beispiel 1

Um eine einzelne Datei aus Amazon S3 in BigQuery zu laden, geben Sie den Amazon S3-URI der Datei an.

s3://my-bucket/my-folder/my-file.csv

Beispiel 2

Wenn Sie alle Dateien aus einem Amazon S3-Bucket in BigQuery laden möchten, geben Sie nur den Bucket-Namen mit oder ohne Platzhalter an.

s3://my-bucket/

oder

s3://my-bucket/*

Beachten Sie, dass s3://my-bucket* kein zulässiger Amazon S3-URI ist, da im Bucket-Namen kein Platzhalter verwendet werden kann.

Beispiel 3

Wenn Sie aus Amazon S3 alle Dateien mit einem gemeinsamen Präfix laden möchten, geben Sie das gemeinsame Präfix gefolgt von einem Platzhalter an.

s3://my-bucket/my-folder/*

Im Gegensatz zum Laden aller Dateien aus einem Amazon S3-Bucket der obersten Ebene muss der Platzhalter am Ende des Amazon S3-URI angegeben werden, damit Dateien geladen werden.

Beispiel 4

Wenn Sie aus Amazon S3 alle Dateien mit einem ähnlichen Pfad laden möchten, geben Sie das gemeinsame Präfix gefolgt von einem Platzhalter an.

s3://my-bucket/my-folder/*.csv

Beispiel 5

Beachten Sie, dass die Platzhalter Verzeichnisse überspannen. Es werden also alle csv-Dateien in my-folder sowie in Unterordnern von my-folder in BigQuery geladen.

Wenn sich diese Quelldateien in einem Ordner logs befinden:

s3://my-bucket/logs/logs.csv
s3://my-bucket/logs/system/logs.csv
s3://my-bucket/logs/some-application/system_logs.log
s3://my-bucket/logs/logs_2019_12_12.csv

können sie so angegeben werden:

s3://my-bucket/logs/*

Beispiel 6

Wenn Sie diese Quelldateien haben, aber nur Dateien mit dem Dateinamen logs.csv übertragen möchten:

s3://my-bucket/logs.csv
s3://my-bucket/metadata.csv
s3://my-bucket/system/logs.csv
s3://my-bucket/system/users.csv
s3://my-bucket/some-application/logs.csv
s3://my-bucket/some-application/output.csv

können Sie so die Dateien mit logs.csv im Namen angeben:

s3://my-bucket/*logs.csv

Beispiel 7

Durch die Verwendung mehrerer Platzhalter lässt sich besser steuern, welche Dateien übertragen werden. Allerdings sind dann die Limits niedriger. Die Verwendung mehrerer Platzhalter bedeutet, dass jeder Platzhalter nur bis zum Ende eines Pfads innerhalb eines Unterverzeichnisses reicht. Angenommen, es gibt in Amazon S3 die folgenden Quelldateien:

s3://my-bucket/my-folder1/my-file1.csv
s3://my-bucket/my-other-folder2/my-file2.csv
s3://my-bucket/my-folder1/my-subfolder/my-file3.csv
s3://my-bucket/my-other-folder2/my-subfolder/my-file4.csv

Wenn nur my-file1.csv und my-file2.csv übertragen werden sollen, verwenden Sie folgenden Wert für den Amazon S3-URI:

s3://my-bucket/*/*.csv

Da keiner der Platzhalter Verzeichnisse überspannt, beschränkt dieser URI die Übertragung auf die CSV-Dateien in my-folder1 und my-other-folder2. Unterordner würden bei der Übertragung nicht berücksichtigt werden.

AWS-Zugriffsschlüssel

Die Zugriffsschlüssel-ID und der geheime Zugriffsschlüssel werden dazu verwendet, in Ihrem Namen auf die Amazon S3-Daten zuzugreifen. Erstellen Sie als Best Practice eine eindeutige Zugriffsschlüssel-ID und einen geheimen Zugriffsschlüssel, die speziell für Amazon S3-Übertragungen bestimmt sind, um minimalen Zugriff auf den BigQuery Data Transfer Service zu gewähren. Informationen zum Verwalten Ihrer Zugriffsschlüssel finden Sie in der allgemeinen Referenzdokumentation zu AWS.

Überlegungen zur Konsistenz

Wenn Sie Daten von Amazon S3 übertragen, werden möglicherweise einige Ihrer Daten nicht an BigQuery übertragen, insbesondere wenn die Dateien erst vor Kurzem dem Bucket hinzugefügt wurden. Es sollte ungefähr 10 Minuten dauern, bis eine Datei für BigQuery Data Transfer Service verfügbar ist, nachdem sie dem Bucket hinzugefügt wurde. In einigen Fällen kann es jedoch länger als 10 Minuten dauern.

Weitere Informationen zum Amazon S3-Konsistenzmodell finden Sie unter Amazon S3-Datenkonsistenzmodell in der Amazon S3-Dokumentation.

Best Practice bezüglich der Kosten für die ausgehende Datenübertragung

Übertragungen von Amazon S3 können fehlschlagen, wenn die Zieltabelle nicht richtig konfiguriert wurde. Folgende Gründe können zu einer falschen Konfiguration führen:

  • Die Zieltabelle ist nicht vorhanden.
  • Das Tabellenschema ist nicht definiert.
  • Das Tabellenschema ist nicht mit den übertragenen Daten kompatibel.

Um Amazon S3-Kosten für ausgehende Datenübertragungen zu vermeiden, sollten Sie zuerst eine Übertragung mit einer kleinen, aber repräsentativen Teilmenge der Dateien testen. Klein bedeutet, dass die Datenmenge und die Dateianzahl klein sein sollten.

Preise

Die Preise für BigQuery Data Transfer Service finden Sie auf der Seite Preise.

Beachten Sie, dass durch die Nutzung dieses Services Kosten außerhalb von Google anfallen können. Weitere Informationen dazu finden Sie auf der Seite Amazon S3 – Preise.

Kontingente und Limits

BigQuery Data Transfer Service verwendet Ladejobs, um Amazon S3-Daten in BigQuery zu laden. Alle BigQuery-Kontingente und -Limits für Ladejobs gelten für wiederkehrende Amazon S3-Übertragungen. Dabei ist Folgendes zu beachten:

Wert Limit
Maximale Größe pro Ladejob-Übertragungsausführung 15 TB
Maximale Anzahl von Dateien pro Übertragungsausführung, wenn der Amazon S3-URI 0 oder 1 Platzhalter enthält 10.000.000 Dateien
Maximale Anzahl von Dateien pro Übertragungsausführung, wenn der Amazon S3-URI mehr als 1 Platzhalter enthält 10.000 Dateien

Nächste Schritte