Übersicht über Schema- und Datenübertragung

In diesem Dokument werden die Konzepte und Aufgaben für die Übertragung des Schemas und der Daten von Ihrem bestehenden Data Warehouse zu BigQuery behandelt.

Die Migration Ihres Data Warehouse in die Cloud ist ein komplexer Prozess, der Planung, Ressourcen und Zeit erfordert. Um diese Komplexität in den Griff zu bekommen, sollten Sie die Data Warehouse-Migration schrittweise und iterativ ausführen. Wenn Sie mehrere Iterationen der Schema- und Datenmigration ausführen, kann das Ergebnis verbessert werden.

Schema- und Datenmigrationsprozess

Am Anfang Ihrer Migration stehen vorgelagerte Systeme, die Ihr altes Data Warehouse mit Daten versorgen, und nachgelagerte Systeme, die diese Daten in Berichten, Dashboards und als Feeds für andere Prozesse verwenden.

Dieser allgemeine Datenfluss unterstützt zahlreiche Analytics-Anwendungsfälle, wie in der folgenden Abbildung dargestellt:

Ausgangszustand vor der Migration:

Am Ende der Migration werden so viele Anwendungsfälle wie möglich auf BigQuery laufen. Wenn Sie diesen Stand erreicht haben, können Sie die Nutzung Ihres alten Data Warehouse minimieren und es schließlich auslaufen lassen. Sie steuern, welche Anwendungsfälle wann migriert werden, indem Sie sie während der Vorbereitungs- und Ermittlungsphase der Migration priorisieren.

Daten und Schemas von lokalen Umgebungen zu BigQuery übertragen

In der Beurteilungs- und Planungsphase der Migration bestimmen Sie die Anwendungsfälle, die Sie migrieren möchten. In der anschließenden Ausführungsphase starten Sie die Migrationsiterationen. So verwalten Sie Ihre Iterationen bei minimalen Unterbrechungen Ihrer Analyseumgebung:

  1. Tabellen übertragen und konfigurieren und nachgelagerte Prozesse testen.

    • Übertragen Sie mit dem BigQuery Data Transfer Service oder einem anderen ETL-Tool die Tabellengruppe für jeden Anwendungsfall ohne Änderungen an BigQuery. Weitere Informationen zu Tools finden Sie im Abschnitt zur ersten Datenübertragung.
    • Konfigurieren Sie Testversionen Ihrer nachgelagerten Prozesse zum Abrufen aus den BigQuery-Tabellen.

    Dieser erste Schritt unterteilt den Datenfluss. Das folgende Diagramm zeigt den resultierenden Fluss. Einige nachgelagerte Systeme lesen jetzt aus BigQuery, wie in den mit B gekennzeichneten Abläufen gezeigt. Andere Nutzer lesen weiterhin aus dem Legacy-Data Warehouse, wie in den mit A gekennzeichneten Abläufen dargestellt.

    Vorgelagerte Prozesse speisen das Legacy-Data Warehouse. Einige Daten fließen in nachgelagerte Prozesse ein, andere wiederum werden mit dem BigQuery Data Transfer Service an BigQuery und von dort aus an verschiedene nachgelagerte Prozesse weitergeleitet.

  2. Konfigurieren Sie einige vorgelagerte Prozesse als Test, um Daten anstatt (oder zusätzlich zu) der alten Datenbank in BigQuery-Tabellen zu schreiben.

    Konfigurieren Sie nach dem Test Ihre vorgelagerten und nachgelagerten Produktionsprozesse zum Schreiben in und Abrufen aus den BigQuery-Tabellen. Diese Prozesse können über die BigQuery API mit BigQuery verknüpft werden und neue Cloud-Produkte wie Google Data Studio und Dataflow einbinden.

    Zu dieser Stelle haben Sie drei Datenflüsse:

    1. Legacy. Die Daten und Prozesse bleiben unverändert und laufen weiterhin über Ihr altes Data Warehouse.
    2. Übertragen. Die vorgelagerten Prozesse speisen Ihr altes Data Warehouse, die Daten werden in BigQuery übertragen und speisen von dort aus nachgelagerte Prozesse.
    3. Vollständig migriert. Die vor- und nachgelagerten Prozesse schreiben oder lesen nicht mehr in das oder aus dem alten Data Warehouse.

      Das folgende Diagramm zeigt ein System mit allen drei Flüssen:

      Fluss von Arbeitslasten über mehrere Pfade.
  3. Wählen Sie weitere Anwendungsfälle für die Migration aus und gehen Sie zurück zu Schritt 1, um eine neue Ausführungsiteration zu starten. Wiederholen Sie diese Schritte, bis alle Ihre Anwendungsfälle vollständig zu BigQuery migriert sind. Bei der Auswahl von Anwendungsfällen können Sie diejenigen Fälle noch einmal bearbeiten, die sich noch im übertragenen Zustand befinden, um sie vollständig zu migrieren. Erwägen Sie, für vollständig migrierte Anwendungsfälle den Entwicklungsprozess fortzusetzen. Folgen Sie dazu den Richtlinien unter Schema in BigQuery entwickeln.

    Letzter Schritt migrierter Anwendungsfälle.

