Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Einführung in das Laden von Daten

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

Überblick

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.

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

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 Daten aus externen Quellen beispielsweise 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.

  • 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 Duplizierung bei der Datendenormalisierung 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.

Denormalisierte, verschachtelte und wiederkehrende Daten laden

Viele Entwickler sind an die Arbeit mit relationalen Datenbanken und normalisierten Datenschemas gewöhnt. Bei der Normalisierung werden keine doppelten Daten gespeichert. Bei regelmäßiger Aktualisierung der Daten sorgt sie außerdem für Konsistenz.

Die Denormalisierung ist eine gängige Strategie zur Steigerung der Leseleistung bei relationalen Datasets, die zuvor normalisiert wurden. Die empfohlene Methode zur Denormalisierung von Daten in BigQuery ist die Verwendung verschachtelter und wiederkehrender Felder. Diese Strategie eignet sich am besten, wenn die Beziehungen hierarchisch sind und häufig zusammen abgefragt werden, beispielsweise in Beziehungen zwischen über- und untergeordneten Elementen.

Die Speicherplatzeinsparungen, die durch die Verwendung normalisierter Daten erzielt werden, sind in modernen Systemen nebensächlich. Die zusätzlichen Speicherkosten werden durch die Leistungssteigerungen, die durch Verwendung denormalisierter Daten erzielt werden, amortisiert. Joins erfordern eine Datenkoordinierung und damit Kommunikationsbandbreite. Durch die Denormalisierung werden die Daten in individuellen Slots platziert, was eine parallele Ausführung ermöglicht.

Um bei der Denormalisierung Ihrer Daten Beziehungen aufrechtzuerhalten, können Sie verschachtelte oder wiederkehrende Felder verwenden, anstatt Ihre Daten zu vereinfachen. Wenn Sie relationale Daten vollständig zusammenfassen, kann die nach dem Zufallsprinzip erfolgende Netzwerkkommunikation die Abfrageleistung beeinträchtigen.

Nehmen wir an, Sie denormalisieren ein Auftragsschema, ohne verschachtelte und wiederkehrende Felder zu verwenden. In diesem Fall ist möglicherweise eine Gruppierung nach einem Feld wie order_id erforderlich – wenn eine 1:n-Beziehung vorliegt. Aufgrund der involvierten Netzwerkkommunikation nach dem Zufallsprinzip ist das Gruppieren der Daten weniger effektiv als deren Denormalisierung mit verschachtelten und wiederkehrenden Feldern.

Unter bestimmten Umständen führt die Denormalisierung Ihrer Daten und die Verwendung verschachtelter und wiederkehrender Felder nicht zu einer Leistungsverbesserung. Denormalisieren Sie die Daten in den folgenden Fällen nicht:

  • Sie haben ein Sternschema, dessen Größe sich regelmäßig ändert.
  • BigQuery ergänzt ein System zur Online-Transaktionsverarbeitung (OLTP) durch die Mutation auf Zeilenebene, kann es jedoch nicht ersetzen.

Verschachtelte und wiederkehrende Felder werden in den folgenden Datenformaten unterstützt:

  • 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

BigQuery Data Transfer Service

BigQuery Data Transfer Service automatisiert das Laden von Daten in BigQuery aus den folgenden Diensten:

SaaS-Anwendungen (Software as a Service) von Google Externe Cloud Storage-Anbieter: Data Warehouses: Darüber hinaus stehen im Google Cloud Marketplace mehrere Drittanbieter-Übertragungen zur Verfügung.

Nachdem Sie eine Datenübertragung konfiguriert haben, werden wiederkehrende Ladevorgänge aus der Quellanwendung in BigQuery automatisch von BigQuery Data Transfer Service geplant und verwaltet.

Google Analytics 360

Eine Anleitung zum Exportieren einer Sitzung und von Trefferdaten aus einer Google Analytics 360-Berichtsdatenansicht in BigQuery finden Sie in der Analytics-Hilfe unter BigQuery-Export.

Beispiele für die Abfrage von Analytics-Daten in BigQuery finden Sie in der Analytics-Hilfe im Cookbook zu BigQuery.

Dataflow

Mit Dataflow können Daten direkt in BigQuery geladen werden. Weitere Informationen dazu, wie Sie Dataflow zum Lesen und Schreiben in BigQuery verwenden, finden Sie in der Apache Beam-Dokumentation unter Google BigQuery I/O-Connector.

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.

Pub/Sub

Pub/Sub ist ein Messaging-Dienst, der für Streaminganalysen und Datenintegrationspipelines verwendet werden kann. Sie können BigQuery-Abos verwenden, um Nachrichten direkt in eine vorhandene BigQuery-Tabelle zu schreiben.

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

Nächste Schritte