Migration von Snowflock zu BigQuery

Dieses Dokument bietet einen technischen Hintergrund für die Migration von Daten von Snowflock zu BigQuery. Es werden die grundlegenden Unterschiede zwischen Snowflake und BigQuery behandelt. Außerdem finden Sie hier Informationen für eine erfolgreiche Migration, z. B. dazu:

  • Welche Schemaänderungen erforderlich sind
  • Welche Migrationstools und -optionen verfügbar sind
  • Wie Daten migriert werden (mit einem Beispielexportprozess)

Verwenden Sie die Batch-SQL-Übersetzung, um Ihre SQL-Skripts im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen. Snowflake SQL wird von beiden Tools in der Vorschau unterstützt.

Terminologie

In diesem Dokument wird die Snowflake- und BigQuery-Terminologie verwendet, um die Funktionalität der einzelnen Produkte zu beschreiben. In der folgenden Tabelle werden Snowflake-Begriffe den entsprechenden BigQuery-Begriffen zugeordnet:

Schneeflocke BigQuery
Datenbank Dataset
Schema Schema
Sitzungsspezifische temporäre oder transiente Tabelle Anonyme oder temporäre Tabelle
Anzeigen Anzeigen
Sichere Ansichten Autorisierte Ansichten
Virtuelles Warehouse Reservierung
Materialisierte Ansicht Materialisierte Ansicht
Kein Äquivalent für die Partitionierung (da die Mikropartitionierung verwendet wird) Partitionierung
Clustering Clustering
Sicherheitsoptimierte benutzerdefinierte Funktionen (UDFs) Autorisierte UDFs

Architekturvergleich

Snowflake und BigQuery sind beide analytische Data Warehouses, haben aber einige wichtige Architekturunterschiede.

Die Snowflake-Architektur ist eine Mischung aus herkömmlichen Datenbankarchitekturen mit einem freigegebenen Laufwerk und Shared-Nothing-Datenbankarchitekturen. Wie bei Shared-Nothing-Architekturen werden Daten in Snowflake in einem separaten Cloud-Objektspeicherdienst verwaltet. Wie bei einer Architektur mit freigegebenen Laufwerken verwenden Abfragen in Snowflake dedizierte Computing-Cluster. In Snowflake verwaltet jeder Cluster im Cache gespeicherte Teile des gesamten Datasets, um die Abfrageleistung zu beschleunigen. Weitere Informationen finden Sie in der Snowflake-Architektur.

Die Architektur von BigQuery unterscheidet sich erheblich von herkömmlichen knotenbasierten Cloud Data Warehouse-Lösungen oder MPP-Systemen. Es entkoppelt Speicherung und Computing, sodass sie unabhängig nach Bedarf skaliert werden können. Weitere Informationen finden Sie unter BigQuery under the hood.

Vergleich der Benutzeroberfläche

Die Web-UI von Snowflake spiegelt die Snowflake-Befehlszeile (CLI) wider. Mit beiden Oberflächen können Sie Folgendes tun:

  • Datenbanken verwalten
  • Warehouses verwalten
  • Abfragen und Arbeitsblätter verwalten
  • Historische Abfragen aufrufen

In der Weboberfläche können Sie auch das Snowflake-Passwort und die Nutzereinstellungen verwalten.

Der Snowflake-CLI-Client verwendet SnowSQL, um eine Verbindung zu Snowflake herzustellen, um SQL-Abfragen und andere Vorgänge auszuführen.

Die BigQuery-Benutzeroberfläche ist in die Google Cloud Console eingebunden und enthält eine Liste der BigQuery-Ressourcen, die Sie aufrufen können:

  • Im Abschnitt BigQuery Studio werden Ihre Datasets, Tabellen, Ansichten und andere BigQuery-Ressourcen angezeigt. Hier können Sie Abfragen erstellen und ausführen, mit Tabellen und Ansichten arbeiten, sich Ihren BigQuery-Jobverlauf ansehen und andere gängige BigQuery-Aufgaben ausführen.
  • Im Abschnitt Datenübertragungen wird die BigQuery Data Transfer Service-Seite geöffnet.
  • Im Abschnitt Geplante Abfragen werden die geplanten Abfragen angezeigt.
  • Im Abschnitt Kapazitätsverwaltung werden Slot-Zusicherungen, Reservierungen und Reservierungszuweisungen angezeigt.
  • Der Abschnitt BI Engine öffnet die Seite "BigQuery BI Engine".

