Guide de migration d’Amazon Redshift vers Snowflake¶

Phase 1 : Planification et conception¶

Cette phase initiale est essentielle pour établir les bases d’une migration réussie. Bâcler cette étape entraîne souvent un glissement des fonctionnalités, des dépassements de budget et des dépassements de délai. Un plan détaillé garantit que toutes les parties prenantes sont d’accord et que les objectifs du projet sont clairement définis.

Vos étapes pratiques :

• ** Réaliser une évaluation complète de votre environnement Redshift :**

  • Inventaire et analyse : répertoriez l’ensemble des bases de données, schémas, tables, vues, procédures stockées et fonctions définies par l’utilisateur (UDFs) dans votre cluster Redshift. Utilisez les tables système Redshift (SVV_TABLE_INFO, PG_PROC, etc.) pour collecter des métadonnées.

  • Analyse des charges de travail : utilisez les vues STL_QUERY et SVL_QUERY_SUMMARY de Redshift pour identifier les modèles de requêtes, la simultanéité des utilisateurs et les goulots d’étranglement des performances. Ces données sont cruciales pour la conception de votre stratégie d’entrepôt virtuel Snowflake.

  • Identifier les dépendances : mappez toutes les sources de données en amont (ETL/tâches ELT) et des consommateurs en aval (outils BI, applications, notebooks sur la science des données).

• Définition de la portée et de la stratégie de la migration :

  • Hiérarchisation des charges de travail : catégorisez les charges de travail par impact métier et complexité technique. Commencez par une charge de travail à fort impact et à faible complexité pour obtenir des résultats rapides et créer une dynamique.

  • ** Choix d’une approche de migration : ** choisissez entre une approche « Lift and Shift » pour une migration plus rapide ou une approche de réarchitecture pour moderniser et optimiser les modèles de données et les pipelines.

• Développement du plan du projet :

  • Construire une équipe : créez une équipe de migration avec des rôles et des responsabilités clairs (par exemple, gestionnaire de projet, ingénieur des données, DBA, administrateur de sécurité, analyste commercial).

  • Création d’un calendrier : définissez des plannings et des étapes réalistes pour chacune des neuf phases.

  • Définition des métriques de réussite : établissez clairement les KPIs pour mesurer la réussite de la migration, comme la réduction des coûts, l’amélioration des performances des requêtes et la satisfaction des utilisateurs.

Phase 2 : Environnement et sécurité¶

Avec un plan solide en place, l’étape suivante consiste à préparer l’environnement Snowflake et à répliquer votre posture de sécurité. Un avantage clé de la migration depuis Redshift est que les deux plateformes s’exécutent généralement sur le même fournisseur cloud (AWS), ce qui simplifie le transfert de données.

Vos étapes pratiques :

• Configuration de votre compte Snowflake :

  • ** Choix de la version et du fournisseur Cloud :** sélectionnez la version de Snowflake (par exemple, Standard, Enterprise, Business Critical) qui répond à vos besoins. Choisissez AWS en tant que fournisseur Cloud et sélectionnez la même région que vos compartiments S3 actuels afin de réduire les coûts de transfert de données et la latence.

  • Conception d’une stratégie d’entrepôt : sur la base de l’analyse de charge de travail de la phase 1, créez un ensemble initial d’entrepôts virtuels. Isolez les différentes charges de travail (par exemple, WH_LOADING, WH_TRANSFORM, WH_BI_ANALYTICS) pour éviter les conflits de ressources. Commencez par des tailles de t-shirt (par exemple, X-Small, Small) et prévoyez de les redimensionner en fonction de tests de performance.

• Mise en œuvre du modèle de sécurité :

  • Mappage des utilisateurs/groupes Redshift sur les rôles Snowflake : traduisez les autorisations d’utilisateur et de groupe Redshift dans le modèle de contrôle d’accès basé sur les rôles (RBAC) de Snowflake. Créez une hiérarchie de rôles fonctionnels (par ex., SYSADMIN, SECURITYADMIN) et des rôles d’accès (p. ex., BI_READ_ONLY, ETL_READ_WRITE).

  • Configuration ds politiques réseau et de l’authentification : définissez des politiques réseau pour restreindre l’accès aux adresses IP de confiance. Configurez des méthodes d’authentification, telles que l’authentification fédérée (SSO) en utilisant un fournisseur d’identité comme Okta ou Azure AD.

Phase 3 : Conversion du code de base de données¶

Cette phase implique la conversion de DDL, DML, et de code procédural Redshift pour qu’ils soient compatibles avec Snowflake. Les outils d’automatisation peuvent accélérer ce processus, mais l’examen et le réglage manuels sont essentiels en raison des différences de dialectes SQL et d’architecture de plateforme.

