Einführung in das Laden von Daten

Dieses Dokument bietet eine Übersicht über das Laden von Daten in BigQuery.

Übersicht

Es gibt mehrere Möglichkeiten, Daten in BigQuery aufzunehmen:

  • Laden Sie eine Reihe von Datensätzen im Batch.
  • Streamen Sie einzelne Datensätze oder Batches von Datensätzen.
  • Verwenden Sie Abfragen, um neue Daten zu generieren und die Ergebnisse an eine Tabelle anzuhängen oder zu überschreiben.
  • Verwenden Sie eine Anwendung oder einen Dienst eines Drittanbieters.

Laden im Batch

Beim Batch-Ladevorgang laden Sie die Quelldaten in einem einzigen Batchvorgang in eine BigQuery-Tabelle. Die Datenquelle kann beispielsweise eine CSV-Datei, eine externe Datenbank oder eine Reihe von Logdateien sein. Herkömmliche ETL-Jobs (Extrahieren, Transformieren und Laden) fallen in diese Kategorie.

Für den Batch-Ladevorgang in BigQuery stehen Ihnen folgende Optionen zur Verfügung:

  • Ladejobs Laden Sie Daten aus Cloud Storage oder aus einer lokalen Datei, indem Sie einen Ladejob erstellen. Die Datensätze können im Avro-, CSV-, JSON-, ORC- oder Parquet-Format vorliegen.
  • SQL. Mit der SQL-Anweisung LOAD DATA werden Daten aus einer oder mehreren Dateien in eine neue oder vorhandene Tabelle geladen. Sie können die Avro-Anweisung LOAD DATA zum Laden von Avro-, CSV-, JSON-, ORC- und Parquet-Dateien verwenden.
  • BigQuery Data Transfer Service Verwenden Sie den BigQuery Data Transfer Service, um das Laden von Daten aus Google-SaaS-Anwendungen (Software as a Service) oder von Anwendungen und Diensten von Drittanbietern zu automatisieren.
  • BigQuery Storage Write API. Mit der Storage Write API können Sie eine beliebig große Anzahl von Datensätzen im Batch verarbeiten und diese in einem einzigen atomaren Vorgang übergeben. Wenn der Commit-Vorgang fehlschlägt, können Sie den Vorgang sicher wiederholen. Im Gegensatz zu BigQuery-Ladejobs ist es bei der Storage Write API nicht erforderlich, die Daten in einem Zwischenspeicher wie Cloud Storage bereitzustellen.
  • Andere verwaltete Dienste. Mit anderen verwalteten Diensten Daten aus einem externen Datenspeicher exportieren und in BigQuery importieren. Sie können beispielsweise Daten aus Firestore-Exporten laden.

Bei der Auswahl einer Batchlademethode sollten die meisten dateibasierten Muster entweder einen Ladejob oder eine LOAD DATA-SQL-Anweisung verwenden, um Daten im Batch zu laden. Andere Dienste sollten im Allgemeinen den BigQuery Data Transfer Service verwenden oder Daten aus Google-Diensten exportieren.

Die Batch-Ladevorgänge können entweder einmalig oder wiederholt ausgeführt werden. Sie haben zum Beispiel folgende Möglichkeiten:

  • Sie können BigQuery Data Transfer Service-Übertragungen nach einem Zeitplan ausführen.
  • Sie können einen Orchestrierungsdienst wie Cloud Composer verwenden, um Ladejobs zu planen.
  • Mit einem Cronjob können Sie Daten nach einem Zeitplan laden.

Streaming