BigQuery verfügt auch über ein Befehlszeilentool, das auf Python basiert. Weitere Informationen finden Sie unter bq-Befehlszeilentool verwenden.

Sicherheit

Bei der Migration von Snowflake zu BigQuery müssen Sie berücksichtigen, wie die Sicherheit bei Google Cloud im Allgemeinen und BigQuery im Speziellen anders als bei Snowflake gewährleistet wird.

Snowflake hat verschiedene sicherheitsbezogene Features wie die folgenden:

  • Netzwerk- und Websitezugriff
  • Konto- und Nutzerauthentifizierung
  • Objektsicherheit
  • Datensicherheit
  • Sicherheitsvalidierungen

Die Sicherheit in Snowflake basiert auf den Features Ihres Cloud-Anbieters. Sie bietet detaillierte Kontrolle über den Zugriff auf Objekte und Objektvorgänge und darüber, wer Zugriffssteuerungsrichtlinien erstellen oder ändern kann.

Die zu den Zugriffssteuerungsberechtigungen von Snowflake parallelen BigQuery-Berechtigungen sind IAM-Rollen (Identity and Access Management) in Google Cloud. Diese Berechtigungen bestimmen, welche Vorgänge für eine Ressource zulässig sind. Berechtigungen werden auf Google Cloud-Ebene erzwungen.

Verschlüsselung

In Snowflake wird die Sicherheit auf Spaltenebene in der Enterprise-Version unterstützt. Vom Kunden verwaltete Verschlüsselungsschlüssel werden in der Business Critical-Version unterstützt. Diese Versionen haben unterschiedliche Preise. In BigQuery werden alle Features und erweiterten Sicherheitsmaßnahmen ohne zusätzliche Kosten als Standardfeatures angeboten.

Snowflake bietet eine End-to-End-Verschlüsselung, bei der alle gespeicherten Daten automatisch verschlüsselt werden. Google Cloud bietet dasselbe Feature, indem standardmäßig alle Daten im ruhenden Zustand und bei der Übertragung verschlüsselt werden.

Ähnlich wie die Snowflake Business Critical-Version unterstützt BigQuery vom Kunden verwaltete Verschlüsselungsschlüssel für Nutzer, die Schlüsselverschlüsselungsschlüssel in Cloud Key Management Service steuern und verwalten möchten. BigQuery ermöglicht auch die Verschlüsselung auf Spaltenebene. Weitere Informationen zur Verschlüsselung in Google Cloud finden Sie unter Verschlüsselung ruhender Daten in Google Cloud und Verschlüsselung bei der Übertragung in Google Cloud.

Rollen

Rollen sind die Entitäten, für die Berechtigungen für sicherbare Objekte gewährt und widerrufen werden können.

Snowflake unterstützt die folgenden zwei Arten von Rollen:

  • Systemdefinierte Rollen: Diese Rollen bestehen aus system- und sicherheitsbezogenen Berechtigungen und werden mit Berechtigungen erstellt, die sich auf die Kontoverwaltung beziehen.
  • Benutzerdefinierte Rollen: Sie können diese Rollen mit den SECURITYADMIN-Rollen oder einer beliebigen Rolle mit der Berechtigung CREATE ROLE erstellen. Jede benutzerdefinierte Rolle in Snowflake besteht aus Berechtigungen.

In IAM werden Berechtigungen in Rollen gruppiert. IAM bietet drei Arten von Rollen:

  • Einfache Rollen: Diese Rollen umfassen die Rollen "Inhaber", "Bearbeiter" und "Betrachter". Sie können diese Rollen auf Projekt- oder Dienstressourcenebene mithilfe der Google Cloud Console, der Identity and Access Management API oder der gcloud CLI anwenden. Für die höchste Sicherheit empfehlen wir im Allgemeinen, BigQuery-spezifische Rollen zu verwenden, um dem Prinzip der geringsten Berechtigung zu folgen.
  • Vordefinierte Rollen: Diese Rollen ermöglichen einen detaillierteren Zugriff auf Features in einem Produkt wie BigQuery und sollen allgemeine Anwendungsfälle und Zugriffssteuerungsmuster unterstützen.
  • Benutzerdefinierte Rollen: Diese Rollen bestehen aus benutzerdefinierten Berechtigungen.

Zugriffssteuerung

Mit Snowflake können Sie anderen Rollen Rollen zuweisen und so eine Hierarchie von Rollen erstellen. IAM unterstützt keine Rollenhierarchie, implementiert jedoch eine Ressourcenhierarchie. Die IAM-Hierarchie umfasst die Organisationsebene, die Ordnerebene, die Projektebene und die Ressourcenebene. Sie können IAM-Rollen auf jeder Hierarchieebene festlegen und Ressourcen übernehmen alle Richtlinien der ihnen übergeordneten Ressourcen.

