Planifier un transfert Snowflake

Le connecteur Snowflake fourni par le service de transfert de données BigQuery vous permet de planifier et de gérer des tâches de transfert automatisées pour migrer des données de Snowflake vers BigQuery à l'aide de listes d'adresses IP publiques autorisées.

Présentation

Le connecteur Snowflake engage les agents de migration dans Google Kubernetes Engine et déclenche une opération de chargement depuis Snowflake vers une zone de préproduction au sein du même fournisseur de cloud que celui où Snowflake est hébergé.

  • Pour les comptes Snowflake hébergés sur AWS, les données sont d'abord préparées dans votre bucket Amazon S3, puis transférées vers BigQuery avec le service de transfert de données BigQuery.
  • Pour les comptes Snowflake hébergés surGoogle Cloud, les données sont d'abord stockées dans votre bucket Cloud Storage, puis transférées vers BigQuery avec le service de transfert de données BigQuery.
  • Pour les comptes Snowflake hébergés sur Azure, les données sont d'abord préparées dans votre conteneur Azure Blob Storage, puis transférées vers BigQuery avec le service de transfert de données BigQuery.

Limites

Les transferts de données effectués à l'aide du connecteur Snowflake sont soumis aux limitations suivantes :

  • Le connecteur Snowflake n'accepte que les transferts depuis des tables d'une même base de données et d'un même schéma Snowflake. Pour transférer des données depuis des tables comportant plusieurs bases de données ou schémas Snowflake, vous pouvez configurer chaque job de transfert séparément.
  • La vitesse de chargement des données de Snowflake vers votre bucket Amazon S3, votre conteneur Azure Blob Storage ou votre bucket Cloud Storage est limitée par l'entrepôt de données Snowflake que vous avez choisi pour ce transfert.

Limites des transferts incrémentiels

Les transferts Snowflake incrémentiels sont soumis aux limitations suivantes :

  • Vous devez fournir des colonnes de clé primaire pour utiliser le mode écriture "upsert". Pour en savoir plus, consultez Définir des clés primaires pour les transferts incrémentiels.
  • Les clés primaires doivent être uniques dans la table source. S'il existe des doublons, les résultats de l'opération de fusion dans BigQuery peuvent être incohérents et ne pas correspondre aux données sources.
  • La gestion automatique des modifications de schéma avec les transferts incrémentaux n'est pas disponible. Si le schéma d'une table source change, vous devez mettre à jour manuellement le schéma de la table BigQuery.
  • Les transferts incrémentiels fonctionnent mieux lorsque les modifications apportées à vos données sources sont concentrées dans un petit nombre de partitions. Les performances de transfert incrémentiel peuvent se dégrader de manière significative si les mises à jour sont dispersées dans la table source, car cela nécessite d'analyser de nombreuses partitions. Si de nombreuses lignes sont modifiées entre les transferts de données, nous vous recommandons d'utiliser plutôt un transfert complet.
  • Certaines opérations dans Snowflake, telles que CREATE OR REPLACE TABLE ou CLONE, peuvent écraser l'objet de table d'origine et son historique de suivi des modifications associé. Les transferts de données existants deviennent obsolètes et une nouvelle synchronisation complète est nécessaire pour reprendre les transferts incrémentiels.
  • Les transferts incrémentaux doivent être exécutés assez souvent pour respecter la période de conservation des données de Snowflake pour le suivi des modifications. Si le dernier transfert réussi a été exécuté en dehors de cette période, le prochain transfert sera un transfert complet.

Comportement d'ingestion des données

Vous pouvez spécifier la façon dont les données sont chargées dans BigQuery en sélectionnant la préférence d'écriture Complète ou Incrémentielle dans la configuration du transfert lorsque vous configurez un transfert Snowflake. Les transferts incrémentiels sont disponibles en version preview.

Vous pouvez sélectionner Complet pour transférer toutes les données de vos ensembles de données Snowflake à chaque transfert de données.

Vous pouvez également sélectionner Incrémentiel (Aperçu) pour ne transférer que les données qui ont été modifiées depuis le dernier transfert de données, au lieu de charger l'intégralité de l'ensemble de données à chaque transfert. Si vous sélectionnez Incrémentiel pour votre transfert de données, vous devez spécifier les modes d'écriture Ajouter ou Upsert pour définir la façon dont les données sont écrites dans BigQuery lors d'un transfert de données incrémentiel. Les sections suivantes décrivent les modes d'écriture disponibles.

Mode d'écriture Append

Le mode d'écriture Ajouter n'insère que de nouvelles lignes dans votre table de destination. Cette option ajoute strictement les données transférées sans vérifier s'il existe des enregistrements, ce qui peut entraîner une duplication des données dans la table de destination.

Lorsque vous sélectionnez le mode Ajouter, vous devez sélectionner une colonne de filigrane. Une colonne de filigrane est requise pour que le connecteur Snowflake puisse suivre les modifications apportées à la table source.

Mode d'écriture Upsert

Le mode d'écriture Upsert met à jour une ligne ou en insère une nouvelle dans votre table de destination en vérifiant la présence d'une clé primaire. Vous pouvez spécifier une clé primaire pour permettre au connecteur Snowflake de déterminer les modifications nécessaires pour que votre table de destination reste à jour par rapport à votre table source. Si la clé primaire spécifiée est présente dans la table BigQuery de destination lors d'un transfert de données, le connecteur Snowflake met à jour cette ligne avec les nouvelles données de la table source. Si aucune clé primaire n'est présente lors d'un transfert de données, le connecteur Snowflake insère une nouvelle ligne.