Beim Streaming senden Sie kontinuierlich kleinere Datenbatches, damit die Daten für eingehende Abfragen verfügbar sind. Zu den Optionen für das Streaming in BigQuery gehören:

  • Storage Write API. Die Storage Write API unterstützt die Streamingaufnahme mit hohem Durchsatz und genau einmaliger Übermittlungssemantik.
  • Dataflow. Sie können Dataflow mit dem Apache Beam SDK nutzen, um eine Streaming-Pipeline einzurichten, die in BigQuery schreibt. Weitere Informationen finden Sie unter BigQuery-E/A-Connector in der Apache Beam-Dokumentation und der Anleitung Stream von Pub/Sub zu BigQuery streamen.
  • Datastream. Datastream verwendet die BigQuery-Funktion Change Data Capture zur Erfassung von Änderungen und die Storage Write API, um Daten und Schemaaktualisierungen aus operativen Datenbanken direkt in BigQuery zu replizieren. In dieser Kurzanleitung finden Sie ein Beispiel für das Replizieren von einer Cloud SQL for PostgreSQL-Datenbank nach BigQuery.
  • BigQuery-Connector für SAP Der BigQuery-Connector für SAP ermöglicht die Replikation von SAP-Daten nahezu in Echtzeit direkt in BigQuery. Weitere Informationen finden Sie unter BigQuery-Connector für SAP – Planungsleitfaden.
  • Pub/Sub. Pub/Sub ist ein Messaging-Dienst, mit dem Sie Streaminganalysen und Datenintegrationspipelines koordinieren können. Sie können BigQuery-Abos verwenden, um Nachrichten direkt in eine vorhandene BigQuery-Tabelle zu schreiben.

Generierte Daten

Sie können mit SQL Daten generieren und die Ergebnisse in BigQuery speichern. Optionen zum Generieren von Daten:

  • Mit DML-Anweisungen (Data Manipulation Language) können Sie Bulk-Insert-Anweisungen mit einer vorhandenen Tabelle durchführen oder Abfrageergebnisse in einer neuen Tabelle speichern.

  • Mit einer CREATE TABLE ... AS-Anweisung können Sie eine neue Tabelle aus einem Abfrageergebnis erstellen.

  • Führen Sie eine Abfrage aus und speichern Sie die Ergebnisse in einer Tabelle. Sie können die Ergebnisse an eine vorhandene Tabelle anfügen oder in eine neue Tabelle schreiben. Weitere Informationen finden Sie unter Abfrageergebnisse schreiben.

Apps von Dritten

Einige Anwendungen und Dienste von Drittanbietern stellen Connectors zur Verfügung, die Daten in BigQuery aufnehmen können. Die Details der Konfiguration und Verwaltung der Aufnahmepipeline hängen von der Anwendung ab. Um beispielsweise Daten aus externen Quellen in den BigQuery-Speicher zu laden, können Sie Informatica Data Loader oder Fivetran Data-Pipelines verwenden. Weitere Informationen finden Sie unter Daten mit einer Drittanbieteranwendung laden.

Datenaufnahmemethode auswählen

Berücksichtigen Sie bei der Auswahl einer Methode zur Datenaufnahme die folgenden Punkte.

Datenquelle. Die Quelle der Daten oder das Datenformat können bestimmen, ob es einfacher ist, Batch-Ladevorgänge oder Streaming zu implementieren und zu verwalten. Beachten Sie die folgenden Punkte:

  • Wenn BigQuery Data Transfer Service die Datenquelle unterstützt, ist die direkte Übertragung der Daten in BigQuery wahrscheinlich die am einfachsten zu implementierende Lösung.

  • Wandeln Sie Daten aus Drittanbieterquellen, die vom BigQuery Data Transfer Service nicht unterstützt werden, in ein durch Batch-Ladeverfahren unterstütztes Format um und verwenden Sie stattdessen diese Methode.

  • Wenn Ihre Daten aus Spark oder Hadoop stammen, sollten Sie die Verwendung von BigQuery-Connectors in Betracht ziehen, um die Datenaufnahme zu vereinfachen.

  • Bei lokalen Dateien sollten Sie Batch-Ladejobs verwenden, insbesondere wenn BigQuery das Dateiformat unterstützt, ohne dass eine Transformation oder ein Schritt zur Datenbereinigung erforderlich ist.

  • Bei Anwendungsdaten wie Anwendungsereignissen oder Logstreams ist es möglicherweise einfacher, die Daten in Echtzeit zu streamen, anstatt Batch-Ladevorgänge zu implementieren.