Sowohl Snowflake als auch BigQuery unterstützen die Zugriffssteuerung auf Tabellenebene. Berechtigungen auf Tabellenebene bestimmen, welche Nutzer, Gruppen und Dienstkonten auf eine Tabelle oder Ansicht zugreifen können. Sie können einem Nutzer Zugriff auf bestimmte Tabellen oder Ansichten geben, ohne dadurch Zugriff auf das gesamte Dataset zu gewähren.

Snowflake verwendet außerdem Sicherheit auf Zeilenebene und Sicherheit auf Spaltenebene.

IAM bietet in BigQuery eine Zugriffssteuerung auf Tabellenebene. Für einen detaillierteren Zugriff können Sie auch die Zugriffssteuerung auf Spaltenebene oder die Sicherheit auf Zeilenebene verwenden. Diese Art der Steuerung bietet mithilfe von Richtlinien-Tags oder typbasierten Datenklassifizierungen einen differenzierten Zugriff auf vertrauliche Spalten.

Sie können auch autorisierte Ansichten erstellen, um den Datenzugriff für eine detailliertere Zugriffssteuerung zu beschränken, sodass bestimmte Nutzer eine Ansicht abfragen können, ohne Lesezugriff auf die zugrunde liegenden Tabellen zu haben.

Bei der Migration zu berücksichtigende Punkte

Es gibt einige Snowflake-Features, die Sie nicht direkt nach BigQuery portieren können. BigQuery bietet beispielsweise für die folgenden Szenarien keine integrierte Unterstützung. In diesen Szenarien müssen Sie möglicherweise andere Dienste in Google Cloud verwenden.

  • Zeitreisen: In BigQuery können Sie mit Zeitreisen auf Daten jedes Zeitpunkts innerhalb der letzten sieben Tage zugreifen. Wenn Sie über sieben Tage hinaus auf Daten zugreifen müssen, sollten Sie den Export regelmäßig geplanter Snapshots in Betracht ziehen. Snowflake bietet Zugriff auf Verlaufsdaten (Daten, die geändert oder gelöscht wurden) für beliebige Zeitpunkte innerhalb eines festgelegten Zeitraums. Sie können diesen Zeitraum auf einen beliebigen Wert zwischen 0 und 90 Tagen festlegen.

  • Streams: BigQuery unterstützt Change Data Capture (CDC) mit Datastream. Sie können auch CDC-Software wie Debezium verwenden, um Datensätze mit Dataflow in BigQuery zu schreiben. Weitere Informationen zum manuellen Entwerfen einer CDC-Pipeline mit BigQuery finden Sie unter Data Warehouses zu BigQuery migrieren: Change Data Capture (CDC). In Snowflake zeichnet ein Streamobjekt Änderungen der Datenbearbeitungssprache auf, die an Tabellen vorgenommen wurden, sowie Metadaten zu jeder Änderung, damit Sie Aktionen mit den geänderten Daten ausführen können.

  • Aufgaben: Mit BigQuery können Sie Abfragen und Streams oder die Integration von Streams in Abfragen mit Datastream planen. Snowflake kann Aufgaben mit Tabellenstreams kombinieren und so Workflows kontinuierlich extrahieren, laden und übertragen, um kürzlich geänderte Tabellenzeilen zu verarbeiten.

  • Externe Funktionen: BigQuery unterstützt externe Funktionsaufrufe über Cloud Functions. Sie können außerdem benutzerdefinierte Funktionen (UDF) wie SQL UDF verwenden, aber diese Funktionen werden nicht außerhalb von BigQuery ausgeführt. In Snowflake ruft eine externe Funktion Code auf, der außerhalb von Snowflake ausgeführt wird. Beispielsweise werden Informationen, die an einen Remotedienst gesendet werden, in der Regel über einen Proxydienst weitergeleitet.

Daten von Snowflake zu BigQuery migrieren

In diesem Abschnitt wird beschrieben, wie Sie die Migration von Snowflake zu BigQuery auf Basis des unter Data Warehouses zu BigQuery migrieren: Was und wie migriert wird beschriebenen Frameworks konfigurieren und initiieren.

Architektur

