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

Schema und Daten an BigQuery übertragen

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

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 vorhandenen Data Warehouse, wie in den mit A gekennzeichneten Abläufen dargestellt.
Konfigurieren Sie einige vorgelagerte Prozesse als Test, um Daten anstatt in das alte Data Warehouse (oder zusätzlich dazu) 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 Looker Studio und Dataflow einbinden.

Zu dieser Stelle haben Sie drei Datenflüsse:
1. Vorhandene. 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:
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.

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.

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.
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.
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.
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 Quell-BigQuery-Schema beziehen, wie in der folgenden Abbildung dargestellt:

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

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.
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 Quell-Schema abgerufen werden. Anschließend können Sie die Tabellen im Quell-Modell aus dem Datenfluss entfernen. Das folgende Diagramm zeigt den Zustand, wenn keine Quell-Tabellen mehr verwendet werden.

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:

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 existierenden 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 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 Datenextraktionsformat und ob Sie Ihre Daten kürzen oder anreichern möchten, bevor Sie sie in BigQuery laden, können Sie einen Schritt zum Transformieren Ihrer Daten hinzufügen. Sie können die Daten in der vorhandenen Umgebung oder in Google Cloud transformieren:

Wenn Sie die Daten in der aktuellen Umgebung transformieren, sollten Sie berücksichtigen, inwiefern die verfügbare Rechenkapazität und die verfügbaren Tools den Durchsatz begrenzen könnten. Wenn Sie die Daten während des Transformationsprozesses anreichern, sollten Sie außerdem berücksichtigen, ob Sie zusätzliche Übertragungszeit oder Netzwerkbandbreite benötigen.
Wenn der Transformationsschritt in Google Cloud ausgeführt wird, finden Sie unter Daten mit einem ETL-Tool laden weitere Informationen zu Ihren Optionen.

Vorhandenes Schema und Daten in Dateien extrahieren

Ihre vorhandene Plattform 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 vorhandenen Umgebung, wenn Sie diese Dateien aus Ihrer existierenden plattform extrahieren.

Dateien in Cloud Storage hochladen

Sofern Sie BigQuery Data Transfer Service nicht direkt zum Laden von Daten aus einem vorhandenen Amazon Redshift 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.
- Versuchen Sie es mit dem Drittanbietertool eines Google-Partners, wenn Sie gsutil nicht verwenden können.
- Wenn Ihre Netzwerkbandbreite begrenzt ist, können Sie die Datengröße mithilfe von Komprimierungstechniken verringern oder Ihre aktuelle Verbindung zu Google Cloud ändern, um die Bandbreite zu erhöhen.
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 alte 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. Anschließend können Sie Ihre vorgelagerten Datenfeeds an BigQuery umleiten, damit Ihr vorhandenes Data Warehouse nicht mehr ausgeführt werden muss. 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 alten 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 partners.

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 vorhandenes Data Warehouse zu entfernen. Setzen Sie die ersten Iterationen überlegt ein und investieren Sie keine großen Ressourcen in das Perfektionieren Ihrer Aufnahmepipelines von Ihrem vorhandenen Data Warehouse zu BigQuery. Letztendlich müssen Sie diese Pipelines so anpassen, dass sie nicht das vorhandene Data Warehouse nutzen.

Schema optimieren

Durch einfache Migration Ihrer Tabellen wie sie sind zu BigQuery können Sie von dessen einzigartigen Funktionen profitieren. 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:

Vorhandene 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: