Guide de migration Azure Synapse vers Snowflake¶

Phase 1 : Planification et conception¶

Cette phase initiale est essentielle pour établir les bases d’une migration réussie. La migration à partir d’Azure Synapse nécessite une bonne compréhension de ses composants intégrés et un plan détaillé pour aligner les parties prenantes, définir la portée et éviter les dépassements budgétaires.

Vos étapes pratiques :

• ** Exécution d’une évaluation complète de votre environnement Synapse :**

  • Inventaire et analyse : répertoriez tous les objets de votre espace de travail Synapse, y compris les tables de pools SQL dédiées, les vues de pool SQL sans serveur, les schémas, les procédures stockées, fonctions et vues T-SQL. Utilisez les vues système de Synapse (par exemple, sys.tables, sys.procedures) pour collecter des métadonnées.

  • Analyse des charges de travail : utilisez le moniteur Azure et des vues de gestion dynamique de Synapse (DMVs) pour identifier les modèles de requête, la simultanéité des utilisateurs, l’utilisation des ressources (DWUs), et les goulots d’étranglement de performance. Ces données sont cruciales pour la conception de votre stratégie d’entrepôt virtuel Snowflake.

  • Identification des dépendances : mappez toutes les sources de données en amont, en particulier Azure Data Factory (ADF), et les consommateurs en aval comme les rapports Power BI, les modèles Azure Machine Learning et d’autres applications.

• 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é (par exemple, un Datamart spécifique) pour démontrer la valeur 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 les modèles de données et les pipelines.