Zum Starten der Migration führen Sie sowohl Snowflake als auch BigQuery aus. Das folgende Diagramm zeigt eine Architektur, die vorhandene Vorgänge nur minimal beeinflusst. Durch die Übertragung sauberer Daten mit kontrollierter Qualität können Sie vorhandene Tools und Prozesse wiederverwenden, während Sie Arbeitslasten zu BigQuery verlagern. Sie können Berichte und Dashboards auch mit alten Versionen validieren. Da OLAP-Daten jedoch an redundanten Orten gespeichert werden, ist dieser Vorgang nicht kostengünstig. Außerdem wird die Verarbeitungszeit verlängert.

  • Punkt 1 zeigt Daten, die von Snowflake zu Cloud Storage verschoben werden.
  • Punkt 2 zeigt die Persistenz der Daten in BigQuery.
  • Punkt 3 zeigt, wie die Daten an den Endnutzer gesendet werden.

Sie können Berichte und Dashboards mit alten Iterationen validieren. Weitere Informationen finden Sie unter Data Warehouses zu BigQuery migrieren: Überprüfen und Validieren.

Eine fortlaufende Migration von Snowflake zu BigQuery

Die endgültige Architektur für Ihre Data-Warehouse-Migration speichert alle Daten aus Quellsystemen direkt in Google Cloud. Abhängig von der Anzahl und Komplexität der Quellsysteme kann die Bereitstellung dieser Architektur in weitere Schritte aufgeteilt werden, indem die Quellsysteme nacheinander abhängig von ihrer Priorität, von Interdependenzen, Integrationsrisiken oder anderen geschäftlichen Faktoren angegangen werden.

Im folgenden Diagramm wird von der Migration der Datenpipelines und der Aufnahme in Google Cloud ausgegangen.

  • Punkt 1 zeigt sowohl synchrone als auch asynchrone Integrationspunkte. Die synchrone Integration erfolgt beispielsweise zwischen Datenquellen und App Engine, wenn es um Anwendungsfälle geht, in denen als Teil des Ablaufs explizite Nutzeraktionen erforderlich sind.
  • Punkt 2 zeigt die Verwendung von Pub/Sub für große Mengen gleichzeitiger Ereignisdaten.
  • Punkt 3 zeigt die Persistenz von Daten mit einem oder mehreren Google Cloud-Produkten, je nach Art der Daten.
  • Punkt 4 zeigt den ETL-Prozess (Extrahieren, Transformieren und Laden) in BigQuery.

Nach der Migration von Snowflake zu BigQuery

Cloud Storage-Umgebung vorbereiten

Google Cloud bietet verschiedene Möglichkeiten, Ihre Daten mit anderen ETL-Tools an BigQuery zu übertragen. Das Muster sieht so aus:

  1. Daten aus der Quelle extrahieren: Kopieren Sie die extrahierten Dateien aus der Quelle in den Staging-Speicher in Ihrer lokalen Umgebung. Weitere Informationen finden Sie unter Data Warehouses zu BigQuery migrieren: Quelldaten extrahieren.

  2. Daten in einen Cloud Storage-Staging-Bucket übertragen: Nachdem Sie Daten aus Ihrer Quelle extrahiert haben, übertragen Sie sie in einen temporären Bucket in Cloud Storage. Je nach der übertragenen Datenmenge und der verfügbaren Netzwerkbandbreite haben Sie mehrere Optionen.

    Es ist wichtig, dass sich der Speicherort Ihres BigQuery-Datasets und Ihrer externen Datenquelle oder Ihres Cloud Storage-Buckets in derselben Region befinden. Weitere Informationen zu geografischen Überlegungen zum Laden von Daten aus Cloud Storage finden Sie unter Daten im Batch laden.

  3. Daten aus dem Cloud Storage-Bucket in BigQuery laden: Ihre Daten befinden sich jetzt in einem Cloud Storage-Bucket näher am Ziel. Es gibt verschiedene Möglichkeiten, die Daten in BigQuery hochzuladen. Diese Optionen hängen davon ab, wie stark die Daten transformiert werden müssen. Alternativ können Sie Ihre Daten in BigQuery mithilfe des ETL-Ansatzes transformieren.

    Wenn Sie mehrere Daten aus einer JSON-Datei, einer Avro-Datei oder einer CSV-Datei importieren, erkennt BigQuery das Schema automatisch. Sie müssen es also nicht vordefinieren. Eine detaillierte Übersicht über den Schemamigrationsprozess für EDW-Arbeitslasten finden Sie unter Schema- und Datenmigrationsprozess.

Unterstützte Datentypen, Attribute und Dateiformate