Langsam wechselnde und sich schnell ändernde Daten. Wenn Sie Daten nahezu in Echtzeit aufnehmen und analysieren müssen, sollten Sie die Daten streamen. Bei Streaming sind die Daten unmittelbar nach dem Empfang jedes Datensatzes zum Abfragen verfügbar. Verwenden Sie DML-Anweisungen nicht, um eine große Anzahl von Zeilenaktualisierungen oder Einfügungen zu senden. Bei häufig aktualisierten Daten ist es oft besser, ein Änderungslog zu streamen und eine Ansicht zum Abrufen der neuesten Ergebnisse zu verwenden. Eine weitere Möglichkeit besteht darin, Cloud SQL als Online-Transaktionsverarbeitungsdatenbank (Online Transaction Processing, OLTP) zu verwenden und föderierte Abfragen zu verwenden, um die Daten in BigQuery zusammenzuführen.

Wenn sich die Quelldaten langsam ändern oder Sie regelmäßig keine ständig aktualisierten Ergebnisse benötigen, sollten Sie einen Ladejob verwenden. Wenn Sie beispielsweise die Daten verwenden, um einen täglichen oder stündlichen Bericht zu erstellen, können Ladejobs kostengünstiger sein und weniger Systemressourcen verwenden.

Ein anderes Szenario sind Daten, die nur selten oder als Reaktion auf ein Ereignis eingehen. Erwägen Sie in diesem Fall, mit Dataflow die Daten zu streamen oder mit Cloud Functions als Reaktion auf einen Trigger die Streaming API aufzurufen.

Zuverlässigkeit der Lösung. BigQuery hat ein Service Level Agreement (SLA). Sie müssen jedoch auch die Zuverlässigkeit der jeweiligen Lösung berücksichtigen, die Sie implementieren. Beachten Sie die folgenden Punkte:

  • Bei lose typisierten Formaten wie JSON oder CSV können fehlerhafte Daten zu einem kompletten Ladejob führen. Überlegen Sie, ob Sie vor dem Laden einen Schritt zur Datenbereinigung benötigen, und überlegen Sie, wie Sie auf Fehler reagieren. Sie können auch ein stark typisiertes Format wie Avro, ORC oder Parquet verwenden.
  • Für regelmäßige Ladejobs ist eine Planung mit Cloud Composer, Cron oder einem anderen Tool erforderlich. Die Planungskomponente kann in der Lösung ein Fehler sein.
  • Beim Streaming können Sie den Erfolg jedes Datensatzes überprüfen und einen Fehler schnell melden. Versuchen Sie, fehlgeschlagene Nachrichten zur späteren Analyse und Verarbeitung in eine Warteschlange für nicht verarbeitete Nachrichten zu schreiben. Weitere Informationen zu BigQuery-Streamingfehlern finden Sie unter Fehlerbehebung bei Streaming-Einfügungen.
  • Streaming- und Ladejobs unterliegen Kontingenten. Informationen zum Umgang mit Kontingentfehlern finden Sie unter Fehlerbehebung bei BigQuery-Kontingentfehlern.
  • Lösungen von Drittanbietern können in Bezug auf Konfigurierbarkeit, Zuverlässigkeit, Reihenfolgengarantien und andere Faktoren variieren. Daher sollten Sie diese Aspekte in Betracht ziehen, bevor Sie eine Lösung implementieren.

Latenz: Überlegen Sie, wie viele Daten Sie laden möchten und wie schnell die Daten verfügbar sein müssen. Streaming bietet die niedrigste Latenz, die für Analysen zur Verfügung steht. Regelmäßige Ladejobs haben eine höhere Latenz, da neue Daten erst nach Abschluss eines Ladejobs verfügbar sind.