Schema in BigQuery entwickeln

Das Data-Warehouse-Schema definiert die Struktur Ihrer Daten und die Beziehungen zwischen Ihren Dateneinheiten. Das Schema ist der Kern Ihres Daten-Designs und wirkt sich auf viele vor- und nachgelagerte Prozesse aus.

Eine Data Warehouse-Migration bietet Ihnen die einmalige Chance, Ihr Schema nach dem Verschieben nach BigQuery weiter zu entwickeln. Dieser Abschnitt enthält Richtlinien zum Entwickeln Ihres Schemas anhand einer Reihe von Schritten. Mit diesen Richtlinien halten Sie Ihre Data Warehouse-Umgebung während Schemaänderungen mit minimalen Störungen der vor- und nachgelagerten Prozesse am Laufen.

In diesem Abschnitt geht es um die Schritte zur Schemaumwandlung für einen einzelnen Anwendungsfall.

Je nachdem, wie weit Sie mit der Entwicklung gehen möchten, können Sie bei einem Zwischenschritt aufhören oder fortfahren, bis Ihr System vollständig entwickelt ist.

  1. Unveränderte Übertragung eines Anwendungsfalles an BigQuery.

    Bevor Sie mit den nächsten Schritten fortfahren, sorgen Sie dafür, dass die vor- und nachgelagerten Prozesse Ihres Anwendungsfalls bereits in bzw. aus BigQuery schreiben und abrufen. Es ist jedoch auch möglich, von einem Zwischenstand aus zu beginnen, in dem nur der nachgelagerte Prozess aus BigQuery abruft. Wenden Sie in diesem Fall nur die Richtlinien für den nachgelagerten Teil an. Das folgende Diagramm zeigt einen Anwendungsfall, bei dem vor- und nachgelagerte Prozesse in BigQuery in Tabellen schreiben und daraus abrufen.

    Vorgelagerte Prozesse speisen BigQuery-Tabellen und von dort aus nachgelagerte Prozesse.

  2. Leichte Optimierungen anwenden

    1. Wiederherstellung Ihrer Tabellen durch Partitionierung und Clustering. Für diese Aufgabe können Sie die Methode zum Erstellen einer Tabelle aus einem Abfrageergebnis nutzen. Weitere Informationen finden Sie in der Diskussion und im Beispiel für partitionierte Tabellen sowie in der Diskussion und im Beispiel für Clustertabellen.
    2. Umleiten Ihrer vor- und nachgelagerten Prozesse auf die neuen Tabellen.
  3. Fassadenansichten erstellen.

    Erstellen Sie Fassadenansichten für Ihre Tabellen, Wenn Sie Ihr Schema über leichte Optimierungen hinaus weiter entwickeln möchten. Das Fassadenmuster ist eine Gestaltungsmethode, die zur besseren Übersichtlichkeit den zugrunde liegenden Code oder die zugrunde liegenden Strukturen verbirgt. Dabei maskieren die Fassadenansichten die zugrunde liegenden Tabellen, um die durch Tabellenänderungen aus nachgelagerten Prozessen verursachte Komplexität zu verbergen.

    Die Ansichten können ein neues Schema darstellen, das frei von technischen Altlasten auf neue Aufnahme- und Verbrauchsszenarien hin modelliert wurde.

    Die Tabellen und die Definition der Ansichtsabfrage selbst können sich im Hintergrund ändern. Die Ansichten davon abstrahieren jedoch diese Änderungen als internes Umsetzungsdetail Ihres Data Warehouse. Es werden immer dieselben Ergebnisse geliefert. Diese aus Fassadenansichten bestehende Abstraktionsschicht isoliert Ihre vor- und nachgelagerten Systeme so lange wie nötig von Änderungen. Die Änderungen werden nur angezeigt, wenn es sinnvoll ist.

  4. Nachgelagerte Prozesse umwandeln.

    Sie können einige Ihrer nachgelagerten Prozesse so umwandeln, dass sie anstatt aus den tatsächlichen Tabellen aus den Fassadenansichten abgerufen werden. Diese Prozesse profitieren bereits von dem weiterentwickelten Schema. Für diese Prozesse ist es transparent, dass die Fassadenansichten im Hintergrund weiterhin ihre Daten aus dem Legacy-BigQuery-Schema beziehen, wie in der folgenden Abbildung dargestellt:

    Vorgelagerte Prozesse speisen BigQuery-Tabellen. Einige davon speisen nachgelagerte Prozesse. Andere wiederum speisen Fassadenansichten, die ihrerseits ausgereifte nachgelagerte Prozesse speisen.

    Wir haben zuerst die nachgelagerte Prozessumwandlung beschrieben. So können Sie den geschäftlichen Nutzen der Migration schneller demonstrieren, etwa in Form migrierter Dashboards oder von Berichten, als wenn Sie erst vorgelagerte Prozesse umwandeln, die für nichttechnische Stakeholder nicht sichtbar sind. Es ist jedoch auch möglich, die Umwandlung stattdessen mit vorgelagerten Prozessen zu beginnen. Wie Sie diese Aufgaben priorisieren, hängt ganz von Ihren Bedürfnissen ab.

  5. Vorgelagerte Prozesse umwandeln.

    Sie können einige Ihrer vorgelagerten Prozesse so umwandeln, dass sie in das neue Schema schreiben. Da Ansichten schreibgeschützt sind, erstellen Sie Tabellen basierend auf dem neuen Schema und ändern dann die Abfragedefinition der Fassadenansichten. Einige Ansichten fragen weiterhin das Legacy-Schema ab, während andere die neu erstellten Tabellen abfragen oder einen SQL-UNION-Vorgang für beide ausführen, wie in der folgenden Abbildung dargestellt:

    Vorgelagerte Prozesse speisen BigQuery-Tabellen, jedoch nicht mehr nachgelagerte Prozesse. Stattdessen speisen die BigQuery-Tabellen Fassadenansichten, die wiederum ausgereifte nachgelagerte Prozesse speisen.

    An dieser Stelle können Sie beim Erstellen der neuen Tabellen die Vorteile verschachtelter und wiederkehrender Felder nutzen. So können Sie Ihr Modell weiter denormalisieren und direkt die BigQuery zugrunde liegende spaltenweise Darstellung von Daten nutzen.

    Ein Vorteil von Fassadenansichten besteht darin, dass die Umwandlung Ihrer nachgelagerten Prozesse unabhängig von den zugrunde liegenden Schemaänderungen sowie von Änderungen an den vorgelagerten Prozessen fortgesetzt werden kann.

  6. Vollständige Weiterentwicklung Ihres Anwendungsfalls.

    Zuletzt können Sie die verbleibenden vor- und nachgelagerten Prozesse umwandeln. Wenn alle diese Funktionen so weit entwickelt wurden, dass sie in die neuen Tabellen schreiben und aus den neuen Fassadenansichten abrufen, ändern Sie die Abfragedefinitionen der Fassadenansichten so, dass sie nicht mehr aus dem alten Schema abgerufen werden. Anschließend können Sie die Tabellen im alten Modell aus dem Datenfluss entfernen. Das folgende Diagramm zeigt den Zustand, wenn keine Legacy-Tabellen mehr verwendet werden.

    Die ursprünglichen vorgelagerten Prozesse werden nicht mehr verwendet. Es verbleiben ausschließlich ausgereifte vorgelagerte Prozesse, die ausgereifte Tabellen speisen. Diese wiederum speisen Fassadenansichten, die schließlich alle nachgelagerten Prozesse speisen.

    Wenn in den Fassadenansichten keine aggregierten Felder oder Filterspalten vorkommen, können Sie die nachgelagerten Prozesse so konfigurieren, dass sie aus den entwickelten Tabellen abgerufen werden. Anschließend können Sie die Fassadenansichten entfernen, um den Prozess zu vereinfachen, wie in der folgenden Abbildung dargestellt:

    In der endgültigen Konfiguration speisen sowohl BigQuery-Tabellen als auch ausgereifte Tabellen Fassadenansichten, die einzigen Quellen für nachgelagerte Prozesse.

