Migration de Snowflake vers BigQuery

Ce document fournit des informations techniques sur la migration des données depuis Snowflake vers BigQuery. Il porte sur les différences fondamentales entre Snowflake et BigQuery Il fournit également des conseils pour mettre en œuvre une migration réussie, par exemple :

  • Les modifications de schéma nécessaires
  • Les outils et options de migration disponibles
  • La migration des données (à l'aide d'un exemple de processus d'exportation)

Vous pouvez également utiliser la traduction SQL par lot pour migrer vos scripts SQL de façon groupée, ou la traduction SQL interactive pour traduire des requêtes ad hoc. Snowflake SQL est compatible avec les deux outils en version bêta.

Terminologie

Ce document utilise la terminologie de Snowflake et de BigQuery pour décrire les fonctionnalités fournies par chacun des produits. Le tableau suivant met en correspondance les termes propres à Snowflake et leurs équivalents pour BigQuery :

Flocon de neige BigQuery
Base de données Dataset
Schema Schema
Table temporaire spécifique à une session Table anonyme ou temporaire
View View
Vues sécurisées Vues autorisées
Entrepôt virtuel Réservation
Vue matérialisée Vue matérialisée
Aucun équivalent pour le partitionnement (car le micro-partitionnement est utilisé) Partitionnement
Filtrage par cluster Filtrage par cluster
Fonctions définies par l'utilisateur sécurisées Fonctions définies par l'utilisateur autorisées

Comparaison des architectures

Snowflake et BigQuery sont tous deux des entrepôts de données d'analyse, mais ils présentent des différences d'architecture clés.

L'architecture de Snowflake est un mélange d'architectures de bases de données traditionnelles à disque partagé et d'architectures de bases de données sans partage. Comme pour les architectures sans partage, les données dans Snowflake sont gérées dans un service de stockage d'objets cloud indépendant. Comme pour une architecture à disque partagé, les requêtes dans Snowflake utilisent des clusters de calcul dédiés. Dans Snowflake, chaque cluster gère des mises en cache de portions de l'ensemble de données global, afin d'accélérer les performances des requêtes. Pour en savoir plus, consultez la section Architecture Snowflake.

L'architecture de BigQuery est très différente des solutions d'entrepôt de données cloud ou de systèmes MPP traditionnels basés sur des nœuds. Elle dissocie le stockage et le calcul, ce qui leur permet d'évoluer indépendamment à la demande. Pour en savoir plus, consultez la page Les rouages de BigQuery.

Comparaison des interfaces utilisateur

L'interface Web de Snowflake met en miroir l'interface de ligne de commande (CLI) Snowflake. Les deux interfaces vous permettent d'effectuer les opérations suivantes :

  • Gérer des bases de données
  • Gérer des entrepôts
  • Gérer des requêtes et des feuilles de calcul
  • Afficher les requêtes d'historique

L'interface Web vous permet également de gérer votre mot de passe et vos préférences utilisateur Snowflake.

Le client CLI Snowflake utilise SnowSQL pour se connecter à Snowflake afin d'exécuter des requêtes SQL et d'autres opérations.

L'interface BigQuery est intégrée à Google Cloud Console et contient une liste de ressources BigQuery que vous pouvez afficher :

  • La section BigQuery Studio affiche vos ensembles de données, vos tables, vos vues et d'autres ressources BigQuery. C'est ici que vous pouvez créer et exécuter des requêtes, travailler avec des tables et des vues, consulter l'historique des tâches BigQuery et effectuer d'autres tâches BigQuery courantes.
  • La section Transferts de données ouvre l'interface utilisateur du service de transfert de données BigQuery.
  • La section Requêtes programmées affiche les requêtes que vous avez planifiées.
  • La section Gestion de la capacité affiche les engagements d'emplacements, les réservations et les attributions de réservation.
  • La section BI Engine permet d'ouvrir la page BigQuery BI Engine.

BigQuery dispose également d'un outil de ligne de commande basé sur Python. Pour en savoir plus, consultez la section Utiliser l'outil de ligne de commande bq.

Sécurité

Lors de la migration de Snowflake vers BigQuery, vous devez tenir compte de la manière dont Google Cloud en général, et BigQuery en particulier, gère la sécurité différemment de Snowflake.

Snowflake présente diverses fonctionnalités liées à la sécurité, par exemple :

  • Accès au réseau et au site
  • Authentification du compte et de l'utilisateur
  • Sécurité des objets
  • Sécurité des données
  • Validations de la sécurité

La sécurité de Snowflake est basée sur les fonctionnalités de votre fournisseur cloud. Elle fournit un contrôle précis sur l'accès aux objets, sur les opérations d'objets, et sur les utilisateurs autorisés à créer ou à modifier les stratégies de contrôle d'accès.

Les droits de BigQuery fonctionnant en parallèle du contrôle d'accès de Snowflake sont les rôles IAM (Identity and Access Management) dans Google Cloud. Ces droits déterminent les opérations autorisées sur une ressource. Les droits sont appliqués au niveau de Google Cloud.

Chiffrement

Dans Snowflake, la sécurité au niveau des colonnes est compatible avec l'édition Enterprise, et les clés de chiffrement gérées par le client sont compatibles avec l'édition Business Critical. Ces éditions sont proposées à des tarifs différents. Dans BigQuery, toutes les fonctionnalités et mesures de sécurité renforcée sont proposées en tant que fonctionnalités standards, sans frais supplémentaires.

Snowflake fournit un chiffrement de bout en bout dans lequel toutes les données stockées sont automatiquement chiffrées. Google Cloud fournit la même fonctionnalité en chiffrant toutes les données au repos et en transit par défaut.

À l'image de l'édition Business Critical de Snowflake, BigQuery est compatible avec les clés de chiffrement gérées par le client, pour les utilisateurs qui souhaitent contrôler et gérer les clés de chiffrement de clés dans Cloud Key Management Service. BigQuery permet également le chiffrement au niveau des colonnes. Pour en savoir plus sur le chiffrement dans Google Cloud, consultez les pages Chiffrement au repos dans Google Cloud et Chiffrement en transit dans Google Cloud.

Rôles

Les rôles sont les entités pour lesquelles les droits sur les objets sécurisés peuvent être accordés et révoqués.

Snowflake accepte les deux types de rôles suivants:

  • Rôles définis par le système: ces rôles sont constitués de droits liés au système et à la sécurité, et sont créés avec des droits liés à la gestion des comptes.
  • Rôles personnalisés: vous pouvez créer ces rôles à l'aide des rôles SECURITYADMIN ou en utilisant n'importe quel rôle disposant du droit CREATE ROLE. Chaque rôle personnalisé dans Snowflake est composé de droits.

Dans IAM, les autorisations sont regroupées dans des rôles. IAM propose trois types de rôles :

  • Rôles de base : ces rôles incluent les rôles "Propriétaire", "Éditeur" et "Lecteur". Vous pouvez appliquer ces rôles au niveau des ressources du projet ou du service à l'aide de la console Google Cloud, de l'API Identity and Access Management ou de gcloud CLI. En règle générale, pour renforcer la sécurité, nous recommandons d'utiliser les rôles spécifiques à BigQuery afin de respecter le principe du moindre privilège.
  • Rôles prédéfinis : ces rôles fournissent un accès plus précis aux fonctionnalités d'un produit (tel que BigQuery). Ils sont conçus pour des cas d'utilisation courants et des modèles de contrôle des accès.
  • Rôles personnalisés: ces rôles sont composés d'autorisations spécifiées par l'utilisateur.

Contrôle des accès

Snowflake vous permet d'attribuer des rôles à d'autres rôles, créant ainsi une hiérarchie de rôles. IAM n'est pas compatible avec une hiérarchie de rôles, mais met en œuvre une hiérarchie de ressources. La hiérarchie IAM inclut les niveaux de l'organisation, du dossier, du projet et des ressources. Vous pouvez définir des rôles IAM à n'importe quel niveau de la hiérarchie. Les ressources héritent de toutes les stratégies de leurs ressources parentes.

Snowflake et BigQuery sont tous deux compatibles avec le contrôle des accès au niveau de la table. Les autorisations au niveau de la table déterminent les utilisateurs, les groupes et les comptes de service autorisés à accéder à une table ou à une vue. Vous pouvez autoriser un utilisateur à accéder à des tables ou des vues spécifiques, sans lui accorder l'accès à l'ensemble de données entier.

Snowflake utilise également la sécurité au niveau des lignes et la sécurité au niveau des colonnes.

Dans BigQuery, IAM fournit un contrôle des accès au niveau de la table. Pour un accès plus précis, vous pouvez également utiliser le contrôle des accès au niveau des colonnes ou la sécurité au niveau des lignes. Ce type de contrôle fournit un accès précis aux colonnes sensibles à l'aide de tags avec stratégie ou de classifications de données basées sur le type.

Vous pouvez également créer des vues autorisées afin de limiter l'accès aux données et ainsi d'appliquer un contrôle d'accès plus précis. Cela permet aux utilisateurs spécifiés d'interroger une vue sans avoir accès en lecture aux tables sous-jacentes.

Éléments à prendre en compte lors de la migration

Certaines fonctionnalités de Snowflake ne peuvent pas être transférées directement vers BigQuery. Par exemple, BigQuery n'offre pas de compatibilité intégrée pour les scénarios suivants. Dans ces scénarios, vous devrez peut-être utiliser d'autres services dans Google Cloud.

  • Fonctionnalité temporelle : dans BigQuery, vous pouvez utiliser les fonctionnalités temporelles pour accéder aux données à partir de n'importe quel moment au cours des sept derniers jours. Si vous devez accéder à des données pendant une période plus longue, envisagez d'exporter des instantanés programmés régulièrement. Snowflake vous permet d'accéder aux données historiques (données modifiées ou supprimées) à tout moment au cours d'une période définie. Vous pouvez définir cette période entre 0 et 90 jours.

  • Flux : BigQuery accepte la capture de données modifiées (CDC, Change Data Capture) avec Datastream. Vous pouvez également utiliser des logiciels de CDC, tels que Debezium, pour écrire des enregistrements dans BigQuery à l'aide de Dataflow. Pour en savoir plus sur la conception manuelle d'un pipeline CDC avec BigQuery, consultez la section Migrer des entrepôts de données vers BigQuery : capture de données modifiées (CDC). Dans Snowflake, un objet de flux enregistre les modifications, en langage de manipulation de données, apportées aux tables ainsi que des métadonnées sur chaque modification afin que vous puissiez effectuer des actions sur les données modifiées.

  • Tâches : BigQuery vous permet de planifier des requêtes et des flux, ou de les intégrer dans des requêtes avec Datastream. Snowflake peut combiner des tâches avec des flux de table pour effectuer des extractions, des chargements et des transferts de workflows continus afin de traiter les lignes de table récemment modifiées.

  • Fonctions externes : BigQuery accepte les appels de fonction externes via Cloud Functions. Cependant, vous pouvez utiliser des fonctions définies par l'utilisateur (UDF), telles que les UDF SQL, bien que ces fonctions ne soient pas exécutées en dehors de BigQuery. Dans Snowflake, une fonction externe appelle du code qui s'exécute en dehors de Snowflake. Par exemple, les informations envoyées à un service distant sont généralement transmises via un service proxy.

Migrer les données depuis Snowflake vers BigQuery

Cette section explique comment configurer et lancer votre migration de Snowflake vers BigQuery en fonction du framework décrit dans la section Migrer des entrepôts de données vers BigQuery : aue faut-il migrer et comment procéder.

Architecture

Pour commencer la migration, vous devez exécuter Snowflake et BigQuery. Le schéma suivant illustre une architecture qui minimise l'impact sur les opérations existantes. En transférant des données nettoyées et dont la qualité est contrôlée, vous pouvez réutiliser les outils et processus existants tout en déchargeant les charges de travail vers BigQuery. Vous pouvez également valider les rapports et les tableaux de bord par rapport aux anciennes versions. Néanmoins, comme les données OLAP sont conservées dans des emplacements redondants, cette opération n'est pas la plus économique. Elle prolonge également la durée du traitement.

  • Le point 1 illustre le transfert de données depuis Snowflake vers Cloud Storage.
  • Le point 2 illustre la persistance des données sur BigQuery.
  • Le point 3 illustre comment les données sont envoyées à l'utilisateur final.

Vous pouvez valider les rapports et les tableaux de bord par rapport aux itérations passées. Pour en savoir plus, consultez la page Migrer des entrepôts de données vers BigQuery : Vérifier et valider.

Migration continue depuis Snowflake vers BigQuery

L'architecture finale de la migration de votre entrepôt de données contient toutes les données des systèmes sources directement conservées dans Google Cloud. En fonction du nombre et de la complexité des systèmes sources, la mise en place de cette architecture peut être abordée en plusieurs étapes, en se consacrant aux systèmes sources les uns après les autres en fonction des priorités, des interdépendances, des risques d'intégration ou d'autres facteurs commerciaux.

Le schéma suivant suppose la migration des pipelines de données et l'ingestion vers Google Cloud.

  • Le point 1 illustre les points d'intégration synchrones et asynchrones. L'intégration synchrone se fait, par exemple, entre des sources de données et App Engine lors du traitement de cas d'utilisation nécessitant des actions utilisateur explicites au sein du flux.
  • Le point 2 illustre l'utilisation de Pub/Sub pour de grands volumes de données d'événements simultanés.
  • Le point 3 illustre la persistance des données à l'aide d'un ou plusieurs produits Google Cloud, en fonction de la nature des données.
  • Le point 4 illustre le processus d'extraction, de transformation et de chargement (ETL, Extract-Transform Load) vers BigQuery.

Après la migration de Snowflake vers BigQuery

Préparer votre environnement Cloud Storage

Google Cloud propose plusieurs façons de transférer vos données vers BigQuery à l'aide d'autres outils ETL. Le procédé est le suivant :

  1. Extraire les données de votre source : copiez les fichiers extraits de votre source vers un stockage de préproduction dans votre environnement sur site. Pour en savoir plus, consultez la section Migrer des entrepôts de données vers BigQuery : extraire les données sources.

  2. Transférer des données vers un bucket Cloud Storage de préproduction : une fois l'extraction des données de votre source terminée, vous les transférez vers un bucket temporaire dans Cloud Storage. Selon la quantité de données transférées et la bande passante réseau disponible, vous avez le choix entre plusieurs options.

    Il est important de vérifier que l'emplacement de votre ensemble de données BigQuery et celui de votre source de données externe, ou de votre bucket Cloud Storage, se trouvent dans la même région. Pour en savoir plus sur les considérations d'emplacement géographique pour le chargement de données à partir de Cloud Storage, consultez la section Charger des données par lot.

  3. Charger les données du bucket Cloud Storage dans BigQuery : vos données se trouvent désormais dans un bucket Cloud Storage, plus près de leur destination. Plusieurs options permettent d'importer les données dans BigQuery. Ces options dépendent du degré de transformation nécessaire sur les données. Vous pouvez également transformer vos données dans BigQuery en suivant l'approche ETL.

    Lorsque vous importez vos données de manière groupée à partir d'un fichier JSON, Avro ou CSV, BigQuery détecte automatiquement le schéma. Vous n'avez donc pas besoin de le prédéfinir. Pour obtenir une présentation détaillée du processus de migration de schéma pour les charges de travail d'entreposage de données, consultez la page Processus de migration du schéma et des données.

Types de données, de propriétés et de formats de fichiers compatibles

Snowflake et BigQuery sont compatibles avec la plupart des mêmes types de données, bien qu'ils utilisent parfois des noms différents. Pour obtenir la liste complète des types de données compatibles avec Snowflake et BigQuery, consultez la section Types de données de la documentation de référence sur la traduction SQL de Snowflake. Vous pouvez également utiliser le traducteur SQL par lot pour effectuer la traduction. Pour plus d'informations sur les types de données compatibles avec BigQuery, consultez la section Types de données GoogleSQL.

Snowflake peut exporter des données aux formats suivants : Vous pouvez charger les formats directement dans BigQuery :

Modifications du schéma

Si vous prévoyez de modifier le schéma dans votre migration vers BigQuery, nous vous recommandons de commencer par migrer votre schéma tel quel. BigQuery est compatible avec un large éventail de modèles de conception de modèles de données, tels que schéma en étoile ou en tant que schéma en flocon de neige. Du fait de cette compatibilité, vous n'avez pas besoin de mettre à jour vos pipelines de données en amont pour un nouveau schéma, et vous pouvez utiliser des outils de migration automatisés pour transférer vos données et votre schéma.

Mettre à jour un schéma

Une fois que vos données sont dans BigQuery, vous pouvez toujours mettre à jour le schéma, par exemple en ajoutant des colonnes à la définition du schéma ou en assouplissant le mode d'une colonne en le passant de REQUIRED à NULLABLE.

N'oubliez pas que BigQuery utilise des conventions d'attribution de noms sensibles à la casse pour le nom de la table, tandis que Snowflake utilise des modèles d'attribution de noms non sensibles à la casse. Cette convention signifie que vous devrez peut-être vérifier toute incohérence dans les conventions d'attribution des noms de table pouvant exister dans Snowflake et corriger les incohérences survenues lors du passage à BigQuery. Pour plus d'informations sur la modification de schéma, consultez l'article Modifier des schémas de table.

Certaines modifications de schéma ne sont pas directement compatibles avec BigQuery et nécessitent des solutions alternatives à effectuer manuellement, parmi lesquelles :

  • Renommer une colonne
  • Modifier le type de données d'une colonne
  • Modifier le mode d'une colonne (sauf pour assouplir une colonne du mode REQUIRED vers le mode NULLABLE)

Pour obtenir des instructions spécifiques sur la mise en œuvre manuelle de ces modifications de schéma, consultez la section Modifier manuellement des schémas de table.

Optimisation

Après la migration du schéma, vous pouvez tester les performances et effectuer des optimisations en fonction des résultats. Par exemple, vous pouvez introduire le partitionnement pour améliorer la gestion et l'interrogation de vos données. Le partitionnement dans BigQuery désigne une table spéciale divisée en segments appelés partitions. Le partitionnement est différent du micro-partitionnement de Snowflake, qui se produit automatiquement lors du chargement des données. Le partitionnement de BigQuery vous permet d'améliorer les performances des requêtes et de contrôler les coûts en effectuant un partitionnement par temps d'ingestion, horodatage ou plage d'entiers. Pour plus d'informations, consultez la page Présentation des tables partitionnées.

Tables en cluster

Les tables en cluster constituent une autre optimisation de schéma. BigQuery, comme Snowflake, vous permet de mettre des clusters en cluster, ce qui vous permet d'organiser automatiquement les données de table en fonction du contenu d'une ou plusieurs colonnes du schéma de la table. BigQuery utilise les colonnes que vous spécifiez pour rapprocher les données associées. Le clustering peut améliorer les performances de certains types de requêtes, telles que les requêtes utilisant des clauses de filtre ou celles agrégeant des données. Pour en savoir plus sur le fonctionnement des tables en cluster dans BigQuery, consultez la page Présentation des tables en cluster.

Outils de migration

La liste suivante décrit les outils que vous pouvez utiliser pour migrer des données depuis Snowflake vers BigQuery. Ces outils sont combinés dans la section Exemples de migration à l'aide de pipelines afin de regrouper les pipelines de migration de bout en bout.

  • Commande COPY INTO <location> : utilisez cette commande dans Snowflake pour décharger les données d'une table Snowflake directement dans un bucket Cloud Storage spécifié. Pour obtenir un exemple de bout en bout, consultez la page Snowflake vers BigQuery (snowflake2bq) sur GitHub.
  • Apache Sqoop : pour extraire les données de Snowflake dans HDFS ou Cloud Storage, envoyez des tâches Hadoop avec le pilote JDBC de Sqoop et de Snowflake. Sqoop s'exécute dans un environnement Dataproc.
  • Pilote JDBC de Snowflake : utilisez ce pilote avec la plupart des outils clients ou des applications compatibles avec JDBC.

Vous pouvez utiliser les outils génériques suivants pour migrer des données depuis Snowflake vers BigQuery :

  • Service de transfert de données BigQuery : effectuez un transfert par lot automatisé de données Cloud Storage vers BigQuery à l'aide de ce service entièrement géré. Cet outil nécessite d'exporter les données Snowflake vers Cloud Storage.
  • gsutil: copiez les fichiers Snowflake téléchargés dans Cloud Storage à l'aide de cet outil de ligne de commande.
  • Outil de ligne de commande bq : interagissez avec BigQuery à l'aide de cet outil de ligne de commande. Les cas d'utilisation courants incluent la création de schémas de table BigQuery, le chargement de données Cloud Storage dans des tables et l'exécution de requêtes.
  • Bibliothèques clientes Cloud Storage: copiez les fichiers Snowflake téléchargés dans Cloud Storage à l'aide d'un outil personnalisé qui utilise les bibliothèques clientes Cloud Storage.
  • Bibliothèques clientes BigQuery: interagissez avec BigQuery à l'aide d'un outil personnalisé basé sur la bibliothèque cliente BigQuery.
  • Programmeur de requêtes BigQuery: programmez des requêtes SQL récurrentes grâce à cette fonctionnalité BigQuery intégrée.
  • Cloud Composer: utilisez cet environnement entièrement géré Apache Airflow pour orchestrer des tâches de chargement et des transformations BigQuery.

Pour en savoir plus sur le chargement des données dans BigQuery, consultez la page Charger des données dans BigQuery.

Exemples de migration à l'aide de pipelines

Les sections suivantes présentent des exemples de migration de données depuis Snowflake vers BigQuery à l'aide de trois techniques différentes : la technique d'extraction et de chargement, l'approche ETL et l'utilisation d'outils partenaires.

Extraction et chargement

La technique d'extraction et de chargement propose deux méthodes :

  • Utiliser un pipeline pour décharger des données depuis Snowflake
  • Utiliser un pipeline et un pilote JDBC pour exporter des données depuis Snowflake

Utiliser un pipeline pour décharger des données depuis Snowflake

Pour décharger des données de Snowflake directement dans Cloud Storage (recommandé), ou pour télécharger des données et les copier dans Cloud Storage à l'aide de gsutil ou des bibliothèques clientes Cloud Storage, utilisez l'outil snowflake2bq pour migrer les données à l'aide de la commande Snowflake COPY INTO <location>.

Ensuite, chargez les données Cloud Storage dans BigQuery à l'aide de l'un des outils suivants :

  • Service de transfert de données BigQuery
  • Outil de ligne de commande bq
  • Bibliothèques clientes de l'API BigQuery

Utiliser un pipeline et un pilote JDBC pour exporter des données depuis Snowflake

Utilisez l'un des produits suivants pour exporter les données Snowflake avec le pilote JDBC de Snowflake :

Extraction, transformation et chargement

Si vous souhaitez transformer vos données avant de les charger dans BigQuery, vous pouvez ajouter une étape de transformation dans les pipelines décrits dans la section précédente, Extraction et chargement.

Transformer les données Snowflake

Pour transformer vos données avant de les charger dans BigQuery, déchargez-les directement depuis Snowflake vers Cloud Storage ou utilisez gsutil pour copier des données, comme décrit dans la section précédente, Extraction et chargement.

Charger des données Snowflake

Après avoir transformé vos données, chargez-les dans BigQuery à l'aide de l'une des méthodes suivantes :

Utiliser un pipeline et un pilote JDBC pour transformer et exporter des données depuis Snowflake

Ajoutez une étape de transformation dans les options de pipeline suivantes, comme décrit dans la section précédente, Extraction et chargement.

Vous pouvez avoir un cas d'utilisation d'extraction, chargement et transformation visant à charger vos données de Snowflake dans BigQuery, puis à les transformer. Pour effectuer cette tâche, chargez les données depuis Snowflake vers une table de préproduction BigQuery, en appliquant l'une des méthodes de la section précédente, Extraction et chargement. Exécutez ensuite des requêtes SQL sur la table de production, et écrivez le résultat dans la table de production finale dans BigQuery.

Outils partenaires pour la migration

Plusieurs fournisseurs sont spécialisés dans l'espace de migration d'entrepôt de données d'entreprise. Pour obtenir la liste des partenaires clés et des solutions qu'ils proposent, consultez le site Web du partenaire BigQuery de Google Cloud.

Exemples de processus d'exportation

Les sections suivantes présentent un exemple d'exportation de données depuis Snowflake vers BigQuery utilisant la commande COPY INTO <location> de Snowflake. Pour obtenir un processus détaillé avec des exemples de code, consultez la section Services professionnels Snowflake de Google Cloud vers l'outil BigQuery.

Préparer l'exportation

Pour le déchargement, utilisez les instructions SQL Snowflake afin de créer une spécification de format de fichier nommé.

Ce tutoriel utilise my_parquet_unload_format pour le format de fichier, mais vous pouvez utiliser un nom différent.

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

Exporter vos données Snowflake

Une fois vos données préparées, vous devez les déplacer vers Google Cloud. Vous pouvez effectuer cette étape de l'une des deux manières suivantes :

  1. Exporter vos données directement vers Cloud Storage à partir de Snowflake
  2. Préproduire vos données Snowflake dans un bucket Amazon Simple Storage Service (Amazon S3) ou Azure Blob Storage

Pour éviter un saut de données supplémentaire, exportez directement vos données.

Exporter les données Snowflake directement vers Cloud Storage

Les instructions suivantes montrent comment utiliser la commande COPY Snowflake pour décharger les données de Snowflake dans Cloud Storage :

  1. Dans Snowflake, configurez un objet d'intégration de stockage pour permettre à Snowflake d'écrire dans un bucket Cloud Storage référencé lors d'une étape Cloud Storage externe.

    Cette étape implique plusieurs sous-étapes.

    1. Créez une intégration avec la commande CREATE STORAGE INTEGRATION :

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

    2. Récupérez le compte de service Cloud Storage associé à Snowflake avec la commande DESCRIBE INTEGRATION, puis accordez-lui des autorisations d'accès au bucket Cloud Storage sélectionné comme zone intermédiaire:

      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. Créez une étape Cloud Storage externe faisant référence à l'intégration que vous avez créée à l'aide de la commande CREATE STAGE :

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

  2. Utilisez la commande COPY INTO <location> pour copier les données de la table de base de données Snowflake dans un bucket Cloud Storage en spécifiant l'objet de l'étape externe que vous avez créé à l'étape précédente :

    copy into @my_ext_unload_stage/d1
from mytable;

Exporter les données Snowflake vers Cloud Storage via le service de transfert de stockage depuis Amazon S3

L'exemple suivant montre comment décharger des données d'une table Snowflake vers un bucket Amazon S3 à l'aide de la commande COPY :

  1. Dans Snowflake, configurez un objet d'intégration de stockage pour permettre à Snowflake d'écrire dans un bucket Amazon S3 référencé lors d'une étape Cloud Storage externe.

    Cette étape implique de configurer les autorisations d'accès au bucket Amazon S3, créer le rôle IAM AWS et créer une intégration de stockage dans Snowflake avec la commande 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. Récupérez l'utilisateur IAM AWS à l'aide de la commande DESCRIBE INTEGRATION:

    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. Accordez à l'utilisateur IAM AWS les autorisations pour accéder au bucket Amazon S3 et créez une étape externe à l'aide de la commande 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. Utilisez la commande COPY INTO <location> pour copier les données de la base de données Snowflake dans le bucket Amazon S3 en spécifiant l'objet de l'étape externe que vous avez créé précédemment :

      copy into @my_ext_unload_stage/d1 from mytable;

  5. Transférez les fichiers exportés vers Cloud Storage à l'aide du service de transfert de stockage.

Exporter les données Snowflake vers Cloud Storage via d'autres fournisseurs cloud :

Azure Blob Storage : Suivez les étapes décrites dans la section Déchargement vers Microsoft Azure. Transférez ensuite les fichiers exportés vers Cloud Storage à l'aide du service de transfert de stockage.

Bucket Amazon S3 : suivez les étapes détaillées dans la section Déchargement vers Amazon S3. Transférez ensuite les fichiers exportés vers Cloud Storage à l'aide du service de transfert de stockage.

Étapes suivantes