Vos étapes pratiques :

• Conversion du DDL (Langage de définition des données) :

  • Tables et vues : extrayez les instructions CREATE TABLE et CREATE VIEW de Redshift. Convertissez les types de données spécifiques à Redshift en leurs équivalents Snowflake (voir annexe 2).

  • Suppression des clauses spécifiques à Redshift : éliminez les clauses de conception physique spécifiques à Redshift comme DISTSTYLE, DISTKEY, et SORTKEY. L’architecture de Snowflake gère la distribution des données et le clustering automatiquement ou via des clés de clustering logiques sur de très grandes tables.

• Conversion du DML (Langage de manipulation de données) et du code procédural :

  • Réécriture des procédures stockées : Redshift utilise PL/pgSQL pour les procédures stockées. Celles-ci doivent être réécrites manuellement dans un langage pris en charge par Snowflake, tel que l’exécution de scripts Snowflake (SQL), JavaScript, Python ou Java. C’est souvent la partie du processus de conversion de code qui prend le plus de temps.

  • ** Traduction des fonctions SQL :** Mappez les fonctions spécifiques à Redshift sur leurs homologues Snowflake. Par exemple, la fonction GETDATE() de Redshift devient de CURRENT_TIMESTAMP() de Snowflake. Voir l’annexe 3 pour les mappages des fonctions courantes.

  • Replacement des commandes de maintenance : les scripts contenant des commandes spécifiques à Redshift comme VACUUM, ANALYZE, et REINDEX doivent être supprimés, car Snowflake gère ces tâches de maintenance automatiquement.

Phase 4 : Migration des données¶

Cette phase se concentre sur le déplacement physique des données historiques de votre cluster Redshift vers des tables Snowflake. La méthode la plus efficace exploite Amazon S3 comme zone de mise en zone de préparation intermédiaire.

Vos étapes pratiques :

• Déchargement des données de Redshift vers S3 :

  • Utilisez la commande UNLOAD Redshift pour exporter des données à partir de tables dans un compartiment S3 désigné. Cette opération est fortement parallélisée et significativement plus rapide qu’une requête SELECT via un outil client.

  • Formatez les données en tant que Parquet ou CSV compressé pour des performances de chargement optimales dans Snowflake. Utilisez l’option PARALLEL ON pour écrire plusieurs fichiers.

• Chargement de données de S3 vers Snowflake :

  • Création de zones de préparation externes : dans Snowflake, créez un objet de zone de préparation externe qui pointe vers le compartiment S3 contenant vos données déchargées.

  • Utilisation de la commande COPY INTO : utilisez la commande COPY INTO <table> Snowflake pour charger les données de la zone de préparation S3 dans les tables cibles de Snowflake. Cette commande est extrêmement performante et évolutive.

  • Utilisation d’un entrepôt virtuel plus grand : utilisez un entrepôt virtuel dédié et plus grand pour la charge de données initiale afin d’accélérer le processus, puis réduisez-le ou suspendez-le pour gérer les coûts.

Phase 5 : ingestion des données¶

Une fois les données historiques migrées, vous devez reconstruire vos pipelines d’ingestion de données en cours pour alimenter en données directement dans Snowflake au lieu de Redshift.

Vos étapes pratiques :

• Migration des tâches ETL/ELT par lots :

  • Mettez à jour les tâches ETL existantes (dans des outils tels que AWS Glue, Talend, or Informatica) pour cibler Snowflake comme destination. Cela implique généralement la modification des détails de la connexion et la mise à jour des remplacements SQL pour utiliser le dialecte de Snowflake.

• Implémentation de l’ingestion continue à Snowpipe :

  • pour les flux de données continus (par exemple, depuis Kinesis ou les journaux d’application aboutissant dans S3), configurez Snowpipe. Snowpipe charge automatiquement et efficacement les nouveaux fichiers de données des tables S3 à Snowflake au fur et à mesure qu’ils arrivent, fournissant ainsi une solution d’ingestion en temps quasi réel.

• Utilisation de l’écosystème Snowflake :

  • Explorez les connecteurs natifs de Snowflake pour des plateformes comme Kafka et Spark afin de simplifier la diffusion directe de données.

Phase 6 : Rapports et analyses¶

Cette phase implique la redirection de toutes les applications en aval, en particulier les outils de BI et de rapports, pour interroger les données de Snowflake.

Vos étapes pratiques :

• Mise à jour des pilotes de connexion : installez et configurez les pilotes ODBC/JDBC de Snowflake sur les serveurs hébergeant vos outils de BI (par exemple, Tableau Server, Power BI Gateway).