Führen Sie eine erste Übertragung Ihres Schemas und Ihrer Daten durch

In diesem Abschnitt werden praktische Überlegungen zur Migration Ihres Schemas und Ihrer Daten von einem Legacy-Data-Warehouse zu BigQuery erläutert.

Wir empfehlen, das Schema während der ersten Iterationen der Migration ohne Änderungen zu übertragen. Dies bietet folgende Vorteile:

  • Die Datenpipelines, die Ihr Data Warehouse speisen, müssen nicht für ein neues Schema angepasst werden.
  • Sie müssen Ihre Mitarbeiter nicht auch noch in einem neuen Schema schulen.
  • Sie können das Schema und die Daten mit automatisierten Tools übertragen.

Darüber hinaus lassen sich Proofs of Concept (PoCs) und andere Datenexplorationsaktivitäten mit Cloud-Funktionen ungehindert ausführen, selbst wenn Ihre Migration parallel erfolgt.

Übertragungsmethode auswählen

Die erste Datenübertragung können Sie auf verschiedene Weise ausführen.

  • Für Amazon Redshift, Oracle und Teradata Data Warehouses können Sie BigQuery Data Transfer Service verwenden, um Schemas und Daten direkt aus Ihrem vorhandenen System in BigQuery zu laden. Cloud Storage wird weiterhin im Rahmen des Migrationsprozesses zum Staging von Daten verwendet.
  • Für jedes Data Warehouse können Sie Dateien, die Ihr Schema und Ihre Daten enthalten, extrahieren, diese Dateien in Cloud Storage hochladen und dann eine der folgenden Optionen verwenden, um das Schema und die Daten aus diesen Dateien in BigQuery:

Weitere Überlegungen zur Auswahl einer Datenübertragungsmethode finden Sie unter Methode zur Datenaufnahme auswählen.

Datentransformation in Betracht ziehen

Abhängig von Ihrem Datenextraktformat und davon, ob Sie Ihre Daten kürzen oder anreichern möchten, bevor Sie sie in BigQuery laden, kann ein Datenumwandlungsschritt erforderlich sein. Der Transformationsschritt kann entweder lokal oder in Google Cloud ausgeführt werden:

  • Wenn der Umwandlungsschritt lokal ausgeführt wird, sollten Sie berücksichtigen, inwiefern die verfügbare Rechenkapazität und die verfügbaren Tools den Durchsatz beeinträchtigen könnten. Wenn beim Umwandlungsprozess Daten angereichert werden, sollten Sie außerdem auch zusätzlich notwendige Übertragungszeiten oder Netzwerkbandbreite berücksichtigen.
  • Wenn der Transformationsschritt in Google Cloud ausgeführt wird, finden Sie unter Daten mit einem ETL-Tool laden weitere Informationen zu Ihren Optionen.

Quellschema und Daten in Dateien extrahieren

Ihre Quellplattform bietet wahrscheinlich ein Tool zum Exportieren von Daten in ein herstellerunabhängiges Format wie Apache AVRO oder CSV. Damit die Übertragung weniger komplex ist, empfehlen wir Ihnen, AVRO ORC oder Parquet zu verwenden, bei dem Schemainformationen in die Daten eingebettet sind. Wenn Sie CSV oder ein ähnliches einfaches, getrenntes Datenformat auswählen, müssen Sie das Schema separat angeben. Die Vorgehensweise hängt von der ausgewählten Datenübertragungsmethode ab. Beispielsweise können Sie für den Batch-Upload entweder ein Schema beim Laden angeben oder die automatische Erkennung des Schemas basierend auf dem Inhalt der CSV-Datei zulassen.