Lorsque vous sélectionnez le mode Upsert, vous devez sélectionner une colonne de filigrane et une clé primaire :

  • La clé primaire peut être une ou plusieurs colonnes de votre table. Elle est nécessaire pour que le connecteur Snowflake puisse déterminer s'il doit insérer ou mettre à jour une ligne.
    • Sélectionnez les colonnes contenant des valeurs non nulles uniques pour toutes les lignes du tableau. Nous vous recommandons d'utiliser des colonnes qui incluent des identifiants générés par le système, des codes de référence uniques (par exemple, des ID à incrémentation automatique) ou des ID de séquence immuables basés sur le temps.
    • Pour éviter toute perte ou corruption de données, les colonnes de clé primaire que vous sélectionnez doivent contenir des valeurs uniques. Si vous avez des doutes sur l'unicité de la colonne de clé primaire que vous avez choisie, nous vous recommandons d'utiliser le mode d'écriture Ajouter à la place.

Pour utiliser le mode d'écriture "upsert" avec votre transfert de données incrémentiel, vous devez définir des clés primaires dans votre fichier de schéma personnalisé.

Avant de commencer

Avant de configurer un transfert Snowflake, vous devez effectuer toutes les étapes listées dans cette section. Vous trouverez ci-dessous la liste de toutes les étapes requises.

  1. Préparer votre projet Google Cloud
  2. Rôles BigQuery requis
  3. Préparer votre bucket de préproduction
  4. Créer un utilisateur Snowflake avec les autorisations requises
  5. Ajouter des règles de réseau
  6. Facultatif : Détection et mappage du schéma
  7. Évaluer votre instance Snowflake pour identifier les types de données non compatibles
  8. Facultatif : activer les transferts incrémentiels
  9. Recueillir les informations de transfert
  10. Si vous envisagez de spécifier une clé de chiffrement gérée par le client (CMEK), assurez-vous que votre compte de service est autorisé à procéder au chiffrement et au déchiffrement, et que vous disposez de l'ID de ressource de la clé Cloud KMS requis pour utiliser des clés CMEK. Pour en savoir plus sur le fonctionnement des clés CMEK avec les transferts, consultez Spécifier une clé de chiffrement avec les transferts.

Préparer votre projet Google Cloud

Créez et configurez votre projet Google Cloud pour un transfert Snowflake en procédant comme suit :

  1. Créez un projet Google Cloud ou sélectionnez-en un.

  2. Vérifiez que vous avez effectué toutes les actions requises pour activer le service de transfert de données BigQuery.

  3. Créez un ensemble de données BigQuery pour stocker vos données. Vous n'avez pas besoin de créer de tables.

Rôles BigQuery requis

Pour obtenir les autorisations nécessaires pour créer un transfert de données Service de transfert de données BigQuery, demandez à votre administrateur de vous accorder le rôle IAM Administrateur BigQuery (roles/bigquery.admin) sur votre projet. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ce rôle prédéfini contient les autorisations requises pour créer un transfert de données du service de transfert de données BigQuery. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour créer un transfert de données du service de transfert de données BigQuery :

  • Autorisations du service de transfert de données BigQuery :
    • bigquery.transfers.update
    • bigquery.transfers.get
  • Autorisations BigQuery :
    • bigquery.datasets.get
    • bigquery.datasets.getIamPolicy
    • bigquery.datasets.update
    • bigquery.datasets.setIamPolicy
    • bigquery.jobs.create

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Pour en savoir plus, consultez Accorder l'accès bigquery.admin.

Préparer le bucket de préproduction

Pour effectuer un transfert de données Snowflake, vous devez créer un bucket intermédiaire, puis le configurer pour autoriser l'accès en écriture depuis Snowflake.

Bucket intermédiaire pour le compte Snowflake hébergé par AWS

Pour un compte Snowflake hébergé sur AWS, créez un bucket Amazon S3 pour préparer les données Snowflake avant de les charger dans BigQuery.

  1. Créez un bucket Amazon S3.

  2. Créez et configurez un objet d'intégration de stockage Snowflake pour permettre à Snowflake d'écrire des données dans le bucket Amazon S3 en tant qu'étape externe.

Pour autoriser l'accès en lecture à votre bucket Amazon S3, vous devez également procéder comme suit :

  1. Créez un utilisateur IAM Amazon dédié et accordez-lui la règle AmazonS3ReadOnlyAccess.

  2. Créez une paire de clés d'accès Amazon pour l'utilisateur IAM.

Conteneur Azure Blob Storage intermédiaire pour le compte Snowflake hébergé sur Azure

Pour les comptes Snowflake hébergés sur Azure, créez un conteneur Azure Blob Storage pour préparer les données Snowflake avant de les charger dans BigQuery.

  1. Créez un compte de stockage Azure et un conteneur de stockage dans ce compte.
  2. Créez et configurez un objet d'intégration de stockage Snowflake pour permettre à Snowflake d'écrire des données dans le conteneur de stockage Azure en tant qu'étape externe. Notez que vous pouvez ignorer l'étape 3 "Créer un stage externe", car nous ne l'utilisons pas.

Pour autoriser l'accès en lecture à votre conteneur Azure, générez un jeton SAP pour celui-ci.

Bucket intermédiaire pour le compte Snowflake hébergé sur Google Cloud

Pour les comptes Snowflake hébergés sur Google Cloud, créez un bucket Cloud Storage pour préproduire les données Snowflake avant de les charger dans BigQuery.

  1. Créez un bucket Cloud Storage.
  2. Créez et configurez un objet d'intégration de stockage Snowflake pour permettre à Snowflake d'écrire des données dans le bucket Cloud Storage en tant qu'étape externe.

  3. Pour autoriser l'accès au bucket intermédiaire, accordez le rôle roles/storage.objectViewer à l'agent de service DTS à l'aide de la commande suivante :

    gcloud storage buckets add-iam-policy-binding gs://STAGING_BUCKET_NAME \
  --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

Créer un utilisateur Snowflake avec les autorisations requises