• Redirection des rapports et tableaux de bord :

  • Dans vos outils de BI, modifiez la connexion de la source de données de Redshift à Snowflake.

  • Testez tous les rapports et tableaux de bord critiques pour vous assurer qu’ils fonctionnent correctement.

• Examen et optimisation des requêtes :

  • Certains tableaux de bord peuvent contenir des SQL personnalisés ou des fonctions spécifiques à la base de données. Vérifiez et refactorisez ces requêtes pour utiliser le dialecte SQL de Snowflake et tirer parti de ses fonctionnalités de performance. Utilisez l’outil Profil de requête dans Snowflake pour analyser et optimiser les rapports qui s’exécutent lentement.

Phase 7 : validation et test des données¶

Des tests rigoureux sont essentiels pour construire la confiance des entreprises dans la nouvelle plateforme et garantir l’intégrité et les performances des données à la hauteur de leurs attentes.

Vos étapes pratiques :

• Exécution de la validation des données :

  • Nombre de lignes : comparez les nombres de lignes entre les tables sources dans Redshift et les tables cibles dans Snowflake.

  • Validation au niveau des cellules : pour les tables critiques, effectuez une validation plus approfondie en comparant les valeurs agrégées (ex : SUM(), AVG(), MIN(), MAX()) ou en utilisant des sommes de contrôle sur les colonnes clés.

• Exécution de test de requêtes et de performances :

  • Requêtes de référence : exécutez un ensemble représentatif de requêtes sur Redshift et Snowflake et comparez les résultats et les performances.

  • Performance de l’outil de BI : testez les temps de chargement et l’interactivité des principaux tableaux de bord connectés à Snowflake.

• Test d’acceptation par l’utilisateur (UAT) :

  • Impliquez les utilisateurs professionnels pour valider leurs rapports et pour qu’ils effectuent leurs tâches quotidiennes en utilisant le nouvel environnement Snowflake. Recueillez les commentaires et résolvez les problèmes.

Phase 8 : Déploiement¶

Le déploiement est la dernière partie de la migration de Redshift vers Snowflake. Ce processus doit être géré avec soin afin d’éviter toute perturbation des opérations commerciales.

Vos étapes pratiques :

• Développement d’un plan de migration :

  • Définissez l’ordre des événements pour le fin de semaine ou le soir de la migration. Ceux-ci incluent l’arrêt des tâches ETL pointant vers Redshift, l’exécution d’une synchronisation finale des données, la redirection de toutes les connexions et la validation de l’intégrité du système.

• Exécution de la synchronisation finale des données :

  • Effectuez un dernier chargement de données incrémentiel pour capturer toutes les modifications de données qui se sont produites au cours de la phase de test.

• Mise en production :

  • Basculez l’ensemble des pipelines de données de production et des connexions utilisateur de Redshift vers Snowflake.

  • Conservez l’environnement Redshift en lecture seule pendant une courte période comme solution de secours avant son interruption.

• Désactivation de Redshift :

  • Une fois que l’environnement Snowflake est stable et validé en production, vous pouvez désactiver le cluster Redshift pour ne plus encourir de frais.

Phase 9 : Optimisation et exécution¶

Cette phase finale est un processus permanent de gestion des performances, des coûts et de la gouvernance dans votre nouvel environnement Snowflake. L’objectif est d’affiner en continu votre configuration pour en maximiser la valeur.

Vos étapes pratiques :

• Implémentation de l’optimisation des performances et des coûts :

  • Entrepôts de taille adaptée : surveillez en permanence les performances de la charge de travail et ajustez les tailles des entrepôts virtuels à la hausse ou à la baisse pour répondre aux SLAs au coût le plus bas possible.

  • Définition de politiques de suspension automatique agressives : définissez le délai de suspension automatique de tous les entrepôts à 60 secondes pour éviter de payer pour le temps de calcul inactif.

  • Utilisation de clés de clustering : pour les très grandes tables (plusieurs téraoctets), analysez les modèles de requête et définissez des clés de clustering pour améliorer les performances des requêtes fortement filtrées.

• Établissement de FinOps et de gouvernance à long terme :

  • Surveillance des coûts : utilisez le schéma ACCOUNT_USAGE et les moniteurs de ressources de Snowflake pour suivre la consommation de crédit et éviter les dépassements de budget.

  • Amélioration de la sécurité : auditez régulièrement les rôles et les autorisations pour vous assurer que le principe du moindre privilège est maintenu. Mettez en œuvre des fonctionnalités de sécurité avancées comme le masquage dynamique des données et les politiques d’accès aux lignes pour les données sensibles.

Annexe 1 : Architecture Snowflake ou Redshift¶

Annexe 2 : Mappages de types de données¶

Annexe 3 : SQL et les différences de fonctions¶