Snowflake und BigQuery unterstützen größtenteils dieselben Datentypen, obwohl sie manchmal unterschiedliche Namen verwenden. Eine vollständige Liste der unterstützten Datentypen in Snowflake und BigQuery finden Sie im Abschnitt Datentypen der SQL-Übersetzungsreferenz von Snowflake. Sie können auch den Batch-SQL-Übersetzer zum Übersetzen verwenden. Weitere Informationen zu den von BigQuery unterstützten Datentypen finden Sie unter GoogleSQL-Datentypen.

Snowflake kann Daten in den folgenden Dateiformaten exportieren. Sie können die Formate direkt in BigQuery laden:

Schemaänderungen

Wenn Sie Schemaänderungen bei der Migration zu BigQuery planen, empfehlen wir, dass Sie zuerst Ihr Schema unverändert migrieren. BigQuery unterstützt eine breite Palette von Datenmodell-Designmustern, z. B. Sternschema oder Snowflake-Schema. Aufgrund dieser Unterstützung müssen Sie Ihre vorgelagerten Datenpipelines nicht für ein neues Schema aktualisieren und können automatisierte Migrationstools verwenden, um Ihre Daten und Ihr Schema zu übertragen.

Schema aktualisieren

Sobald sich die Daten in BigQuery befinden, können Sie das Schema jederzeit aktualisieren, indem Sie beispielsweise der Schemadefinition Spalten hinzufügen oder den Modus einer Spalte von REQUIRED zu NULLABLE lockern.

BigQuery verwendet für den Tabellennamen Namenskonventionen, bei denen die Groß- und Kleinschreibung berücksichtigt wird, während Snowflake Namensmuster ohne Berücksichtigung der Groß- und Kleinschreibung verwendet. Diese Konvention bedeutet, dass Sie möglicherweise alle Inkonsistenzen in den Namenskonventionen für Tabellen, die in Snowflake vorhanden sein können, noch einmal prüfen und alle Inkonsistenzen, die während der Migration zu BigQuery aufgetreten sind, korrigieren müssen. Weitere Informationen zur Schemaänderung finden Sie unter Tabellenschemas ändern.

Einige Schemaänderungen werden in BigQuery nicht direkt unterstützt und erfordern manuelle Problemumgehungen, einschließlich:

  • Name einer Spalte ändern
  • Datentyp einer Spalte ändern
  • Modus einer Spalte ändern (außer zum Lockern von REQUIRED zu NULLABLE)

Eine genaue Anleitung zum manuellen Implementieren dieser Schemaänderungen finden Sie unter Tabellenschemas manuell ändern.

Optimierung

Nach der Schemamigration können Sie die Leistung testen und anhand der Ergebnisse Optimierungen vornehmen. Sie können beispielsweise die Partitionierung einführen, um die Daten effizienter zu verwalten und abzufragen. Die Partitionierung in BigQuery bezieht sich auf eine spezielle Tabelle, die in Segmente unterteilt ist, die als Partitionen bezeichnet werden. Die Partitionierung unterscheidet sich von der Mikropartitionierung von Snowflake, die automatisch beim Laden von Daten erfolgt. Mit der Partitionierung von BigQuery können Sie die Abfrageleistung und die Kostenkontrolle durch Partitionierung nach Aufnahmezeit, Zeitstempel oder Ganzzahlbereich verbessern. Weitere Informationen finden Sie unter Einführung in partitionierte Tabellen.

Geclusterte Tabellen

Geclusterte Tabellen sind eine weitere Schemaoptimierung. Mit BigQuery können Sie, wie bei Snowflake, Tabellen gruppieren, um Tabellendaten anhand des Inhalts einer oder mehrerer Spalten im Tabellenschema automatisch zu organisieren. BigQuery verwendet die von Ihnen angegebenen Spalten, um verwandte Daten am selben Ort zu platzieren. Clustering kann die Leistung bestimmter Abfragetypen verbessern, z. B. Abfragen, die Filterklauseln verwenden, oder Abfragen, die Daten aggregieren. Weitere Informationen zur Funktionsweise geclusterter Tabellen in BigQuery finden Sie unter Einführung in geclusterte Tabellen.

Migrationstools