Lors d'un transfert Snowflake, le connecteur Snowflake se connecte à votre compte Snowflake à l'aide d'une connexion JDBC. Vous devez créer un utilisateur Snowflake avec un rôle personnalisé qui ne dispose que des droits nécessaires pour effectuer le transfert de données :

  // Create and configure new role, MIGRATION_ROLE
  GRANT USAGE
    ON WAREHOUSE WAREHOUSE_NAME
    TO ROLE MIGRATION_ROLE;

  GRANT USAGE
    ON DATABASE DATABASE_NAME
    TO ROLE MIGRATION_ROLE;

  GRANT USAGE
    ON SCHEMA DATABASE_NAME.SCHEMA_NAME
    TO ROLE MIGRATION_ROLE;

  // You can modify this to give select permissions for all tables in a schema
  GRANT SELECT
    ON TABLE DATABASE_NAME.SCHEMA_NAME.TABLE_NAME
    TO ROLE MIGRATION_ROLE;

  GRANT USAGE
    ON STORAGE_INTEGRATION_OBJECT_NAME
    TO ROLE MIGRATION_ROLE;

Remplacez les éléments suivants :

  • MIGRATION_ROLE : nom du rôle personnalisé que vous créez
  • WAREHOUSE_NAME : nom de votre entrepôt de données
  • DATABASE_NAME : nom de votre base de données Snowflake
  • SCHEMA_NAME : nom de votre schéma Snowflake
  • TABLE_NAME : nom de la base de données Snowflake incluse dans ce transfert de données.
  • STORAGE_INTEGRATION_OBJECT_NAME : nom de votre objet d'intégration de stockage Snowflake.

Générer une paire de clés pour l'authentification

Étant donné que Snowflake n'accepte plus les connexions avec mot de passe à un seul facteur, nous vous recommandons d'utiliser une paire de clés pour l'authentification.

Vous pouvez configurer une paire de clés en générant une paire de clés RSA chiffrée ou non chiffrée, puis en attribuant la clé publique à un utilisateur Snowflake. Pour en savoir plus, consultez Configurer l'authentification par paire de clés.

Ajouter des règles de réseau

Pour la connectivité publique, le compte Snowflake autorise par défaut la connexion publique avec les identifiants de la base de données. Toutefois, vous avez peut-être configuré des règles ou des stratégies réseau qui pourraient empêcher le connecteur Snowflake de se connecter à votre compte. Dans ce cas, vous devez ajouter les adresses IP nécessaires à votre liste d'autorisation.

Le tableau suivant liste les adresses IP des emplacements régionaux et multirégionaux utilisés pour les transferts publics. Vous pouvez ajouter les adresses IP qui correspondent uniquement à l'emplacement de votre ensemble de données ou toutes les adresses IP listées dans le tableau. Il s'agit d'adresses IP réservées par Google pour les transferts de données du service de transfert de données BigQuery.

Pour ajouter une adresse IP à une liste d'autorisation, procédez comme suit :

  1. Créez une règle de réseau avec type = IPV4. Le service de transfert de données BigQuery utilise une connexion JDBC pour se connecter au compte Snowflake.
  2. Créez une règle de réseau avec la règle de réseau que vous avez créée précédemment et l'adresse IP du tableau suivant.

Zones régionales