• Développement du plan du projet :

  • Mise en place d’une équipe : créez une équipe de migration avec des rôles clairs (responsable de projet, ingénieur des données, Synapse/SQL DBA, architecte Snowflake, administrateur 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 le succès, 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, l’étape suivante consiste à préparer l’environnement Snowflake et à traduire le modèle de sécurité d’Azure. L’hébergement de Snowflake sur Azure est fortement recommandé pour simplifier le transfert de données et l’intégration réseau.

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 Azure comme fournisseur Cloud ** et sélectionnez la même région que votre Azure Data Lake Storage (ADLS Gen2) pour 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 principaux Azure AD sur les rôles Snowflake :** traduisez les utilisateurs et groupes Azure Active Directory (AAD) dans le modèle hiérarchique de contrôle d’accès basé sur les rôles (RBAC) de Snowflake. Créez une hiérarchie de rôles fonctionnels (SYSADMIN, SECURITYADMIN) et de rôles d’accès (BI_READ_ONLY, ETL_READ_WRITE).

  • Configuration des politiques réseau et de l’authentification : définissez des politiques réseau pour restreindre l’accès aux adresses IP de confiance via Azure Private Link pour une connexion sécurisée. Configurez SSO en configurant Snowflake comme application d’entreprise dans Azure AD.

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

Cette phase implique la conversion du DDL basé sur le T-SQL, le DML, et le code procédural Synapse pour qu’ils soient compatibles avec Snowflake. Les outils d’automatisation peuvent accélérer ce processus, mais l’examen manuel est essentiel.

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 Synapse. Convertissez les types de données spécifiques à Synapse en leurs équivalents Snowflake (voir annexe 2).

  • Suppression des clauses spécifiques à la syntaxe : éliminez les clauses de distribution physique spécifiques à Synapse comme DISTRIBUTION (par ex., ROUND_ROBIN, HASH) et les stratégies d’indexation comme CLUSTERED COLUMNSTORE INDEX. Snowflake gère automatiquement la distribution et le stockage des données.

  • Réimplémentation ds contraintes : Snowflake applique uniquement les contraintes NOT NULL. Les contraintes PRIMARY KEY et UNIQUE sont informatives. Toute autre logique d’intégrité des données doit être déplacée dans votre ETL/processus ELT.

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

  • Réécriture des procédures stockées T-SQL : les procédures stockées T-SQL de Synapse doivent être réécrites dans un langage pris en charge par Snowflake, tel que Exécution de scripts Snowflake (SQL), JavaScript, ou Python.

  • ** Traduction des fonctions SQL :** mappez les fonctions Synapse/T-SQL spécifiques sur leurs homologues Snowflake (par exemple, GETDATE() devient CURRENT_TIMESTAMP(), ISNULL() devient IFNULL()). Voir l’annexe 3 pour les mappages courants.

Phase 4 : Migration des données¶

Cette phase se concentre sur le déplacement physique des données historiques de vos pools SQL Synapse vers des tables Snowflake. La méthode la plus efficace s’appuie sur Azure Data Lake Storage (ADLS Gen2) comme zone de mise en zone de préparation intermédiaire.

Vos étapes pratiques :

• Déchargement des données de Synapse vers ADLS Gen2 :

  • Utilisez la commande CREATE EXTERNAL TABLE AS SELECT (CETAS) dans Synapse pour exporter des données des tables vers un conteneur désigné dans votre compte ADLS Gen2.

  • Formatez les données en tant que Parquet ou CSV compressé pour des performances de chargement optimales dans Snowflake.

• ** Chargement des données de ADLS Gen2 vers Snowflake :**

  • Création d’une zone de préparation externe : dans Snowflake, créez un objet d’intégration de stockage pour une connexion sécurisée à ADLS Gen2, puis créez une zone de préparation externe qui pointe vers le conteneur avec vos données déchargées.

  • Utilisation de la commande COPY INTO : utiliser la commande COPY INTO <table> de Snowflake pour charger de la zone de préparation ADLS vers les tables cibles de Snowflake.

  • 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.

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, généralement dans Azure Data Factory, pour alimenter des données dans Snowflake.

Vos étapes pratiques :

• Migration des pipelines Azure Data Factory (ADF) :

  • Dans vos pipelines ADF, remplacez les ensembles de données et les activités Synapse par leurs équivalents Snowflake. Utilisez le connecteur natif de Snowflake dans ADF pour les activités d’entrée et de sortie.

  • Mettez à jour toutes les activités de recherche ou de script pour utiliser le dialecte SQL de Snowflake.

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

  • Pour les flux de données continus qui atterrissent dans ADLS Gen2, configurez Snowpipe. Snowpipe charge automatiquement et efficacement les nouveaux fichiers de données dans les tables Snowflake au fur et à mesure qu’ils arrivent, fournissant ainsi une solution d’ingestion en temps quasi réel. Cette opération peut être déclenchée par des notifications Azure Event Grid.

• 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 Power BI, pour interroger des données de Snowflake.

Vos étapes pratiques :

• Mise à jour des pilotes de connexion : vérifiez que Power BI et la passerelle de données sur site disposent des derniers pilotes Snowflake.

• Redirection des rapports Power BI :

  • Dans Power BI, modifiez la source de données de chaque rapport, en basculant la connexion d’Azure Synapse vers Snowflake. Le connecteur BI natif de Snowflake est certifié et fortement recommandé.

  • Testez l’ensemble des rapports et tableaux de bord critiques. Soyez attentif aux rapports à l’aide de DirectQuery, car les caractéristiques de performance vont changer.

• Examen et optimisation des requêtes :

  • Certains rapports peuvent contenir des requêtes T-SQL natives. Celles-ci doivent être refactorisées pour utiliser le dialecte SQL de Snowflake. Utilisez l’outil Profil de requête dans Snowflake et l’analyseur de performance dans Power BI pour optimiser les rapports lents.

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 Synapse 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 (SUM, AVG, MIN, MAX) sur des 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 Synapse 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 Power BI 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.

Phase 8 : Déploiement¶

Le déploiement est la dernière partie de la migration d’Azure Synapse 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 la migration. Ceux-ci incluent la mise en pause des pipelines ADF pointant vers Synapse, 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 Synapse vers Snowflake.

  • Conservez l’environnement Synapse disponible (mais en pause, si possible) pendant une courte période en tant que solution de secours avant la désactivation.

• Désactivation de Synapse :

  • Une fois que l’environnement Snowflake est stable et validé en production, vous pouvez désactiver les pools SQL Synapse 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.

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. Cela remplace le concept de mise à l’échelle des DWUs Synapse.

  • 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), 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.

  • Réglage de la sécurité : auditez régulièrement les rôles et les autorisations. 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 Architecture Azure Synapse¶

Annexe 2 : Mappages de types de données¶

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