Kopieren Sie sie in den Staging-Speicher in Ihrer lokalen Umgebung, wenn Sie diese Dateien aus Ihrer Quellplattform extrahieren.

Dateien in Cloud Storage hochladen

Sofern Sie BigQuery Data Transfer Service nicht direkt zum Laden von Daten aus einem vorhandenen Amazon Redshift, Oracle oder Teradata verwenden, müssen Sie die extrahierten Dateien in einen Bucket in Cloud Storage hochladen. Je nach der übertragenen Datenmenge und verfügbaren Netzwerkbandbreite können Sie aus den folgenden Übertragungsoptionen auswählen:

  • Wenn sich Ihre extrahierten Daten bei einem anderen Cloud-Anbieter befinden, verwenden Sie den Storage Transfer Service.
  • Wenn sich die Daten in einer lokalen Umgebung oder in einer Colocations-Einrichtung mit guter Netzwerkbandbreite befinden, verwenden Sie das Tool gsutil. Das gsutil-Tool unterstützt parallele Uploads mit mehreren Threads, wird nach Fehlern fortgesetzt und verschlüsselt aus Sicherheitsgründen den Traffic während der Übertragung.

  • Wenn Sie keine ausreichende Netzwerkbandbreite erreichen können, können Sie mit einer Transfer Appliance eine Offline-Übertragung ausführen.

Wenn Sie den Cloud Storage-Bucket erstellen und Daten über das Netzwerk übertragen, minimieren Sie die Netzwerklatenz durch Wahl eines Standorts, der Ihrem Rechenzentrum am nächsten liegt. Wenn möglich, wählen Sie den Standort des Buckets so, dass er dem Standort des BigQuery-Datensatzes entspricht.

Ausführliche Informationen zu Best Practices für das Verschieben von Daten in Cloud Storage, einschließlich einer Kosteneinschätzung, finden Sie unter Strategien für die Übertragung großer Datenmengen.

Schema und Daten in BigQuery laden

Laden Sie das Schema und die Daten mit einer der unter Übertragungsmethode auswählen beschriebenen Optionen in BigQuery.

Weitere Informationen zum einmaligen Laden finden Sie unter Einführung in das Laden von Daten aus Cloud Storage in der Dokumentation zu BigQuery. Weitere Informationen zu regelmäßig geplanten Ladevorgängen finden Sie in der Übersicht über Cloud Storage-Übertragungen in der Dokumentation zum BigQuery Data Transfer Service.