Description de la région Nom de la région Adresses IP
Amériques
Columbus, Ohio us-east5 34.162.72.184
34.162.173.185
34.162.205.205
34.162.81.45
34.162.182.149
34.162.59.92
34.162.157.190
34.162.191.145
Dallas us-south1 34.174.172.89
34.174.40.67
34.174.5.11
34.174.96.109
34.174.148.99
34.174.176.19
34.174.253.135
34.174.129.163
Iowa us-central1 34.121.70.114
34.71.81.17
34.122.223.84
34.121.145.212
35.232.1.105
35.202.145.227
35.226.82.216
35.225.241.102
Las Vegas us-west4 34.125.53.201
34.125.69.174
34.125.159.85
34.125.152.1
34.125.195.166
34.125.50.249
34.125.68.55
34.125.91.116
Los Angeles us-west2 35.236.59.167
34.94.132.139
34.94.207.21
34.94.81.187
34.94.88.122
35.235.101.187
34.94.238.66
34.94.195.77
Mexique northamerica-south1 34.51.6.35
34.51.7.113
34.51.12.83
34.51.10.94
34.51.11.219
34.51.11.52
34.51.2.114
34.51.15.251
Montréal northamerica-northeast1 34.95.20.253
35.203.31.219
34.95.22.233
34.95.27.99
35.203.12.23
35.203.39.46
35.203.116.49
35.203.104.223
Virginie du Nord us-east4 35.245.95.250
35.245.126.228
35.236.225.172
35.245.86.140
35.199.31.35
35.199.19.115
35.230.167.48
35.245.128.132
35.245.111.126
35.236.209.21
Oregon us-west1 35.197.117.207
35.199.178.12
35.197.86.233
34.82.155.140
35.247.28.48
35.247.31.246
35.247.106.13
34.105.85.54
Salt Lake City us-west3 34.106.37.58
34.106.85.113
34.106.28.153
34.106.64.121
34.106.246.131
34.106.56.150
34.106.41.31
34.106.182.92
São Paulo southamerica-east1 35.199.88.228
34.95.169.140
35.198.53.30
34.95.144.215
35.247.250.120
35.247.255.158
34.95.231.121
35.198.8.157
Santiago southamerica-west1 34.176.188.48
34.176.38.192
34.176.205.134
34.176.102.161
34.176.197.198
34.176.223.236
34.176.47.188
34.176.14.80
Caroline du Sud us-east1 35.196.207.183
35.237.231.98
104.196.102.222
35.231.13.201
34.75.129.215
34.75.127.9
35.229.36.137
35.237.91.139
Toronto northamerica-northeast2 34.124.116.108
34.124.116.107
34.124.116.102
34.124.116.80
34.124.116.72
34.124.116.85
34.124.116.20
34.124.116.68
Europe
Belgique europe-west1 35.240.36.149
35.205.171.56
34.76.234.4
35.205.38.234
34.77.237.73
35.195.107.238
35.195.52.87
34.76.102.189
Berlin europe-west10 34.32.28.80
34.32.31.206
34.32.19.49
34.32.33.71
34.32.15.174
34.32.23.7
34.32.1.208
34.32.8.3
Finlande europe-north1 35.228.35.94
35.228.183.156
35.228.211.18
35.228.146.84
35.228.103.114
35.228.53.184
35.228.203.85
35.228.183.138
Francfort europe-west3 35.246.153.144
35.198.80.78
35.246.181.106
35.246.211.135
34.89.165.108
35.198.68.187
35.242.223.6
34.89.137.180
Londres europe-west2 35.189.119.113
35.189.101.107
35.189.69.131
35.197.205.93
35.189.121.178
35.189.121.41
35.189.85.30
35.197.195.192
Madrid europe-southwest1 34.175.99.115
34.175.186.237
34.175.39.130
34.175.135.49
34.175.1.49
34.175.95.94
34.175.102.118
34.175.166.114
Milan europe-west8 34.154.183.149
34.154.40.104
34.154.59.51
34.154.86.2
34.154.182.20
34.154.127.144
34.154.201.251
34.154.0.104
Pays-Bas europe-west4 35.204.237.173
35.204.18.163
34.91.86.224
34.90.184.136
34.91.115.67
34.90.218.6
34.91.147.143
34.91.253.1
Paris europe-west9 34.163.76.229
34.163.153.68
34.155.181.30
34.155.85.234
34.155.230.192
34.155.175.220
34.163.68.177
34.163.157.151
Stockholm europe-north2 34.51.133.48
34.51.136.177
34.51.128.140
34.51.141.252
34.51.139.127
34.51.142.55
34.51.134.218
34.51.138.9
Turin europe-west12 34.17.15.186
34.17.44.123
34.17.41.160
34.17.47.82
34.17.43.109
34.17.38.236
34.17.34.223
34.17.16.47
Varsovie europe-central2 34.118.72.8
34.118.45.245
34.118.69.169
34.116.244.189
34.116.170.150
34.118.97.148
34.116.148.164
34.116.168.127
Zurich europe-west6 34.65.205.160
34.65.121.140
34.65.196.143
34.65.9.133
34.65.156.193
34.65.216.124
34.65.233.83
34.65.168.250
Asie-Pacifique
Bangkok asia-southeast3 34.15.142.80
34.15.131.78
34.15.141.141
34.15.143.6
34.15.142.166
34.15.138.0
34.15.135.129
34.15.139.45
Delhi asia-south2 34.126.212.96
34.126.212.85
34.126.208.224
34.126.212.94
34.126.208.226
34.126.212.232
34.126.212.93
34.126.212.206
Hong Kong asia-east2 34.92.245.180
35.241.116.105
35.220.240.216
35.220.188.244
34.92.196.78
34.92.165.209
35.220.193.228
34.96.153.178
Jakarta asia-southeast2 34.101.79.105
34.101.129.32
34.101.244.197
34.101.100.180
34.101.109.205
34.101.185.189
34.101.179.27
34.101.197.251
Melbourne australia-southeast2 34.126.196.95
34.126.196.106
34.126.196.126
34.126.196.96
34.126.196.112
34.126.196.99
34.126.196.76
34.126.196.68
Mumbai asia-south1 34.93.67.112
35.244.0.1
35.200.245.13
35.200.203.161
34.93.209.130
34.93.120.224
35.244.10.12
35.200.186.100
Osaka asia-northeast2 34.97.94.51
34.97.118.176
34.97.63.76
34.97.159.156
34.97.113.218
34.97.4.108
34.97.119.140
34.97.30.191
Séoul asia-northeast3 34.64.152.215
34.64.140.241
34.64.133.199
34.64.174.192
34.64.145.219
34.64.136.56
34.64.247.158
34.64.135.220
Singapour asia-southeast1 34.87.12.235
34.87.63.5
34.87.91.51
35.198.197.191
35.240.253.175
35.247.165.193
35.247.181.82
35.247.189.103
Sydney australia-southeast1 35.189.33.150
35.189.38.5
35.189.29.88
35.189.22.179
35.189.20.163
35.189.29.83
35.189.31.141
35.189.14.219
Taïwan asia-east1 35.221.201.20
35.194.177.253
34.80.17.79
34.80.178.20
34.80.174.198
35.201.132.11
35.201.223.177
35.229.251.28
35.185.155.147
35.194.232.172
Tokyo asia-northeast1 34.85.11.246
34.85.30.58
34.85.8.125
34.85.38.59
34.85.31.67
34.85.36.143
34.85.32.222
34.85.18.128
34.85.23.202
34.85.35.192
Moyen-Orient
Dammam me-central2 34.166.20.177
34.166.10.104
34.166.21.128
34.166.19.184
34.166.20.83
34.166.18.138
34.166.18.48
34.166.23.171
Doha me-central1 34.18.48.121
34.18.25.208
34.18.38.183
34.18.33.25
34.18.21.203
34.18.21.80
34.18.36.126
34.18.23.252
Tel Aviv me-west1 34.165.184.115
34.165.110.74
34.165.174.16
34.165.28.235
34.165.170.172
34.165.187.98
34.165.85.64
34.165.245.97
Afrique
Johannesburg africa-south1 34.35.11.24
34.35.10.66
34.35.8.32
34.35.3.248
34.35.2.113
34.35.5.61
34.35.7.53
34.35.3.17

Zones multirégionales

Description de la zone multirégionale Nom de la zone multirégionale Adresses IP
Centres de données dans les États membres de l'Union européenne1 EU 34.76.156.158
34.76.156.172
34.76.136.146
34.76.1.29
34.76.156.232
34.76.156.81
34.76.156.246
34.76.102.206
34.76.129.246
34.76.121.168
Centres de données aux États-Unis US 35.185.196.212
35.197.102.120
35.185.224.10
35.185.228.170
35.197.5.235
35.185.206.139
35.197.67.234
35.197.38.65
35.185.202.229
35.185.200.120

1 Les données situées dans la zone multirégionale EU ne sont pas stockées dans les centres de données des régions europe-west2 (Londres) ou europe-west6 (Zurich).