In der folgenden Liste werden die Tools beschrieben, mit denen Sie Daten von Snowflake zu BigQuery migrieren können. Diese Tools werden im Abschnitt Beispiele für die Migration mit Pipelines kombiniert, um End-to-End-Migrationspipelines zu erstellen.

  • Befehl COPY INTO <location>: Verwenden Sie diesen Befehl in Snowflake, um Daten aus einer Snowflake-Tabelle direkt in einen bestimmten Cloud Storage-Bucket zu entladen. Ein End-to-End-Beispiel finden Sie unter Snowflake zu BigQuery (snowflake2bq) auf GitHub.
  • Apache Sqoop: Wenn Sie Daten aus Snowflake in HDFS oder Cloud Storage extrahieren möchten, senden Sie Hadoop-Jobs mit Sqoop und dem JDBC-Treiber von Snowflake. Sqoop wird in einer Dataproc-Umgebung ausgeführt.
  • Snowflake-JDBC: Verwenden Sie diesen Treiber mit den meisten Clienttools oder Anwendungen, die JDBC unterstützen.

Mit den folgenden generischen Tools können Sie Daten von Snowflake zu BigQuery migrieren:

  • BigQuery Data Transfer Service: Führen Sie mit diesem vollständig verwalteten Dienst eine automatisierte Batchübertragung von Cloud Storage-Daten nach BigQuery durch. Bei diesem Tool müssen Sie zuerst die Snowflake-Daten nach Cloud Storage exportieren.
  • gsutil: Mit diesem Befehlszeilentool können Sie heruntergeladene Snowflake-Dateien in Cloud Storage kopieren.
  • bq-Befehlszeilentool: Über dieses Befehlszeilentool können Sie mit BigQuery interagieren. Gängige Anwendungsfälle sind z. B. das Erstellen von BigQuery-Tabellenschemas, das Laden von Cloud Storage-Daten in Tabellen und das Ausführen von Abfragen.
  • Cloud Storage-Clientbibliotheken: Kopieren Sie heruntergeladene Snowflake-Dateien mit einem benutzerdefinierten Tool, das die Cloud Storage-Clientbibliotheken verwendet, in Cloud Storage.
  • BigQuery-Clientbibliotheken: Interagieren Sie mit BigQuery mit einem benutzerdefinierten Tool, das auf der BigQuery-Clientbibliothek basiert.
  • BigQuery-Abfrageplaner: Planen Sie wiederkehrende SQL-Abfragen mit diesem integrierten BigQuery-Feature.
  • Cloud Composer: Verwenden Sie diese vollständig verwaltete Apache Airflow-Umgebung, um BigQuery-Ladejobs und -Transformationen zu orchestrieren.

Weitere Informationen zum Laden von Daten in BigQuery finden Sie unter Daten in BigQuery laden.

Beispiele für die Migration mit Pipelines

In den folgenden Abschnitten finden Sie Beispiele dafür, wie Sie Ihre Daten mit drei verschiedenen Techniken von Snowflake zu BigQuery migrieren: Extrahieren und Laden, ETL und Partnertools.

Extrahieren und Laden

Die Techniken mit Extrahieren und Laden bietet zwei Methoden:

  • Pipeline zum Entladen von Daten aus Snowflake verwenden
  • Pipeline und JDBC-Treiber zum Exportieren von Daten aus Snowflake verwenden

Pipeline zum Entladen von Daten aus Snowflake verwenden

Wenn Sie Daten aus Snowflake direkt nach Cloud Storage entladen möchten (empfohlen) oder Daten herunterladen und mithilfe von gsutil oder mit Cloud Storage-Clientbibliotheken in Cloud Storage kopieren möchten, verwenden Sie das snowflake2bq-Tool, um Daten mit dem Snowflake-Befehl COPY INTO <location> zu migrieren.

Anschließend laden Sie Cloud Storage-Daten mit einem der folgenden Tools in BigQuery:

  • BigQuery Data Transfer Service
  • bq-Befehlszeilentool
  • BigQuery API-Clientbibliotheken

Pipeline und JDBC-Treiber zum Exportieren von Daten aus Snowflake verwenden

Verwenden Sie eines der folgenden Produkte, um Snowflake-Daten mit dem JDBC-Treiber von Snowflake zu exportieren:

Extrahieren, Transformieren und Laden

Wenn Sie die Daten transformieren möchten, bevor Sie sie in BigQuery laden, können Sie einen Transformationsschritt in die Pipelines einfügen, der im vorherigen Abschnitt Extrahieren und Laden beschrieben wurde.

Snowflake-Daten transformieren

Um Ihre Daten vor dem Laden in BigQuery zu transformieren, entladen Sie die Daten entweder direkt aus Snowflake nach Cloud Storage oder kopieren Sie Daten mit gsutil, wie im vorherigen Abschnitt Extrahieren und Laden beschrieben.

