Migration de Snowflake vers BigQuery
Ce document présente la migration de Snowflake vers BigQuery. Les sections suivantes présentent les outils de migration pour vous aider à effectuer une migration BigQuery et décrivent certaines différences entre Snowflake et BigQuery pour vous aider à planifier votre migration.
Migrer des workflows de Snowflake vers BigQuery
Lorsque vous planifiez une migration BigQuery, tenez compte des différents workflows que vous avez sur Snowflake et de la manière dont vous pouvez les migrer individuellement. Pour minimiser l'impact sur vos opérations existantes, nous vous recommandons de migrer vos requêtes SQL vers BigQuery, puis de migrer votre schéma et votre code.
Migrer des requêtes SQL
Pour migrer vos requêtes SQL, le service de migration BigQuery propose diverses fonctionnalités de traduction SQL pour automatiser la conversion de vos requêtes SQL Snowflake en requêtes SQL GoogleSQL, telles que le traducteur SQL par lot pour traduire des requêtes en bloc, le traducteur SQL interactif pour traduire des requêtes individuelles et l'API de traduction SQL. Ces services de traduction incluent également une fonctionnalité améliorée par Gemini pour simplifier davantage le processus de migration de vos requêtes SQL.
Lorsque vous traduisez vos requêtes SQL, examinez-les attentivement pour vérifier que les types de données et les structures de table sont correctement gérés. Pour ce faire, nous vous recommandons de créer un large éventail de cas de test avec différents scénarios et données. Exécutez ensuite ces cas de test sur BigQuery pour comparer les résultats aux résultats Snowflake d'origine. S'il existe des différences, analysez et corrigez les requêtes converties.
Migrer le schéma et le code
Pour migrer le schéma et les données depuis Snowflake, utilisez le connecteur Snowflake dans le service de transfert de données BigQuery pour configurer un transfert de données. Lorsque vous configurez le transfert de données, vous pouvez spécifier des tables Snowflake spécifiques à inclure, et le connecteur peut également détecter automatiquement le schéma de votre table et les types de données lors d'un transfert.
Pour en savoir plus sur la configuration d'un transfert de données Snowflake, consultez la section Planifier un transfert Snowflake.
Transfert incrémentiel
Lorsque vous effectuez un transfert de données Snowflake à l'aide du connecteur Snowflake, vous pouvez configurer un transfert incrémentiel qui ne transfère que les données qui ont été modifiées depuis le dernier transfert de données, au lieu de charger l'ensemble de données à chaque transfert de données. Pour en savoir plus, consultez la section Planifier un transfert Snowflake.
Migrer d'autres fonctionnalités Snowflake
Tenez compte des fonctionnalités Snowflake suivantes lorsque vous planifiez votre migration vers BigQuery.
| Cas d'utilisation | Fonctionnalité Snowflake | Fonctionnalité BigQuery |
|---|---|---|
| Préparation des fichiers de données brutes pour le chargement et l'exportation | Les données peuvent être importées et exportées vers la zone de préparation à l'aide des commandes `GET` et `PUT`. Les requêtes et les commandes `COPY` peuvent lire et écrire dans les zones de préparation. | BigQuery s'appuie sur Cloud Storage pour préparer les données de fichiers et permet de lire et d'écrire dans plusieurs autres sources et Google Cloud services. Utilisez Cloud Storage pour importer et exporter des fichiers de données brutes. Pour en savoir plus sur les différentes manières de charger des données à partir de Cloud Storage et d'autres sources, consultez la section Présentation du chargement de données. Pour en savoir plus sur l'exportation vers Cloud Storage et d'autres sources, consultez la section Présentation de l'exportation de données. |
| Précalcul des résultats de requêtes courants | Les tables dynamiques peuvent être définies avec une requête et actualisées selon une planification. | Les vues matérialisées peuvent être configurées pour persister et actualiser automatiquement le calcul des requêtes SQL. |
| Petites opérations DML | Les tables hybrides Snowflake autorisent les petites écritures LMD. | Les opérations DML précises peuvent être utilisées dans BigQuery pour améliorer la latence et le débit des petites écritures. Pour les cas d'utilisation avancés de traitement hybride transactionnel et analytique (HTAP), envisagez d'utiliser des ensembles de données externes Spanner. |
| Notebooks et visualisation | Les applications Snowflake Streamlit peuvent visualiser des données avec du code Python. | Les notebooks BigQuery et la bibliothèque Python BigFrames peuvent être utilisés pour explorer et visualiser des données en Python. Pour en savoir plus sur les intégrations avec Looker et d'autres outils d'analyse et de visualisation, consultez la section Présentation des outils d'analyse et d'informatique décisionnelle. |
| Disposition physique des données | Snowflake est compatible avec le clustering et le micro-partitionnement pour organiser les données sur le disque. | BigQuery est compatible avec le partitionnement et le clustering explicites pour offrir aux utilisateurs un contrôle précis sur la distribution et l'organisation des données, ce qui peut améliorer les performances en termes de coûts et d'exécution. Le service de traduction SQL gère automatiquement la traduction du clustering de tables et peut être configuré pour personnaliser le partitionnement et le clustering lors de la migration des DDL. |
| Fonctions et procédures externes | Snowflake est compatible avec les fonctions et les procédures stockées implémentées dans plusieurs langages externes. | BigQuery accepte les appels de fonction externes via les fonctions Cloud Run. Vous pouvez également utiliser des [fonctions définies par l'utilisateur](/bigquery/docs/user-defined-functions) (UDF), telles que les UDF SQL, qui sont exécutées dans BigQuery. BigQuery est compatible avec SQL pour les procédures stockées. Pour les autres langages, nous vous recommandons d'utiliser des fonctions externes ou une logique d'application côté client. |
Fonctionnalités de sécurité BigQuery
Lorsque vous migrez de Snowflake vers BigQuery, tenez compte de la manière dont Google Cloud gère la sécurité différemment de Snowflake.
La sécurité dans BigQuery est intrinsèquement liée à la gestion de l'authentification et des accès (IAM) dans Google Cloud. Les droits IAM définissent les opérations autorisées sur une ressource et sont appliqués au Google Cloud niveau, ce qui fournit une approche centralisée et cohérente de la gestion de la sécurité. Voici quelques-unes des principales fonctionnalités de sécurité de Google Cloud:
- Sécurité intégrée : BigQuery exploite les fonctionnalités de sécurité de Google Cloud's. Cela inclut IAM pour un contrôle précis des accès pour une intégration de sécurité robuste et transparente.
- Sécurité au niveau des ressources : IAM se concentre sur le contrôle des accès au niveau des ressources, en accordant des autorisations aux utilisateurs et aux groupes pour diverses ressources et services BigQuery. Cette approche permet de gérer efficacement les droits d'accès afin que les utilisateurs ne disposent que des autorisations nécessaires pour effectuer leurs tâches.
- Sécurité réseau : BigQuery bénéficie des fonctionnalités de sécurité réseau robustes de Google Cloud's, telles que le cloud privé virtuel et les connexions privées.
Lorsque vous migrez de Snowflake vers BigQuery, tenez compte des exigences de migration liées à la sécurité suivantes :
- Configuration IAM : vous devez configurer les rôles et les autorisations IAM dans BigQuery pour qu'ils correspondent à vos stratégies de contrôle des accès Snowflake existantes. Cela implique de mapper les rôles Snowflake sur les rôles et autorisations IAM BigQuery appropriés.
- Contrôle précis des accès : si vous utilisez la sécurité au niveau des lignes ou des colonnes dans Snowflake, vous devrez implémenter des contrôles équivalents dans BigQuery à l'aide de vues autorisées ou de tags avec stratégie.
- Migration des vues et des UDF : lorsque vous migrez des vues et des UDF, vérifiez que les contrôles de sécurité associés sont correctement traduits en vues et UDF autorisées dans BigQuery.
Chiffrement
BigQuery chiffre vos données au repos et en transit par défaut. Si vous avez besoin de plus de contrôle sur les clés de chiffrement, BigQuery est compatible avec les clés de chiffrement gérées par le client dans le Cloud Key Management Service. Vous pouvez également utiliser le chiffrement au niveau des colonnes.
Pour maintenir la sécurité des données pendant et après la migration vers BigQuery, tenez compte des points suivants :
- Gestion des clés : si vous avez besoin de clés gérées par le client, établissez une stratégie de gestion des clés dans Cloud Key Management Service et configurez BigQuery pour qu'il utilise ces clés.
- Masquage/tokenisation des données : si des données sensibles sont impliquées, déterminez si le masquage ou la tokenisation des données est nécessaire pour les protéger.
- Sécurité au niveau des lignes : implémentez la sécurité au niveau des lignes à l'aide de vues autorisées, de filtres de sécurité au niveau des lignes ou d'autres méthodes appropriées.
- Analyse des failles et tests d'intrusion : effectuez régulièrement des analyses des failles et des tests d'intrusion pour vérifier la posture de sécurité de votre environnement BigQuery.
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.
Au sein d'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
Google Cloud console, de l'API Identity and Access Management ou de
gcloud CLI. En règle générale, pour renforcer la sécurité, nous vous recommandons d'utiliser des rôles prédéfinis 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.
BigQuery est compatible avec le contrôle des accès au niveau des tables. 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.
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 contrôle des 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.
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. Vous pouvez également utiliser des outils de traduction SQL, tels que le traducteur SQL interactif, l' API de traduction SQLou le traducteur SQL par lot, pour traduire différents dialectes SQL en GoogleSQL.
Pour en savoir plus 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 suivants directement dans BigQuery :
- Charger des données CSV à partir de Cloud Storage.
- Charger des données Parquet depuis Cloud Storage.
- Charger des données JSON à partir de Cloud Storage.
- Interroger des données à partir d'Apache Iceberg.
Outils de migration
La liste suivante décrit les outils que vous pouvez utiliser pour migrer des données depuis Snowflake vers BigQuery. Pour obtenir des exemples d'utilisation combinée de ces outils dans un pipeline de migration Snowflake, consultez la section Exemples de pipeline de migration Snowflake.
COPY INTO <location>commande: Utilisez cette commande dans Snowflake pour extraire 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 Managed Service pour Apache Spark.
- 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 :
- Connecteur BigQuery Data Transfer Service pour Snowflake (aperçu) : effectuez un transfert par lot automatisé de données Cloud Storage vers BigQuery.
- La Google Cloud CLI: 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.
Tarifs
Lorsque vous planifiez votre migration Snowflake, tenez compte du coût du transfert et du stockage des données, ainsi que de l'utilisation des services dans BigQuery. Pour en savoir plus, reportez-vous à la page Tarifs.
Des frais de sortie peuvent s'appliquer pour le transfert de données depuis Snowflake ou AWS. Des frais supplémentaires peuvent également s'appliquer lorsque vous transférez des données entre régions ou entre différents fournisseurs de cloud.
Commencer
Les sections suivantes résument le processus de migration de Snowflake vers BigQuery :
Exécuter une évaluation de la migration
Lors de votre migration de Snowflake vers BigQuery, nous vous recommandons de commencer par exécuter l'outil d'évaluation de la migration BigQuery pour évaluer la faisabilité et les avantages potentiels du transfert de votre entrepôt de données de Snowflake vers BigQuery. Cet outil fournit une approche structurée pour comprendre votre environnement Snowflake actuel et estimer l'effort nécessaire pour réussir la migration.
L'exécution de l'outil d'évaluation de la migration BigQuery génère un rapport d'évaluation qui contient les sections suivantes :
- Rapport sur le système existant : instantané du système Snowflake existant et de son utilisation, y compris le nombre de bases de données, de schémas et de tables, ainsi que la taille totale en To. Il répertorie également les schémas par taille et pointe vers une utilisation potentiellement sous-optimale des ressources, comme les tables sans écriture ou peu de lectures.
- Suggestions de transformation de l'état stable BigQuery : montre à quoi ressemblera le système dans BigQuery après la migration. Il inclut des suggestions pour optimiser les charges de travail dans BigQuery et éviter les gaspillages.
- Plan de migration : fournit des informations sur l'effort de migration lui-même. Par exemple, passer du système existant à l'état stable de BigQuery. Cette section inclut le nombre de requêtes traduites automatiquement, ainsi que le temps nécessaire pour déplacer chaque table vers BigQuery.
Pour en savoir plus sur les résultats d'une évaluation de la migration, consultez la section Examiner le rapport Looker Studio.
Valider votre migration
Une fois que vous avez migré vos données Snowflake vers BigQuery, exécutez l'outil de validation des données (DVT) pour effectuer une validation sur vos données BigQuery nouvellement migrées. Le DVT valide diverses fonctions, du niveau des tables au niveau des lignes, pour vérifier que vos données migrées fonctionnent comme prévu.