Détection et mappage de schémas

Pour définir votre schéma, vous pouvez utiliser le service de transfert de données BigQuery afin de détecter automatiquement le schéma et la mise en correspondance des types de données lorsque vous transférez des données de Snowflake vers BigQuery. Vous pouvez également utiliser le moteur de traduction pour définir manuellement votre schéma et vos types de données.

Fichier de schéma personnalisé

Vous pouvez utiliser un fichier de schéma personnalisé pour définir des clés primaires pour les transferts incrémentaux et pour personnaliser le mappage de schéma. Un fichier de schéma personnalisé est un fichier JSON qui décrit le schéma source et cible.

Définir des clés primaires pour les transferts incrémentaux

Pour les transferts incrémentiels en mode Upsert, vous devez identifier une ou plusieurs colonnes comme clés primaires. Pour ce faire, annotez les colonnes avec le type d'utilisation PRIMARY_KEY dans le fichier de schéma personnalisé.

L'exemple suivant montre un fichier de schéma personnalisé qui définit O_ORDERKEY et O_ORDERDATE comme clés primaires pour la table orders :


{
  "databases": [
    {
      "name": "my_db",
      "originalName": "my_db",
      "tables": [
        {
          "name": "orders",
          "originalName": "orders",
          "columns": [
            {
              "name": "O_ORDERKEY",
              "originalName": "O_ORDERKEY",
              "usageType": [
                "PRIMARY_KEY"
              ]
            },
            {
              "name": "O_ORDERDATE",
              "originalName": "O_ORDERDATE",
              "usageType": [
                "PRIMARY_KEY"
              ]
            }
          ]
        }
      ]
    }
  ]
}

Détection du schéma par défaut

Le connecteur Snowflake peut détecter automatiquement le schéma de votre table Snowflake. Pour utiliser la détection automatique de schéma, vous pouvez laisser le champ Chemin d'accès GCS du résultat de la traduction vide lorsque vous configurez un transfert Snowflake.

La liste suivante montre comment le connecteur Snowflake mappe vos types de données Snowflake dans BigQuery :

  • Les types de données suivants sont mappés en tant que STRING dans BigQuery :
    • TIMESTAMP_TZ
    • TIMESTAMP_LTZ
    • OBJECT
    • VARIANT
    • ARRAY
  • Les types de données suivants sont mappés en tant que TIMESTAMP dans BigQuery :
    • TIMESTAMP_NTZ

Tous les autres types de données Snowflake sont mappés directement à leurs types équivalents dans BigQuery.

Utiliser la sortie du moteur de traduction pour le schéma

Pour définir manuellement votre schéma (par exemple, pour remplacer certains attributs de schéma), vous pouvez générer vos métadonnées et exécuter le moteur de traduction en procédant comme suit :

Limites

  • Les données sont extraites de Snowflake au format Parquet avant d'être chargées dans BigQuery :

    • Les types de données Parquet suivants ne sont pas acceptés :

    • Les types de données Parquet suivants ne sont pas acceptés, mais peuvent être convertis :

      • TIMESTAMP_NTZ
      • OBJECT, VARIANT, ARRAY

      Utilisez le fichier YAML de configuration de la conversion de type global pour remplacer le comportement par défaut de ces types de données lorsque vous exécutez le moteur de traduction.

      Le fichier YAML de configuration peut ressembler à l'exemple suivant :

      type: experimental_object_rewriter
global:
  typeConvert:
    datetime: TIMESTAMP
    json: VARCHAR

Le connecteur du service de transfert de données BigQuery pour Snowflake utilise le moteur de traduction du service de migration BigQuery pour le mappage de schéma lors de la migration des tables Snowflake vers BigQuery. Pour effectuer un transfert de données Snowflake, vous devez d'abord générer des métadonnées pour la traduction, puis exécuter le moteur de traduction :

  1. Exécutez dwh-migration-tool pour Snowflake. Pour en savoir plus, consultez Générer des métadonnées pour la traduction et l'évaluation.
  2. Importez le fichier metadata.zip généré dans un bucket Cloud Storage. Le fichier metadata.zip est utilisé comme entrée pour le moteur de traduction.

  3. Exécutez le service de traduction par lot en spécifiant le champ target_types sur metadata. Pour en savoir plus, consultez Traduire des requêtes SQL avec l'API Translation.

    • Voici un exemple de commande permettant d'exécuter une traduction par lot pour Snowflake :
      curl -d "{
  \"name\": \"sf_2_bq_translation\",
  \"displayName\": \"Snowflake to BigQuery Translation\",
  \"tasks\": {
      string: {
        \"type\": \"Snowflake2BigQuery_Translation\",
        \"translation_details\": {
            \"target_base_uri\": \"gs://sf_test_translation/output\",
            \"source_target_mapping\": {
              \"source_spec\": {
                  \"base_uri\": \"gs://sf_test_translation/input\"
              }
            },
            \"target_types\": \"metadata\",
        }
      }
  },
  }" \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/project_id/locations/location/workflows
    • Vous pouvez vérifier l'état de cette commande sur la page Traduction SQL dans BigQuery. Le résultat du job de traduction par lot est stocké dans gs://translation_target_base_uri/metadata/config/.

Autorisations requises pour le compte de service

Dans un transfert Snowflake, un compte de service est utilisé pour lire les données issues du moteur de traduction dans le chemin Cloud Storage spécifié. Vous devez accorder au compte de service les autorisations storage.objects.get et storage.objects.list.

Nous vous recommandons d'utiliser un compte de service appartenant au même Google Cloud projet que celui dans lequel la configuration du transfert et l'ensemble de données de destination sont créés. Si le compte de service se trouve dans un projet Google Cloud différent de celui qui a créé le transfert de données BigQuery, vous devez activer l'autorisation du compte de service entre projets.

Pour en savoir plus, consultez Rôles et autorisations IAM BigQuery.

Évaluer les données Snowflake