Snowflake-Daten laden

Nach der Transformation Ihrer Daten haben Sie die Möglichkeit, die Daten mit einer der folgenden Methoden in BigQuery zu laden:

Pipeline und JDBC-Treiber zum Transformieren und Exportieren von Daten aus Snowflake verwenden

Fügen Sie in den folgenden Pipelineoptionen einen Transformationsschritt hinzu, wie im vorherigen Abschnitt Extrahieren und Laden beschrieben.

Vielleicht haben Sie einen Anwendungsfall zum Extrahieren, Laden und Transformieren, um die Daten aus Snowflake in BigQuery zu laden und dann zu transformieren. Wenn Sie diese Aufgabe ausführen möchten, laden Sie die Daten aus Snowflake in eine BigQuery-Staging-Tabelle. Verwenden Sie dazu eine der Methoden im vorherigen Abschnitt Extrahieren und Laden. Anschließend führen Sie SQL-Abfragen für die Staging-Tabelle aus und schreiben die Ausgabe in die endgültige Produktionstabelle in BigQuery.

Partnertools für die Migration

Es gibt mehrere Anbieter, die sich auf den EDW-Migrationsraum spezialisiert haben. Eine Liste der wichtigsten Partner und ihrer Lösungen finden Sie auf der BigQuery-Partnerwebsite von Google Cloud.

Beispiele für den Exportprozess

In den folgenden Abschnitten wird ein Beispiel für den Export von Daten von Snowflake nach BigQuery gezeigt, bei dem der Befehl COPY INTO <location> von Snowflake verwendet wird. Eine detaillierte Schritt-für-Schritt-Anleitung, die Codebeispiele enthält, finden Sie im Artikel zum Tool „Snowflake to BigQuery“ der Google Cloud-Dienstleistungen.

Auf Export vorbereiten

Verwenden Sie zum Entladen die Snowflake-SQL-Anweisungen, um eine benannte Dateiformatspezifikation zu erstellen.

In dieser Anleitung wird my_parquet_unload_format für das Dateiformat verwendet. Sie können jedoch auch einen anderen Namen verwenden.

   create or replace file format my_parquet_unload_format
     type = 'PARQUET'
     field_delimiter = '|'

Snowflake-Daten exportieren

Nachdem Sie Ihre Daten vorbereitet haben, müssen Sie sie in Google Cloud verschieben. Sie können diesen Schritt über eine der beiden folgenden Methoden ausführen:

  1. Exportieren Ihrer Daten direkt von Snowflake nach Cloud Storage
  2. Staging Ihrer Snowflake-Daten in einem Amazon Simple Storage Service-Bucket (Amazon S3) oder in Azure Blob Storage

Sie können Ihre Daten direkt exportieren, um einen zusätzlichen Daten-Hop zu vermeiden.

Snowflake-Daten direkt nach Cloud Storage exportieren

In der folgenden Anleitung wird gezeigt, wie Sie mit dem Snowflake-Befehl COPY Daten von Snowflake nach Cloud Storage entladen:

  1. Konfigurieren Sie in Snowflake ein Speicherintegrationsobjekt, damit Snowflake in einen Cloud Storage-Bucket schreiben kann, auf den in einer externen Cloud Storage-Phase verwiesen wird.

    Dieser Schritt umfasst mehrere Unterschritte.

    1. Erstellen Sie eine Integration mit dem Befehl CREATE STORAGE INTEGRATION:

      create storage integration gcs_int
  type = external_stage
  storage_provider = gcs
  enabled = true
  storage_allowed_locations = ('gcs://mybucket/unload/')

    2. Rufen Sie das Cloud Storage-Dienstkonto für Snowflake mit dem Befehl DESCRIBE INTEGRATION ab und gewähren Sie dem Dienstkonto Berechtigungen für den Zugriff auf die Cloud Storage-Bucket, der als Staging-Bereich ausgewählt ist:

      desc storage integration gcs_int;

      +-----------------------------+---------------+-----------------------------------------------------------------------------+------------------+
