Einführung in das Laden von Daten

Diese Seite bietet eine Übersicht über das Laden von Daten in BigQuery.

Übersicht

Es gibt viele Situationen, in denen Sie Daten abfragen können, ohne sie zu laden. In allen anderen Situationen müssen Sie die Daten vor dem Ausführen von Abfragen in BigQuery laden.

Sie können Daten so laden:

Das Laden von Daten aus Google Drive in BigQuery wird derzeit nicht unterstützt. Sie können aber Daten in Google Drive mithilfe einer externen Tabelle abfragen.

Sie können Daten in eine neue Tabelle oder Partition laden bzw. an eine vorhandene Tabelle oder Partition anfügen. Es ist außerdem möglich, eine Tabelle oder Partition zu überschreiben. Weitere Informationen zum Arbeiten mit Partitionen finden Sie unter Partitionierte Tabellen verwalten.

Beim Laden von Daten in BigQuery können Sie das Tabellen- oder Partitionsschema angeben oder die automatische Schemaerkennung verwenden, wenn es sich um unterstützte Datenformate handelt.

Einschränkungen

Das Laden von Daten in BigQuery unterliegt den folgenden Einschränkungen:

  • Derzeit können Sie Daten nur aus Cloud Storage oder einer lesbaren Datenquelle (z. B. Ihrem lokalen Computer) in BigQuery laden.

Je nach Speicherort und Format Ihrer Quelldaten sind weitere Einschränkungen möglich. Weitere Informationen:

Unterstützte Datenformate

BigQuery unterstützt das Laden von Daten aus Cloud Storage und lesbaren Datenquellen in den folgenden Formaten:

Das Standardquellformat für das Laden von Daten ist CSV. Wenn Sie Daten laden möchten, die in einem der anderen unterstützten Datenformate gespeichert sind, geben Sie das Format explizit an. Beim Laden von Daten in BigQuery werden die Daten in ein Spaltenformat für Capacitor (BigQuery-Speicherformat) konvertiert.

Datenaufnahmeformat auswählen

Sie können Daten in einer Vielzahl von Formaten in BigQuery laden. Beim Laden von Daten in BigQuery werden die Daten in ein Spaltenformat für Capacitor (BigQuery-Speicherformat) konvertiert.

Wählen Sie beim Laden von Daten ein Datenaufnahmeformat basierend auf den folgenden Faktoren aus:

  • Ihr Datenschema

    Avro, CSV, JSON, ORC und Parquet unterstützen eindimensionale Daten. Avro-, JSON-, ORC-, Parquet-, Datastore- und Firestore-Exporte unterstützen auch Daten mit verschachtelten und wiederkehrenden Feldern. Verschachtelte und wiederkehrende Daten sind nützlich, um die hierarchische Anordnung von Daten auszudrücken. Verschachtelte und wiederkehrende Felder reduzieren bei der Datendenormalisierung außerdem die Duplizierung.

  • Eingebettete Zeilenumbrüche

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

  • Externe Einschränkungen

    Ihre Daten stammen möglicherweise aus einer Dokumentenablagedatenbank, in der Daten im JSON-Format gespeichert werden. Ihre Daten können auch aus einer Quelle stammen, die ausschließlich in das CSV-Format exportiert.

Codierte Daten laden

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

Zeichencodierungen

Standardmäßig erwartet der BigQuery-Dienst alle Quelldaten in UTF-8-Codierung. Wenn Sie wahlweise CSV-Dateien mit codierten Daten im ISO-8859-1-Format vorliegen haben, müssen Sie die Codierung ausdrücklich beim Importieren der Daten angeben. Dies ist erforderlich, damit BigQuery die Daten während des Importvorgangs ordnungsgemäß in UTF-8 konvertieren kann. Derzeit können nur ISO-8859-1- oder UTF-8-codierte Daten importiert werden. Beachten Sie die folgenden Aspekte, wenn Sie die Zeichencodierung der Daten angeben.

  • Wenn Sie keine Codierung angeben oder ausdrücklich angeben, dass die Daten in UTF-8-Codierung vorliegen, dann aber eine nicht UTF-8-codierte CSV-Datei bereitstellen, nimmt BigQuery eine Konvertierung der CSV-Datei in UTF-8 vor.

    In der Regel werden die Daten erfolgreich importiert, stimmen aber möglicherweise nicht Byte für Byte mit dem erwarteten Ergebnis überein. Geben Sie die richtige Codierung an und versuchen Sie einen erneuten Import, um diese Situation zu vermeiden.

  • Trennzeichen müssen ISO-8859-1-codiert sein.

    Als bewährte Praxis empfiehlt sich die Verwendung von Standardtrennzeichen, wie z. B. Tab, senkrechter Strich oder Komma.

  • Wenn BigQuery ein Zeichen nicht konvertieren kann, wird es in das standardmäßige Unicode-Ersetzungszeichen konvertiert: �.
  • JSON-Dateien müssen immer UTF-8-codiert sein.

Wenn Sie ISO-8859-1-codierte, eindimensionale Daten mit der API laden möchten, geben Sie das Attribut encoding in der Ladejobkonfiguration (load) an.

Komprimierte und unkomprimierte Daten laden

Das Avro-Binärformat ist das bevorzugte Format zum Laden komprimierter und unkomprimierter Daten. Avro-Daten können schneller geladen werden, da die Daten parallel gelesen werden können, selbst wenn die Datenblöcke komprimiert sind. Komprimierte Avro-Dateien werden nicht unterstützt, komprimierte Datenblöcke hingegen schon. BigQuery unterstützt die Codecs DEFLATE und Snappy für komprimierte Datenblöcke in Avro-Dateien.