BigQuery écrit les données de Snowflake dans Cloud Storage sous forme de fichiers Parquet. Les fichiers Parquet ne sont pas compatibles avec les types de données TIMESTAMP_TZ et TIMESTAMP_LTZ. Si vos données contiennent ces types, vous pouvez les exporter vers Amazon S3 sous forme de fichiers CSV, puis importer ces fichiers CSV dans BigQuery. Pour en savoir plus, consultez Présentation des transferts Amazon S3.

Activer les transferts incrémentiels

Avant de pouvoir configurer un transfert Snowflake incrémentiel, vous devez activer le suivi des modifications sur chaque table source à l'aide de la commande suivante :

ALTER TABLE DATABASE_NAME.SCHEMA_NAME.TABLE_NAME SET CHANGE_TRACKING = TRUE;

Si le suivi des modifications n'est pas activé pour une table, le connecteur Snowflake effectue par défaut un transfert complet des données pour cette table.

Recueillir les informations de transfert

Recueillez les informations dont vous avez besoin pour configurer la migration avec le service de transfert de données BigQuery :

Configurer un transfert Snowflake

Sélectionnez l'une des options suivantes :

Console

  1. Accédez à la page "Transferts de données" dans la console Google Cloud .

    Accéder à la page Transferts de données

  2. Cliquez sur Créer un transfert.

  3. Dans la section Type de source, sélectionnez Migration Snowflake dans la liste Source.

  4. Dans la section Transfer config name (Nom de la configuration de transfert), saisissez un nom pour le transfert, tel que My migration, dans le champ Display name (Nom à afficher). Le nom à afficher peut être n'importe quelle valeur permettant d'identifier le transfert si vous devez le modifier par la suite.

  5. Dans la section Destination settings (Paramètres de destination), choisissez l'ensemble de données que vous avez créé dans la liste Dataset (Ensemble de données).

  6. Dans la section Data source details (Détails de la source de données), procédez comme suit :

    1. Pour Identifiant de compte, saisissez un identifiant unique pour votre compte Snowflake, qui est une combinaison du nom de votre organisation et du nom de votre compte. L'identifiant correspond au préfixe de l'URL du compte Snowflake, et non à l'URL complète. Exemple :ACCOUNT_IDENTIFIER.snowflakecomputing.com
    2. Dans le champ Nom d'utilisateur, saisissez le nom d'utilisateur Snowflake dont les identifiants et l'autorisation sont utilisés pour accéder à votre base de données afin de transférer les tables Snowflake. Nous vous recommandons d'utiliser l'utilisateur que vous avez créé pour ce transfert.
    3. Pour Mécanisme d'authentification, sélectionnez une méthode d'authentification des utilisateurs Snowflake. Pour en savoir plus, consultez Générer une paire de clés pour l'authentification.
    4. Dans le champ Mot de passe, saisissez le mot de passe de l'utilisateur Snowflake. Ce champ est obligatoire si vous avez sélectionné PASSWORD dans le champ Auth mechanism (Mécanisme d'authentification).
    5. Pour Clé privée, saisissez la clé privée associée à la clé publique associée à l'utilisateur Snowflake. Ce champ est obligatoire si vous avez sélectionné KEY_PAIR dans le champ Mécanisme d'authentification.
    6. Pour La clé privée est-elle chiffrée ?, sélectionnez ce champ si la clé privée est chiffrée avec une phrase secrète.
    7. Dans le champ Phrase secrète de la clé privée, saisissez la phrase secrète de la clé privée chiffrée. Ce champ est obligatoire si vous avez sélectionné KEY_PAIR dans les champs Mécanisme d'authentification et La clé privée est-elle chiffrée ?.
    8. Pour Entrepôt, saisissez un entrepôt utilisé pour l'exécution de ce transfert de données.
    9. Pour Compte de service, saisissez un compte de service à utiliser avec ce transfert de données. Le compte de service doit appartenir au même projetGoogle Cloud que celui dans lequel la configuration du transfert et l'ensemble de données de destination sont créés. Le compte de service doit disposer des autorisations requises storage.objects.list et storage.objects.get.
    10. Dans le champ Base de données, saisissez le nom de la base de données Snowflake contenant les tables incluses dans ce transfert de données.
    11. Dans Schéma, saisissez le nom du schéma Snowflake contenant les tables incluses dans ce transfert de données.
    12. Sous Table name patterns (Modèles de nom de table), spécifiez une table à transférer en saisissant un nom ou un modèle correspondant au nom de la table dans le schéma. Vous pouvez utiliser des expressions régulières pour spécifier le modèle, par exemple table1_regex;table2_regex. Le modèle doit suivre la syntaxe d'expression régulière Java. Par exemple,
      • lineitem;ordertb renvoie les tables nommées lineitem et ordertb.
      • .* renvoie toutes les tables.

    13. Pour Mode d'ingestion, sélectionnez FULL ou INCREMENTAL. Pour en savoir plus, consultez Comportement d'ingestion des données.

    14. Facultatif : Pour Chemin d'accès GCS de la sortie de traduction, spécifiez le chemin d'accès au dossier Cloud Storage contenant les fichiers de mappage de schéma du moteur de traduction. Vous pouvez laisser ce champ vide pour que le connecteur Snowflake détecte automatiquement votre schéma.

      • Le chemin d'accès doit respecter le format translation_target_base_uri/metadata/config/db/schema/ et se terminer par /.

    15. Dans le champ Nom de l'objet d'intégration du stockage, saisissez le nom de l'objet d'intégration du stockage Snowflake.

    16. Pour Fournisseur de services cloud, sélectionnez AWS, AZURE ou GCP selon le fournisseur de services cloud qui héberge votre compte Snowflake.

    17. Pour URI Amazon S3, saisissez l'URI du bucket Amazon S3 à utiliser comme zone intermédiaire. Obligatoire uniquement lorsque votre fournisseur de services cloud est AWS.

    18. Dans les champs ID de clé d'accès et Clé d'accès secrète, saisissez la paire de clés d'accès. Obligatoire uniquement lorsque votre fournisseur de services cloud est AWS.

    19. Dans les champs Compte de stockage Azure et Conteneur de stockage Azure, saisissez le nom du compte de stockage et du conteneur Azure Blob Storage à utiliser comme zone de préparation. Obligatoire uniquement lorsque votre fournisseur de services cloud est AZURE.

    20. Dans le champ Jeton SAP, saisissez le jeton SAP généré pour le conteneur. Obligatoire uniquement lorsque votre fournisseur de services cloud est AZURE.

    21. Pour URI GCS, saisissez l'URI Cloud Storage à utiliser comme zone intermédiaire. Obligatoire uniquement lorsque votre fournisseur de services cloud est GCP.

  7. Facultatif : dans la section Options de notification, procédez comme suit :

    1. Cliquez sur le bouton pour activer les notifications par e-mail. Lorsque vous activez cette option, l'administrateur de transfert reçoit une notification par e-mail en cas d'échec de l'exécution du transfert.
    2. Pour le champ Select a Pub/Sub topic (Sélectionner un sujet Pub/Sub), choisissez le nom de votre sujet ou cliquez sur Create a topic (Créer un sujet). Cette option configure les notifications d'exécution Cloud Pub/Sub pour votre transfert.

  8. Si vous utilisez des CMEK, dans la section Options avancées, sélectionnez Clé gérée par le client. La liste des CMEK disponibles s'affiche. Pour en savoir plus sur le fonctionnement des CMEK avec le Service de transfert de données BigQuery, consultez Spécifier une clé de chiffrement avec les transferts.

  9. Cliquez sur Enregistrer.

  10. La console Google Cloud affiche tous les détails de configuration du transfert, y compris un nom de ressource pour ce transfert.