Für Ladejobs wird standardmäßig ein gemeinsamer Pool von Slots verwendet. Ein Ladejob wartet möglicherweise im Status "Ausstehend" bis Slots verfügbar sind, insbesondere wenn Sie eine sehr große Datenmenge laden. Wenn dies zu einer unzulässigen Wartezeit führt, können Sie eigene Slots erwerben, anstatt den gemeinsamen Slot-Pool zu nutzen. Weitere Informationen finden Sie unter Einführung in Reservierungen.

Die Abfrageleistung ist bei externen Datenquellen mitunter geringer als für die in BigQuery gespeicherte Daten. Wenn die Minimierung der Abfragelatenz wichtig ist, empfehlen wir, die Daten in BigQuery zu laden.

Datenaufnahmeformat: Wählen Sie anhand der folgenden Faktoren ein Datenaufnahmeformat aus:

  • Schema-Support Avro-, ORC-, Parquet- und Firestore-Exporte sind selbstbeschreibende Formate. BigQuery erstellt das Tabellenschema automatisch anhand der Quelldaten. Für JSON- und CSV-Daten können Sie ein explizites Schema angeben oder die automatische Schemaerkennung verwenden.

  • Eindimensionale Daten oder verschachtelte und wiederkehrende Felder Avro, CSV, JSON, ORC und Parquet unterstützen eindimensionale Daten. Avro-, JSON-, ORC-, Parquet- und Firestore-Exporte unterstützen auch Daten mit verschachtelten und wiederkehrenden Feldern. Verschachtelte und wiederholte Daten sind nützlich, um hierarchische Daten auszudrücken. Außerdem wird durch verschachtelte und wiederkehrende Felder die Datenduplizierung beim Laden der Daten reduziert.

  • Eingebettete Zeilenumbrüche Wenn Sie Daten aus JSON-Dateien laden, müssen die Zeilen durch Zeilenumbrüche getrennt sein. BigQuery erwartet durch Zeilenumbruch getrennte JSON-Dateien, die einen einzelnen Datensatz pro Zeile enthalten.

  • Codierung BigQuery unterstützt die UTF-8-Codierung für verschachtelte, wiederkehrende und eindimensionale Daten. Die ISO-8859-1-Codierung wird nur für eindimensionale Daten und nur für CSV-Dateien unterstützt.

Verschachtelte und wiederkehrende Daten laden

Sie können Daten in verschachtelte und wiederkehrende Felder in den folgenden Datenformaten laden:

  • Avro
  • JSON (durch Zeilenumbruch getrennt)
  • ORC
  • Parquet
  • Datastore-Exporte
  • Firestore-Exporte

Informationen darüber, wie Sie beim Laden von Daten verschachtelte und wiederkehrende Felder in Ihrem Schema angeben, finden Sie unter Verschachtelte und wiederkehrende Felder angeben.

Daten aus anderen Google-Diensten laden

Einige Google-Dienste exportieren Daten mithilfe von geplanten Abfragen, Exporten oder Übertragungen nach BigQuery. Weitere Informationen zu Diensten, die Exporte nach BigQuery unterstützen, finden Sie unter Daten aus Google-Diensten laden.

Andere Google-Dienste unterstützen auch Datenexporte, die über BigQuery Data Transfer Service initiiert wurden. Weitere Informationen zu Diensten, die Exporte unterstützen, die vom BigQuery Data Transfer Service initiiert werden, finden Sie unter BigQuery Data Transfer Service.

Kontingent

Informationen zu Kontingenten finden Sie in den folgenden Abschnitten:

Alternativen zum Laden von Daten

In den folgenden Situationen brauchen Sie vor dem Ausführen von Abfragen keine Daten zu laden:

Öffentliche Datasets
Öffentliche Datasets sind in BigQuery gespeicherte Datasets, die für die Öffentlichkeit freigegeben sind. Weitere Informationen finden Sie unter Öffentliche BigQuery-Datasets.
Freigegebene Datasets
Sie können in BigQuery gespeicherte Datasets freigeben. Wenn jemand ein Dataset für Sie freigegeben hat, können Sie dieses Dataset abfragen, ohne die Daten vorher laden zu müssen.
Externe Datenquellen
BigQuery kann Abfragen für bestimmte Formen externer Daten ausführen, ohne die Daten in den BigQuery-Speicher zu laden. Dieser Ansatz bietet die Möglichkeit, die Analysefunktionen von BigQuery zu nutzen, ohne Daten zu verschieben, die an anderer Stelle gespeichert sind. Informationen zu den Vor- und Nachteilen dieses Ansatzes finden Sie unter Externe Datenquellen.
Logdateien
Cloud Logging bietet eine Option zum Exportieren von Logdateien in BigQuery. Weitere Informationen finden Sie unter Senken konfigurieren und verwalten.
.

Nutzung von Ladejobs überwachen

Sie können die Nutzung von Ladejobs auf zwei Arten überwachen:

  • Cloud Monitoring verwenden Weitere Informationen finden Sie unter BigQuery-Messwerte. Insbesondere können Sie die Datenmenge und die Anzahl der Zeilen beobachten, die in eine bestimmte Tabelle hochgeladen werden. Wenn Ihre Ladejobs Daten in eine bestimmte Tabelle hochladen, kann dies ein Proxy zum Überwachen der Nutzungsdaten von Ladejob-Uploads sein.

  • Verwenden Sie INFORMATION_SCHEMA.JOBS_BY_PROJECT. Mit der Ansicht INFORMATION_SCHEMA.JOBS_BY_PROJECT können Sie die Anzahl der Ladejobs pro Tabelle und Tag abrufen.

Anwendungsbeispiel

In den folgenden Beispielen werden die Methoden erläutert, die Sie basierend auf Ihrem Anwendungsfall verwenden müssen und wie Sie sie mit anderen Datenanalyselösungen verwenden können.

Daten mit der Storage Write API streamen

Angenommen, eine Pipeline verarbeitet Ereignisdaten aus Endpunktlogs. Ereignisse werden kontinuierlich generiert und müssen so schnell wie möglich für Abfragen in BigQuery verfügbar sein. Da die Datenaktualität für diesen Anwendungsfall von größter Bedeutung ist, ist die Storage Write API die beste Wahl, um Daten in BigQuery aufzunehmen. Eine empfohlene Architektur, um diese schlanken Endpunkte zu halten, sendet Ereignisse an Pub/Sub, von dem sie von einer Streaming-Dataflow-Pipeline verarbeitet werden, die direkt an BigQuery streamt.

Ein wichtiger Aspekt der Zuverlässigkeit dieser Architektur ist die Handhabung des Fehlschlagens des Einfügens eines Datensatzes in BigQuery. Wenn jeder Datensatz wichtig ist und nicht verloren gehen kann, müssen die Daten vor dem Einfügen zwischengespeichert werden. In der oben empfohlenen Architektur kann Pub/Sub die Rolle eines Zwischenspeichers mit seinen Funktionen zur Nachrichtenaufbewahrung spielen. Die Dataflow-Pipeline sollte so konfiguriert sein, dass BigQuery-Streaming-Insert-Anweisungen mit abgeschnittenem exponentiellem Backoff wiederholt werden. Sobald die Kapazität von Pub/Sub als Zwischenspeicher erschöpft ist, z. B. bei längerer Nichtverfügbarkeit von BigQuery oder einem Netzwerkfehler, müssen die Daten auf dem Client beibehalten werden und der Client benötigt einen Mechanismus zum Fortsetzen des Einfügens beibehaltener Datensätze, sobald die Verfügbarkeit wiederhergestellt ist. Weitere Informationen zum Umgang mit dieser Situation finden Sie im Blogpost Google Pub/Sub Reliability Guide.

Ein weiterer Fehlerfall ist die Verwendung eines Poisoning-Datensatzes. Ein Cache-Eintrag ist entweder ein Eintrag, der von BigQuery abgelehnt wurde, weil der Eintrag nicht mit einem nicht wiederholbaren Fehler eingefügt werden kann oder ein Eintrag, der nach der maximalen Anzahl von Wiederholungsversuchen nicht eingefügt wurde. Beide Datensatztypen sollten von der Dataflow-Pipeline zur weiteren Untersuchung in einer Warteschlange für unzustellbare Nachrichten gespeichert werden.