Das binäre Parquet-Format ist auch eine gute Wahl, da die effiziente Spaltencodierung von Parquet in der Regel zu einer besseren Komprimierungsrate und kleineren Dateien führt. Parquet-Dateien nutzen auch Komprimierungstechniken, mit denen Dateien parallel geladen werden können. Komprimierte Parquet-Dateien werden nicht unterstützt, komprimierte Datenblöcke hingegen schon. Die Codecs Snappy, GZip und LZO_1X werden von BigQuery für komprimierte Datenblöcke in Parquet-Dateien unterstützt.

Das ORC-Binärformat bietet ähnliche Vorteile wie das Parquet-Format. Daten in ORC-Dateien können durch das parallele Lesen von Datenstreifen schnell geladen werden. Die in jedem Datenstreifen enthaltenen Zeilen werden nacheinander geladen. Verwenden Sie zum Optimieren der Ladezeit Datenstreifen mit maximal rund 256 MB. Komprimierte ORC-Dateien werden nicht unterstützt, komprimierte Dateifußzeilen und Datenstreifen hingegen schon. BigQuery unterstützt Zlib-, Snappy-, LZO- und LZ4-Komprimierung für Fußzeilen und Datenstreifen in ORC-Dateien.

Bei anderen Datenformaten wie CSV und JSON kann BigQuery unkomprimierte Dateien aufgrund der parallelen Lesevorgänge wesentlich schneller laden als komprimierte Dateien. Da unkomprimierte Dateien größer sind, kann ihre Verwendung zu Bandbreitenbeschränkungen und höheren Kosten für Daten führen, die in Cloud Storage bereitgestellt sind, bevor sie in BigQuery geladen werden. Beachten Sie außerdem, dass die Zeilenreihenfolge bei komprimierten und unkomprimierten Dateien nicht sichergestellt ist. Je nach Anwendungsfall müssen Sie die Vor- und Nachteile unbedingt abwägen.

Allgemein gilt: Wenn die Bandbreite begrenzt ist, sollten Sie Ihre CSV- und JSON-Dateien mit gzip komprimieren, bevor Sie sie in Cloud Storage hochladen. Beim Laden von Daten in BigQuery ist gzip derzeit der einzige unterstützte Komprimierungstyp für CSV- und JSON-Dateien. Wenn die Ladegeschwindigkeit für Ihre Anwendung wichtig ist und Sie viel Bandbreite zum Laden Ihrer Daten haben, lassen Sie die Dateien unkomprimiert.

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.

BigQuery funktioniert am besten mit denormalisierten Daten. Zur Verbesserung der Leistung können Sie die Daten denormalisieren. Sie können auch verschachtelte und wiederkehrende Felder verwenden, anstatt an relationalen Schemas etwa in Form eines Sterns oder einer Schneeflocke festzuhalten. Die Beziehungen zwischen verschachtelten und wiederkehrenden Feldern können aufrechterhalten werden, ohne die Leistung wie bei relationalen bzw. normalisierten Schemas zu beeinträchtigen.

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.

Automatische Schemaerkennung

Die automatische Schemaerkennung ist für das Laden von Daten in BigQuery und für das Abfragen einer externen Datenquelle verfügbar.

Wenn die automatische Erkennung aktiviert ist, startet BigQuery den Ableitungsvorgang. Zu diesem Zweck wird eine zufällige Datei in der Datenquelle ausgewählt und es werden bis zu 100 Datenzeilen als repräsentative Stichprobe durchsucht. BigQuery überprüft dann jedes Feld und versucht, diesem Feld basierend auf den Werten in dieser Stichprobe einen Datentyp zuzuweisen.

Beim Laden von JSON- oder CSV-Dateien können Sie die automatische Schemaerkennung verwenden. Die automatische Schemaerkennung ist für Avro-, ORC- und Parquet-Dateien sowie für Datastore- oder Firestore-Exporte nicht verfügbar, da die Schemainformationen für diese Formate selbstbeschreibend sind.

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 Übertragungen von Drittanbietern (Beta) 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 zum Laden von Daten aus einer Google Analytics 360-Berichtsdatenansicht in BigQuery finden Sie in der Google Analytics-Hilfe unter BigQuery-Export.

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

Cloud Storage

BigQuery unterstützt das Laden von Daten aus Cloud Storage. Weitere Informationen finden Sie unter Daten aus Cloud Storage laden.

Datastore

BigQuery unterstützt das Laden von Daten aus Datastore-Exporten. Weitere Informationen finden Sie unter Daten aus Datastore-Exporten laden.

Firestore

BigQuery unterstützt das Laden von Daten aus Firestore-Exporten. Weitere Informationen finden Sie unter Daten aus Firestore-Exporten laden.

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.

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
Sie können das Laden der Daten vermeiden, indem Sie eine auf einer externen Datenquelle basierende Tabelle erstellen. Informationen zu den Vor- und Nachteilen dieses Ansatzes finden Sie unter Externe Datenquellen.
Logdateien
Stackdriver Logging bietet eine Option zum Exportieren von Logdateien in BigQuery. Weitere Informationen finden Sie unter Export über die Loganzeige.

Eine weitere Alternative zum Laden von Daten ist das Streamen einzelner Datensätze. Streaming wird normalerweise verwendet, wenn die Daten sofort verfügbar sein müssen. Informationen zum Streaming finden Sie unter Daten in BigQuery streamen.

Kontingentrichtlinie

Informationen zu den Kontingentrichtlinien für das Laden von Daten finden Sie auf der Seite "Kontingente und Limits" unter Ladejobs.

Preise

Das Laden von Daten in BigQuery ist derzeit kostenlos. Weitere Informationen finden Sie in der Preisübersicht.

Weitere Informationen