bq

Saisissez la commande bq mk, puis spécifiez l'option de création de transfert --transfer_config. Les paramètres suivants sont également requis :

  • --project_id
  • --data_source
  • --target_dataset
  • --display_name
  • --params
bq mk \
    --transfer_config \
    --project_id=project_id \
    --data_source=data_source \
    --target_dataset=dataset \
    --display_name=name \
    --service_account_name=service_account \
    --params='parameters'

Remplacez les éléments suivants :

  • project_id : ID de votre projet Google Cloud . Si --project_id n'est pas spécifié, le projet par défaut est utilisé.
  • data_source : source de données, snowflake_migration.
  • dataset : ensemble de données cible BigQuery pour la configuration de transfert.
  • name : nom à afficher de la configuration de transfert. Ce nom peut correspondre à toute valeur permettant d'identifier le transfert si vous devez le modifier ultérieurement.
  • service_account : (facultatif) nom du compte de service utilisé pour authentifier le transfert. Le compte de service doit appartenir au même project_id que celui utilisé pour créer le transfert et doit disposer de tous les rôles requis.
  • parameters correspond aux paramètres de la configuration de transfert créée, au format JSON. Exemple : --params='{"param":"param_value"}'.

Les paramètres requis pour une configuration de transfert Snowflake sont les suivants :

  • account_identifier : spécifiez un identifiant unique pour votre compte Snowflake, qui est une combinaison du nom de votre organisation et du nom de votre compte. L'identifiant est le préfixe de l'URL du compte Snowflake, et non l'URL complète. Exemple :account_identifier.snowflakecomputing.com
  • username : spécifiez le nom d'utilisateur Snowflake dont les identifiants et l'autorisation sont utilisés pour accéder à votre base de données afin de transférer les tables Snowflake.
  • auth_mechanism : spécifiez la méthode d'authentification des utilisateurs Snowflake. Les valeurs acceptées sont PASSWORD et KEY_PAIR. Pour en savoir plus, consultez Générer une paire de clés pour l'authentification.
  • password : spécifiez le mot de passe de l'utilisateur Snowflake. Ce champ est obligatoire si vous avez spécifié PASSWORD dans le champ auth_mechanism.
  • private_key : spécifiez la clé privée associée à la clé publique associée à l'utilisateur Snowflake. Ce champ est obligatoire si vous avez spécifié KEY_PAIR dans le champ auth_mechanism.
  • is_private_key_encrypted : spécifiez true si la clé privée est chiffrée avec une phrase secrète.
  • private_key_passphrase : spécifiez la phrase secrète pour la clé privée chiffrée. Ce champ est obligatoire si vous avez spécifié KEY_PAIR dans le champ auth_mechanism et true dans le champ is_private_key_encrypted.
  • warehouse : spécifiez un entrepôt utilisé pour l'exécution de ce transfert de données.
  • service_account : spécifiez un compte de service à utiliser avec ce transfert de données. Le compte de service doit appartenir au même projet Google Cloud que celui dans lequel la configuration du transfert et l'ensemble de données de destination sont créés. Le compte de service doit disposer des autorisations requises storage.objects.list et storage.objects.get.
  • database : spécifiez le nom de la base de données Snowflake contenant les tables incluses dans ce transfert de données.
  • schema : spécifiez le nom du schéma Snowflake contenant les tables incluses dans ce transfert de données.

  • table_name_patterns : spécifiez une table à transférer en saisissant un nom ou un modèle correspondant au nom de la table dans le schéma. Vous pouvez utiliser des expressions régulières pour spécifier le modèle, par exemple table1_regex;table2_regex. Le modèle doit suivre la syntaxe d'expression régulière Java. Par exemple,

    • lineitem;ordertb renvoie les tables nommées lineitem et ordertb.

    • .* renvoie toutes les tables.

      Vous pouvez également laisser ce champ vide pour migrer toutes les tables à partir du schéma spécifié.

  • ingestion_mode : spécifiez le mode d'ingestion pour le transfert. Les valeurs acceptées sont FULL et INCREMENTAL. Pour en savoir plus, consultez Comportement de l'ingestion de données.

  • translation_output_gcs_path : (facultatif) spécifiez le chemin d'accès au dossier Cloud Storage contenant les fichiers de mappage de schéma du moteur de traduction. Vous pouvez laisser ce champ vide pour que le connecteur Snowflake détecte automatiquement votre schéma.

    • Le chemin d'accès doit respecter le format gs://translation_target_base_uri/metadata/config/db/schema/ et se terminer par /.

  • storage_integration_object_name : spécifiez le nom de l'objet d'intégration du stockage Snowflake.

  • cloud_provider : saisissez AWS, AZURE ou GCP selon le fournisseur de services cloud qui héberge votre compte Snowflake.

  • staging_s3_uri : saisissez l'URI du bucket S3 à utiliser comme zone intermédiaire. Obligatoire uniquement lorsque votre cloud_provider est défini sur AWS.

  • aws_access_key_id : saisissez la paire de clés d'accès. Obligatoire uniquement lorsque votre cloud_provider est défini sur AWS.

  • aws_secret_access_key : saisissez la paire de clés d'accès. Obligatoire uniquement lorsque votre cloud_provider est défini sur AWS.

  • azure_storage_account : saisissez le nom du compte de stockage à utiliser comme zone de préparation. Obligatoire uniquement lorsque votre cloud_provider est défini sur AZURE.

  • staging_azure_container : saisissez le conteneur dans Azure Blob Storage à utiliser comme zone de préparation. Obligatoire uniquement lorsque votre cloud_provider est défini sur AZURE.

  • azure_sas_token : saisissez le jeton SAP. Obligatoire uniquement lorsque votre cloud_provider est défini sur AZURE.

  • staging_gcs_uri : saisissez l'URI Cloud Storage à utiliser comme zone de préparation. Obligatoire uniquement lorsque votre cloud_provider est défini sur GCP.