Wenn eine Genau-einmal-Semantik erforderlich ist, erstellen Sie einen Schreibstream im Commit-Typ mit vom Client bereitgestellten Datensatz-Offsets. Dadurch werden Duplikate vermieden, da der Schreibvorgang nur dann erfolgt, wenn der Versatzwert mit dem nächsten Anfüge-Offset übereinstimmt. Wenn kein Offset angegeben wird, werden Datensätze an das aktuelle Ende des Streams angehängt. Dies kann dazu führen, dass der Datensatz mehrmals im Stream angezeigt wird.

Wenn keine einmaligen Garantien erforderlich sind, ermöglicht das Schreiben in den Standardstream einen höheren Durchsatz und wird auch nicht auf das Kontingentlimit für die Erstellung von Schreibstreams angerechnet.

Schätzen Sie den Durchsatz Ihres Netzwerks ab und prüfen Sie vorab, ob Sie ein ausreichendes Kontingent für die Bereitstellung des Durchsatzes haben.

Werden Ihre Arbeitslast Daten mit einer sehr ungleichmäßigen Rate generiert oder verarbeitet, versuchen Sie, alle Lastspitzen auf dem Client auszugleichen und mit einem konstanten Durchsatz in BigQuery zu streamen. Dies kann die Kapazitätsplanung vereinfachen. Wenn dies nicht möglich ist, müssen Sie auf die Behandlung von 429-Fehlern (Ressource erschöpft) vorbereitet sein, falls Ihr Durchsatz bei kurzen Spitzen das Kontingent überschreitet.

Batchdatenverarbeitung

Angenommen, es gibt eine nächtliche Batchverarbeitungspipeline, die bis zu einer festen Frist abgeschlossen werden muss. Daten müssen innerhalb dieser Frist zur weiteren Verarbeitung durch einen anderen Batchprozess verfügbar sein, um Berichte zu generieren, die an eine Aufsichtsbehörde gesendet werden. Dieser Anwendungsfall ist in regulierten Branchen wie der Finanzbranche üblich.

Für diesen Anwendungsfall ist das Batch-Laden von Daten mit Ladejobs der richtige Ansatz, da die Latenz kein Problem darstellt, wenn die Frist eingehalten werden kann. Achten Sie darauf, dass Ihre Cloud Storage-Buckets die Standortanforderungen zum Laden von Daten in das BigQuery-Dataset erfüllen.

Das Ergebnis eines BigQuery-Ladejobs ist atomar. Entweder werden alle Datensätze eingefügt oder keiner. Als Best Practice sollten Sie beim Einfügen aller Daten in einen einzelnen Ladejob mithilfe der WRITE_TRUNCATE-Disposition der JobConfigurationLoad-Ressource eine neue Tabelle erstellen. Dies ist wichtig, wenn ein fehlgeschlagener Ladejob wiederholt werden soll, da der Client möglicherweise nicht zwischen fehlgeschlagenen Jobs und dem unterscheiden kann, wenn der Fehler beispielsweise bei der Kommunikation des Erfolgsstatus an den Client verursacht wurde.

Wenn Daten, die aufgenommen werden sollen, bereits in Cloud Storage kopiert wurden, reicht der Versuch mit exponentiellem Backoff aus, um Aufnahmefehler zu beheben.

Es wird empfohlen, dass ein nächtlicher Batchjob nicht das Standardkontingent von 1.500 Ladevorgängen pro Tabelle und Tag überschreitet, selbst mit Wiederholungsversuchen. Wenn die Daten inkrementell geladen werden, reicht das Standardkontingent aus, um alle 5 Minuten einen Ladejob auszuführen und dabei noch über genügend unverbrauchte Kontingente für durchschnittlich mindestens 1 Wiederholungsversuch pro Job zu verfügen.

Nächste Schritte