Daten mit einem ETL-Tool laden

Verwenden Sie eine der folgenden Optionen, wenn Ihre Daten beim Laden in BigQuery weiter transformiert werden müssen.

  • Cloud Data Fusion. Dieses Tool erstellt grafisch vollständig verwaltete ETL/ELT-Datenpipelines mit einer Open-Source-Bibliothek mit vorkonfigurierten Connectors und Umwandlungen.
  • Dataflow. Dieses Tool definiert und bewältigt komplexe Datenumwandlungen und Anreicherungsgrafiken mit dem Apache Beam-Modell. Dataflow ist serverlos und wird vollständig von Google verwaltet, sodass Sie auf praktisch unbegrenzte Verarbeitungskapazitäten zugreifen können.
  • Dataproc. führt Apache Spark- und Apache Hadoop-Cluster auf einem vollständig verwalteten Cloud-Dienst aus.
  • Drittanbieter-Tools. Wenden Sie sich an einen unserer Partner. Sie bieten Ihnen gute Optionen, wenn Sie die Erstellung einer Datenpipeline auslagern möchten.

Das folgende Diagramm zeigt das in diesem Abschnitt beschriebene Muster. Das Datenübertragungstool ist gsutil. Es enthält einen Umwandlungsschritt, bei dem unter Nutzung von Cloud Dataflow direkt in BigQuery geschrieben wird. Hier kann auch der in Apache Beam eingebundene Google BigQuery-E/A-Connector verwendet werden.

Das Legacy-Data Warehouse kopiert die Daten lokal in den temporären Speicher. Das gsutil-Tool kopiert die Daten in einen Cloud Storage-Bucket. Dataflow liest den Staging-Bucket aus und verschiebt die Daten in BigQuery.

Nachdem Sie einen ersten Satz Ihrer Daten in BigQuery geladen haben, können Sie die leistungsstarken Funktionen von BigQuery nutzen.

Wie beim Übertragen Ihres Schemas ist das Hochladen Ihrer Daten jedoch Teil eines iterativen Prozesses. Nachfolgende Iterationen können damit beginnen, dass das Volumen der an BigQuery übertragenen Daten vergrößert wird. Und sie können dann Ihre vorgelagerten Datenfeeds umleiten, damit Sie Ihren älteren Datenspeicher nicht mehr behalten müssen. Diese Themen werden im nächsten Abschnitt behandelt.

Daten validieren

Nachdem sich Ihre Daten nun in BigQuery befinden, können Sie den Erfolg der Datenübertragung mit dem Data Validation Tool (DVT) prüfen. DVT ist ein Python-Befehlszeilentool im Open-Source-Format, mit dem Sie Daten aus verschiedenen Quellen mit dem Ziel in BigQuery vergleichen können. Sie können angeben, welche Aggregationen (z. B. Anzahl, Summe, Mittelwert) Sie ausführen und auf welche Spalten anwenden möchten. Weitere Informationen finden Sie unter Datenvalidierung mit DVT automatisieren.

Erste Übertragung iterieren

In diesem Abschnitt erfahren Sie, wie Sie nach der ersten Datenübertragung BigQuery optimal nutzen.

Eine Teilmenge Ihrer Daten befindet sich jetzt in BigQuery. Sie bereiten sich nun darauf vor, das Volumen der in BigQuery verwendeten Daten zu erweitern, um die Abhängigkeit von Ihrem Legacy-Data Warehouse zu verringern.

Welche Methode Sie für nachfolgende Iterationen auswählen, hängt davon ab, wie wichtig es für Ihren Anwendungsfall ist, die Daten bis auf die Sekunde aktuell zu halten. Wenn Ihre Datenanalysten mit Daten arbeiten können, die in regelmäßigen Abständen in das Data Warehouse aufgenommen werden, ist eine geplante Option der richtige Weg. Sie können geplante Übertragungen ähnlich wie die ursprüngliche Übertragung erstellen. Sie nutzen den BigQuery Data Transfer Service, andere ETL-Tools wie Storage Transfer Service von Google oder Implementierungen von Drittanbietern.