| property                    | property_type | property_value                                                              | property_default |
+-----------------------------+---------------+-----------------------------------------------------------------------------+------------------|
| ENABLED                     | Boolean       | true                                                                        | false            |
| STORAGE_ALLOWED_LOCATIONS   | List          | gcs://mybucket1/path1/,gcs://mybucket2/path2/                               | []               |
| STORAGE_BLOCKED_LOCATIONS   | List          | gcs://mybucket1/path1/sensitivedata/,gcs://mybucket2/path2/sensitivedata/   | []               |
| STORAGE_GCP_SERVICE_ACCOUNT | String        | service-account-id@project1-123456.iam.gserviceaccount.com                  |                  |
+-----------------------------+---------------+---------------------------------------------------------
--------------------+------------------+

    3. Erstellen Sie eine externe Cloud Storage-Phase, die auf die Integration verweist, die Sie mit dem Befehl CREATE STAGE erstellt haben:

      create or replace stage my_ext_unload_stage
  url='gcs://mybucket/unload'
  storage_integration = gcs_int
  file_format = my_parquet_unload_format;

  2. Verwenden Sie den Befehl COPY INTO <location>, um Daten aus der Snowflake-Datenbank in einen Cloud Storage-Bucket zu kopieren. Geben Sie dazu das Objekt der externen Phase an, das Sie im vorherigen Schritt erstellt haben:

    copy into @my_ext_unload_stage/d1
from mytable;

Snowflake-Daten über Storage Transfer Service von Amazon S3 nach Cloud Storage exportieren

Das folgende Beispiel zeigt, wie Sie mit dem Befehl COPY Daten aus einer Snowflake-Tabelle in einen Amazon S3-Bucket entladen:

  1. Konfigurieren Sie in Snowflake ein Speicherintegrationsobjekt, damit Snowflake in einen Amazon S3-Bucket schreiben kann, auf den in einer externen Cloud Storage-Phase verwiesen wird.

    Dieser Schritt umfasst die Konfiguration von Zugriffsberechtigungen für den Amazon S3-Bucket, das Erstellen der AWS IAM-Rolle und das Erstellen einer Speicherintegration in Snowflake mit dem Befehl CREATE STORAGE INTEGRATION:

    create storage integration s3_int
  type = external_stage
  storage_provider = s3
  enabled = true
  storage_aws_role_arn = 'arn:aws:iam::001234567890:role/myrole'
  storage_allowed_locations = ('s3://unload/files/')

  2. Rufen Sie den AWS IAM-Nutzer mit dem Befehl DESCRIBE INTEGRATION ab:

    desc integration s3_int;

    +---------------------------+---------------+================================================================================+------------------+
| property                  | property_type | property_value                                                                 | property_default |
+---------------------------+---------------+================================================================================+------------------|
| ENABLED                   | Boolean       | true                                                                           | false            |
| STORAGE_ALLOWED_LOCATIONS | List          | s3://mybucket1/mypath1/,s3://mybucket2/mypath2/                                | []               |
| STORAGE_BLOCKED_LOCATIONS | List          | s3://mybucket1/mypath1/sensitivedata/,s3://mybucket2/mypath2/sensitivedata/    | []               |
| STORAGE_AWS_IAM_USER_ARN  | String        | arn:aws:iam::123456789001:user/abc1-b-self1234                                 |                  |
| STORAGE_AWS_ROLE_ARN      | String        | arn:aws:iam::001234567890:role/myrole                                          |                  |
| STORAGE_AWS_EXTERNAL_ID   | String        | MYACCOUNT_SFCRole=                                                   |                  |
+---------------------------+---------------+================================================================================+------------------+

  3. Gewähren Sie dem AWS IAM-Nutzer Berechtigungen zum Zugriff auf den Amazon S3-Bucket und erstellen Sie eine externe Phase mit dem Befehl CREATE STAGE:

      create or replace stage my_ext_unload_stage url='s3://unload/files/'
    storage_integration = s3_int
    file_format = my_parquet_unload_format;

  4. Kopieren Sie mit dem Befehl COPY INTO <location> die Daten aus der Snowflake-Datenbank in den Amazon S3-Bucket, indem Sie das Objekt der externen Phase angeben, das Sie zuvor erstellt haben:

      copy into @my_ext_unload_stage/d1 from mytable;

  5. Übertragen Sie die exportierten Dateien mit Storage Transfer Service nach Cloud Storage.

Exportieren Sie Snowflake-Daten über andere Cloud-Anbieter nach Cloud Storage:

Azure Blob Storage: Führen Sie die Schritte unter In Microsoft Azure entladen aus. Übertragen Sie dann die exportierten Dateien mit Storage Transfer Service nach Cloud Storage.

Amazon S3-Bucket: Folgen Sie der Anleitung unter In Amazon S3 entladen. Übertragen Sie dann die exportierten Dateien mithilfe von Storage Transfer Service nach Cloud Storage.

Nächste Schritte