Par exemple, pour un compte Snowflake hébergé sur AWS, la commande suivante crée un transfert Snowflake nommé Snowflake transfer config avec un ensemble de données cible nommé your_bq_dataset et un projet dont l'ID est your_project_id.

  PARAMS='{
  "account_identifier": "your_account_identifier",
  "auth_mechanism": "KEY_PAIR",
  "aws_access_key_id": "your_access_key_id",
  "aws_secret_access_key": "your_aws_secret_access_key",
  "cloud_provider": "AWS",
  "database": "your_sf_database",
  "ingestion_mode": "INCREMENTAL",
  "private_key": "-----BEGIN PRIVATE KEY----- privatekey\nseparatedwith\nnewlinecharacters=-----END PRIVATE KEY-----",
  "schema": "your_snowflake_schema",
  "service_account": "your_service_account",
  "storage_integration_object_name": "your_storage_integration_object",
  "staging_s3_uri": "s3://your/s3/bucket/uri",
  "table_name_patterns": ".*",
  "translation_output_gcs_path": "gs://sf_test_translation/output/metadata/config/database_name/schema_name/",
  "username": "your_sf_username",
  "warehouse": "your_warehouse"
}'

bq mk --transfer_config \
    --project_id=your_project_id \
    --target_dataset=your_bq_dataset \
    --display_name='snowflake transfer config' \
    --params="$PARAMS" \
    --data_source=snowflake_migration

API

Utilisez la méthode projects.locations.transferConfigs.create et fournissez une instance de la ressource TransferConfig.

Spécifier une clé de chiffrement avec les transferts

Vous pouvez spécifier des clés de chiffrement gérées par le client (CMEK) pour chiffrer les données d'une exécution de transfert. Vous pouvez utiliser une clé CMEK pour accepter les transferts provenant de Snowflake.

Lorsque vous spécifiez une clé CMEK avec un transfert, le service de transfert de données BigQuery l'applique à tous les caches sur disque intermédiaires des données ingérées afin que l'intégralité du workflow de transfert de données soit compatible avec CMEK.

Vous ne pouvez pas mettre à jour un transfert existant pour ajouter une clé CMEK si le transfert n'a pas été initialement créé avec une clé CMEK. Par exemple, vous ne pouvez pas modifier une table de destination initialement chiffrée par défaut pour être chiffrée avec des clés CMEK. À l'inverse, vous ne pouvez pas modifier une table de destination chiffrée par CMEK pour obtenir un type de chiffrement différent.

Vous pouvez mettre à jour une clé CMEK pour un transfert si la configuration de celui-ci a été initialement créée avec un chiffrement CMEK. Lorsque vous mettez à jour une clé CMEK pour une configuration de transfert, le service de transfert de données BigQuery propage cette clé aux tables de destination à la prochaine exécution du transfert, où le service de transfert de données BigQuery remplace toutes les clés CMEK obsolètes par la nouvelle clé lors de l'exécution du transfert. Pour en savoir plus, consultez Mettre à jour un transfert.

Vous pouvez également utiliser les clés par défaut d'un projet. Lorsque vous spécifiez une clé de projet par défaut avec un transfert, le service de transfert de données BigQuery utilise cette clé pour toutes les nouvelles configurations de transfert.

Quotas et limites

BigQuery a un quota de charge de 15 To par tâche de chargement et par table. En interne, Snowflake compresse les données de la table. La taille de la table exportée est donc supérieure à celle indiquée par Snowflake. Si vous envisagez de migrer une table de plus de 15 To, veuillez contacter dts-migration-preview-support@google.com.

En raison du modèle de cohérence d'Amazon S3, il est possible que certains fichiers ne soient pas inclus dans le transfert vers BigQuery.

Tarifs

Pour plus d'informations sur la tarification du service de transfert de données BigQuery, consultez la page Tarifs.

  • Si l'entrepôt de données Snowflake et le bucket Amazon S3 se trouvent dans des régions différentes, Snowflake applique des frais de sortie lorsque vous exécutez un transfert de données Snowflake. Aucuns frais de sortie ne s'appliquent aux transferts de données Snowflake si l'entrepôt de données Snowflake et le bucket Amazon S3 se trouvent dans la même région.
  • Lorsque des données sont transférées d'AWS vers Google Cloud, des frais de sortie inter-cloud s'appliquent.

Étapes suivantes