Wenn Sie den BigQuery Data Transfer Service verwenden, müssen Sie zuerst entscheiden, welche Tabellen verschoben werden sollen. Anschließend erstellen Sie ein Tabellennamenmuster, um diese Tabellen aufzunehmen. Zuletzt legen Sie einen regelmäßigen Zeitplan für die Ausführung der Übertragung fest.

Wenn Ihr Anwendungsfall allerdings einen nahezu unmittelbaren Zugriff auf neue Daten erfordert, benötigen Sie einen Streaming-Ansatz. Es stehen zwei Optionen zur Verfügung:

  • Richten Sie mit Google Cloud-Produkten eine Ladepipeline ein. Zur Erleichterung dieser Aufgabe bietet Google eine Reihe von Streaming-Dataflow-Vorlagen an.
  • Nutzen Sie eine Lösung von einem unserer Partner.

Kurzfristig sollte die Erweiterung Ihrer BigQuery-Datenvolumina und deren Verwendung für nachgelagerte Prozesse darauf ausgerichtet sein, Ihre wichtigsten Anwendungsfälle zu bedienen. Das mittelfristige Ziel ist, Ihre alten Datenquelle zu entfernen. Setzen Sie daher die ersten Iterationen überlegt ein. Wenden Sie keine großen Ressourcen dafür auf, die Aufnahmepipelines aus Ihrem alten Data Warehouse zu BigQuery zu perfektionieren. Letztendlich werden Sie diese Pipelines ohnehin so einrichten müssen, dass sie nicht mehr aus dieser Datenquelle schöpfen.

Schema optimieren

Durch Migration Ihrer Tabellen zu BigQuery können Sie bereits seine einzigartigen Features nutzen. Zum Beispiel müssen keine Indexe neu erstellt oder Datenblöcke neu gemischt werden (bereinigen) und es kommt zu keinen Ausfallzeiten oder Leistungseinbußen aufgrund von Versions-Upgrades.

Das Beibehalten des Data Warehouse-Modells über die anfänglichen Iterationen der Migration hinaus birgt jedoch auch Nachteile:

  • Alte Probleme und technische Altlasten im Zusammenhang mit dem Schema bleiben bestehen.
  • Abfrageoptimierungen sind begrenzt und müssen möglicherweise noch einmal durchgeführt werden, wenn das Schema später aktualisiert wird.
  • Sie können andere BigQuery-Features wie verschachtelte und wiederkehrende Felder, Partitionierung und Clustering nicht vollständig nutzen.

Für eine endgültige Übertragung empfehlen wir, die Systemleistung zu verbessern. Wenden Sie dazu Partitionierung und Clustering auf die Tabellen an, die Sie in Ihrem Schema erstellen.

Partitionierung

Mit BigQuery können Sie Ihre Daten in Segmente unterteilen, sogenannte Partitionen, mit denen Sie Ihre Daten einfacher und effizienter verwalten und abfragen können. Sie können Ihre Tabellen basierend auf der Spalte TIMESTAMP oder DATE partitionieren, oder BigQuery kann Pseudospalten hinzufügen, um Ihre Daten während der Datenaufnahme automatisch zu partitionieren. Da sie nur einen Teil der Daten scannen, können Abfragen mit kleinteiligeren Partitionen leistungsfähiger sein sowie durch Minimierung der zu lesenden Byte Kosten senken.

Partitionierung wirkt sich nicht auf Ihre vorhandene Tabellenstruktur aus. Daher sollten Sie in Betracht ziehen, partitionierte Tabellen zu erstellen, auch wenn Ihr Schema nicht geändert wird.

Clustering

In BigQuery werden keine Indexe zum Abfragen Ihrer Daten verwendet. Die Leistung von BigQuery wird durch das zugrunde liegende Modell, die Speicher- und Abfragetechniken und die massiv parallele Architektur optimiert. Bei einer Abfrage werden zum Scannen von Daten und zur gleichzeitigen Aggregierung der Ergebnisse umso mehr Computer eingesetzt, je mehr Daten verarbeitet werden. Diese Technik lässt sich gut für sehr große Datensätze skalieren. Neu erstellte Indexe können das nicht.

Dennoch lassen sich Abfragen mit Techniken wie Clustering weiter optimieren. Beim Clustering sortiert BigQuery Ihre Daten automatisch anhand der Werte einiger von Ihnen angegebener Spalten und ordnet sie in Blöcken mit optimaler Größe an. Clustering verbessert die Abfrageleistung. Mit Clustering kann BigQuery die Kosten für die Ausführung der Abfrage besser abschätzen als ohne Clustering. Mit geclusterten Spalten werden bei Abfragen auch keine unnötigen Daten gescannt und Aggregate können schneller berechnet werden, da die Blöcke Datensätze mit ähnlichen Werten zusammenfassen.

Ermitteln Sie, welche Spalten bei Ihren Abfragen häufig zum Filtern verwendet werden, und erstellen Sie Ihre Tabellen mit Clustering für diese Spalten. Clustering erfordert partitionierte Tabellen und wird auch bei der Tabellenerstellung definiert.

Denormalisierung

Datenmigration ist ein iterativer Prozess. Nachdem Sie Ihr ursprüngliches Schema in die Cloud verschoben, leichte Optimierungen durchgeführt und einige wichtige Anwendungsfälle getestet haben, ist es vielleicht Zeit, zusätzliche Funktionen zu erwägen, die vom zugrunde liegenden Design von BigQuery profitieren. Dazu gehören verschachtelte und wiederkehrende Felder.

Data Warehouse-Schemas nutzen üblicherweise die folgenden Modelle:

  • Sternschema. Dies ist ein denormalisiertes Modell, bei dem in einer Faktentabelle Messwerte wie Bestellbetrag, Rabatt und Menge zusammen mit einer Gruppe von Schlüsseln erfasst werden. Diese Schlüssel gehören zu Dimensionstabellen wie Kunde, Lieferant, Region usw. Grafisch ähnelt das Modell einem Stern, wobei die Faktentabelle in der Mitte von Dimensionstabellen umgeben ist.
  • Schneeflockenschema. Es ähnelt dem Sternschema, jedoch mit normalisierten Dimensionstabellen. Das Schema ähnelt daher einer einzigartigen Schneeflocke.

BigQuery unterstützt sowohl Stern- als auch Schneeflockenschemas; seine systemeigene Schemadarstellung ist jedoch keine dieser beiden. Es nutzt verschachtelte und wiederkehrende Felder, um die Daten natürlicher darzustellen. Weitere Informationen finden Sie in der BigQuery-Dokumentation im Beispielschema.

Das Ändern Ihres Schemas für die Verwendung verschachtelter und wiederkehrender Felder ist eine hervorragende Wahl für weitere Entwicklung. Es reduziert die Anzahl der für Ihre Abfragen erforderlichen Joins und richtet Ihr Schema an der internen BigQuery-Datendarstellung aus. Intern organisiert BigQuery Daten mit dem Dremel-Modell und speichert sie in einem Spaltenspeicherformat mit dem Namen Capacitor.

Für den besten Ansatz der Denormalisierung für Ihren Fall sollten Sie die Best Practices für die Denormalisierung in BigQuery sowie die Techniken für Schemaänderungen verarbeiten berücksichtigen.

Nächste Schritte

Mehr über die folgenden Schritte bei der Data Warehouse-Migration erfahren:

Außerdem erfahren Sie, wie Sie von bestimmten Data Warehouse-Technologien zu BigQuery wechseln: