Réussir sa migration de Synapse vers Databricks

Azure Synapse a servi de base fiable pour l'analyse SQL à grande échelle, et les équipes qui l'ont adoptée ont fait un choix judicieux à l'époque. Cependant, une plateforme principalement conçue autour d'un entrepôt de données n'est pas taillée pour répondre à l'ensemble des besoins actuels des équipes chargées des données. Combler ces lacunes implique généralement d'ajouter des services, des intégrations et une surcharge opérationnelle supplémentaires, qui s'accumulent au fil du temps.

Migrer vers Databricks est un moyen de résoudre ce problème. Dans ce blog, nous abordons la manière d'aborder la migration depuis Synapse et les points clés à garder à l'esprit lors de son exécution.

Ce qu'une migration depuis Synapse permet de libérer

Parmi les projets de migration depuis Synapse que nous menons avec nos clients, trois leviers stratégiques reviennent systématiquement :

1. Patrimoine de données unifié. À mesure que les plateformes de données se développent, le nombre de services impliqués augmente également. Par exemple, les pools Synapse Analytics gèrent un ensemble de charges de travail, les pools Spark en gèrent un autre, et le SQL serverless fournit un accès ad hoc. Azure Data Factory est souvent associé à ces éléments pour orchestrer le tout. De nombreuses organisations ont également des charges de travail héritées SSIS qui doivent toujours être prises en charge. Aucun de ces composants n'est problématique de manière isolée. Cependant, le défi apparaît lorsque des services supplémentaires sont introduits, car cela ajoute une couche supplémentaire de gouvernance, de surveillance, de gestion des autorisations et de surcharge opérationnelle.
   Databricks résout ce problème en unifiant l'ingénierie des données, l'analyse, le machine learning et la gouvernance sur une plateforme unique. Plutôt que de naviguer entre des services aux modèles opérationnels différents, les équipes peuvent travailler sur la même architecture sous-jacente et le même cadre de gouvernance. Il en résulte une complexité réduite, moins de points d'intégration et une plateforme plus facile à exploiter à grande échelle.
2. Prêt pour l'avenir. L'attention des équipes de données modernes s'est désormais déplacée vers la prise en charge des modèles de machine learning, des pipelines de données en temps réel et des applications basées sur l'IA. Toutes ces charges de travail dépendent des mêmes données sous-jacentes. Le défi réside dans le fait que les architectures traditionnelles, centrées sur l'entrepôt de données, n'ont pas été conçues pour ce niveau de convergence et ciblaient principalement les besoins en BI. À mesure que les exigences s'étendent, les organisations se retrouvent souvent à ajouter de nouveaux services et outils spécialisés pour combler les lacunes de fonctionnalités.
   Databricks est conçu pour cette convergence, en unifiant les données, l'analyse et l'IA sur une plateforme unique. Avec Unity Catalog qui fournit une gouvernance cohérente pour les données, les notebooks et les actifs d'IA/ML, et Unity AI Gateway qui étend ces contrôles aux modèles, agents et applications d'IA, les organisations peuvent adopter de nouvelles charges de travail d'IA sans ajouter de nouveaux silos de gouvernance.
3. Efficacité opérationnelle. Bien que la plupart des analyses de rentabilité de migration commencent par les coûts de licence, c'est rarement de là que proviennent les économies les plus importantes. L'impact le plus fort provient souvent de la réduction du nombre de systèmes que les équipes doivent exploiter et maintenir. Moins de services signifie moins d'intégrations, moins de transferts entre outils et moins de problèmes potentiels.

Les organisations qui ont déjà franchi le pas constatent des résultats tangibles. Par exemple, Casey's, la troisième plus grande chaîne de magasins de proximité aux États-Unis, a migré son environnement d'analyse de Synapse vers Databricks Lakehouse (anciennement Databricks SQL), réduisant ainsi les délais de livraison des données opérationnelles de huit heures à quatre. Autre exemple, Italgas a simplifié son architecture en supprimant à la fois Synapse et Azure Analysis Services. L'entreprise a fait état d'une réduction de 73 % des coûts des charges de travail tout en alimentant à la fois Power BI et des analyses basées sur l'IA directement depuis Databricks.

Bien que les spécificités varient d'une organisation à l'autre, le modèle reste le même : des architectures plus simples, une livraison des données plus rapide et une plateforme mieux alignée sur les exigences imposées aux équipes de données modernes.

Comprendre ce que vous migrez réellement

Une chose qui prend souvent les équipes au dépourvu au début d'une migration Synapse est l'étendue de ce qu'elles déplacent. Bien qu'Azure Synapse soit souvent considéré comme une plateforme unique, il comprend en pratique une variété de services distincts opérant sous une seule marque, chacun d'eux pouvant nécessiter des stratégies de migration différentes et présentant un niveau de complexité variable.

La plupart des migrations consacrent la majorité de leurs efforts aux pools SQL dédiés, où la logique métier, les procédures stockées, les stratégies de distribution, les décisions d'indexation et les optimisations de performances se sont accumulées au fil des ans. Mais la complexité s'arrête rarement au SQL. La même migration doit généralement prendre en compte l'orchestration (Azure Data Factory et Synapse Pipelines), les autorisations et la gouvernance (autorisations SQL plus Microsoft Purview, avec un lignage souvent reconstitué manuellement), ainsi que la BI et la connectivité tierce (modèles sémantiques, rapports et outils en aval connectés directement aux points de terminaison Synapse). C'est la partie du patrimoine qui exige le plus de refonte, de tests et de validation – et celle qui est la plus susceptible d'être sous-estimée.

Les pools SQL serverless sont généralement plus simples, car ils fournissent principalement une couche de requête sur les fichiers d'un lac de données. Ici, la migration consiste principalement à rétablir des vues, des tables externes et des modèles d'accès plutôt qu'à reconcevoir des charges de travail complexes. Les pools Spark sont les composants les plus simples à déplacer, car Synapse Spark et Databricks sont tous deux basés sur Apache Spark et les notebooks peuvent souvent être migrés avec relativement peu de modifications.

Le point important est que ces composants évoluent à des rythmes différents, impliquent des parties prenantes d'horizons divers et présentent des risques différents. Les organisations qui abordent la migration comme un flux de travail unique avec un calendrier unique sous-estiment souvent à la fois l'effort et la complexité. C'est là que les délais commencent à déraper et que les programmes de migration commencent à dépasser leur portée initiale. Pour réussir, les équipes doivent structurer le parcours de migration.

Comment structurer la migration

Une migration de Synapse vers Databricks n'est pas un flux de travail unique. Vous déplacez trois modèles de calcul différents, consolidez la gouvernance, modernisez l'orchestration et retravaillez des années de logique T-SQL accumulée. Les équipes qui gèrent cela efficacement le traitent comme un programme structuré plutôt que comme un projet technique avec une approche par phases.

Découverte. Chaque migration commence par la compréhension de ce qui est réellement exécuté. Lakebridge Profiler analyse le patrimoine Synapse et collecte des métadonnées sur la configuration, l'utilisation des ressources, les modèles de requête et les références de performance. Les résultats sont utilisés pour élaborer une analyse de TCO.

Évaluation. Une fois l'inventaire établi, l'étape suivante consiste à comprendre la complexité. Lakebridge Analyzer évalue la base de code T-SQL, classe chaque objet par complexité, signale les structures non prises en charge et cartographie les dépendances. Les résultats peuvent être utilisés pour évaluer le calendrier de migration et les efforts associés, ainsi que pour définir la priorité des migrations d'actifs. Commencez par les charges de travail de complexité faible et moyenne (les gains faciles) et planifiez ensuite les efforts pour les cas d'usage les plus critiques.

Conception. Une fois le patrimoine visible, l'attention se porte sur l'architecture et la conception. La première décision concerne l'approche : lift-and-shift, modernisation ou hybride. Pour la plupart des migrations Synapse, l'approche hybride est la bonne solution. Des outils automatisés gèrent la majeure partie de la conversion du code pour quitter Synapse dans les délais, tandis que la modernisation se fait de manière progressive une fois que les charges de travail s'exécutent sur Databricks.

La deuxième décision concerne le séquençage. Une approche axée d'abord sur la BI a tendance à créer une dynamique plus rapidement que de commencer par l'ETL. Grâce à Lakehouse Federation, vous pouvez exposer les données Synapse via Unity Catalog avant même que les pipelines sous-jacents n'aient été déplacés. Un moyen pratique de commencer consiste à héberger d'abord les données enrichies destinées aux métiers (vos data marts) sur Databricks, puis à les mettre directement à la disposition des utilisateurs métier avec Genie pour des analyses en langage naturel. Les parties prenantes métier constatent rapidement les progrès et la valeur ajoutée, tandis que les équipes d'ingénierie modernisent l'ETL sous-jacent plus complexe. Lisez notre article de blog pour définir l'approche de migration qui vous convient.

Pilote. Avant de passer à l'échelle, la stratégie de migration doit être validée de bout en bout par rapport à une charge de travail réelle. Choisissez un cas d'usage phare, migrez-le de l'ingestion jusqu'à la consommation, et basculez-le en production. Un pilote permet de valider l'architecture, le modèle de gouvernance, les procédures de test et les outils dans des conditions réelles, et produit des actifs réutilisables pour les vagues suivantes.

Migration par vagues. Pour la phase de déploiement à l'échelle, une migration par vagues est recommandée. Chaque vague est conçue pour apporter un gain métier visible et établit une boucle de rétroaction avec les utilisateurs finaux.

L'exécution se déroule généralement sous la forme de quatre flux de travail parallèles : l'ingestion (déplacement des charges de travail ADF et Synapse Pipeline vers Lakeflow Connect), la transformation (migration des procédures T-SQL et de la logique métier vers Databricks), l'orchestration (déplacement des planifications et des dépendances vers Databricks Workflows) et la consommation (redirection des outils BI et des modèles sémantiques vers les Databricks SQL Warehouses). Leur exécution en parallèle permet aux équipes de générer de la valeur rapidement et de retirer Synapse selon un calendrier prévisible.

Databricks prend en charge les migrations Synapse sous plusieurs angles : le conseil et la mise en œuvre par notre équipe Forward Deployed Engineering, des partenaires Brickbuilder certifiés, et des accélérateurs comme Lakebridge qui automatisent le travail le plus lourd. L'objectif n'est pas seulement de mener à bien la migration, mais aussi de développer les compétences et le modèle opérationnel dont l'équipe a besoin pour pérenniser la plateforme bien après la fin du projet.

Ingestion de données

Avant de convertir le code SQL, les données doivent d'abord être ingérées dans le lakehouse. Databricks propose plusieurs options en fonction des systèmes sources et des exigences opérationnelles.

Pour de nombreuses sources d'entreprise courantes, Lakeflow Connect offre une expérience d'ingestion gérée avec des connecteurs intégrés et une gestion automatisée des pipelines. Parallèlement, Databricks repose sur des formats de stockage ouverts, ce qui permet aux organisations d'utiliser un large éventail d'outils d'ingestion tiers. Des solutions telles que Fivetran, Airbyte et d'autres plateformes ETL/ELT peuvent ingérer des données directement dans Delta Lake, permettant ainsi aux clients de s'intégrer aux écosystèmes d'intégration de données existants plutôt que d'être liés à un seul framework d'ingestion.

La conversion de code en pratique

Une fois les données disponibles dans le lakehouse, l'effort de migration se déplace vers la conversion de code, qui est généralement la phase la plus complexe de la migration. Bien que les outils automatisés gèrent la majeure partie de la traduction, généralement autour de 80 à 90 %, l'effort restant est consacré à l'affinage de la logique procédurale et à la résolution des modèles qui ne peuvent pas être traduits automatiquement.

Voici quelques différences à surveiller dans la syntaxe Synapse et Databricks.

Suppression des directives physiques

Le modèle de conversion le plus courant est la suppression des directives d'optimisation physique. Les Dedicated SQL Pools s'appuient fortement sur des constructions telles que la distribution HASH, la distribution ROUND_ROBIN, la distribution REPLICATE et les index columnstore clusterisés. Ces éléments sont fondamentaux pour le réglage des performances de Synapse, mais n'ont pas d'équivalent direct dans Databricks, ils sont donc généralement omis lors de la migration.

À la place, Databricks s'appuie sur l'optimisation du stockage et le Liquid Clustering pour améliorer les performances des requêtes. Le premier est géré automatiquement via l'optimisation prédictive, qui effectue en continu des opérations de maintenance telles que la compaction des fichiers, la collecte de statistiques et VACUUM pour les tables Delta. Le second est fourni par le Liquid Clustering, qui organise les données au sein des tables Delta à l'aide d'une ou plusieurs colonnes de clustering pour améliorer les performances des requêtes. Le choix des colonnes de clustering optimales dépend toutefois de la compréhension de la manière dont les données sont interrogées, une tâche souvent difficile en pratique et qui évolue fréquemment avec les charges de travail. Pour réduire cette charge opérationnelle, Databricks a introduit CLUSTER BY AUTO, qui identifie automatiquement et affine en continu les colonnes de clustering en fonction des modèles d'accès aux requêtes observés. Ensemble, ces fonctionnalités réduisent considérablement la quantité de réglages physiques manuels requis par rapport aux Dedicated SQL Pools.

Les décisions de conception physique qui nécessitaient un effort d'ingénierie important dans Synapse sont simplement abandonnées. La plateforme gère ce qui était auparavant manuel.

Remappage des fonctions

La plupart des fonctions T-SQL couramment utilisées ont des équivalents Databricks directs, et Lakebridge gère la grande majorité des mappages automatiquement.

La source de problèmes la plus fréquente n'est pas le mappage des fonctions en soi, mais les différences de comportement qui affectent les résultats de manière subtile. La comparaison de chaînes de caractères en est un bon exemple. Les Dedicated SQL Pools de Synapse fonctionnent généralement avec des collations insensibles à la casse, tandis que Databricks SQL est sensible à la casse par défaut. Une logique qui repose implicitement sur une correspondance insensible à la casse peut renvoyer des résultats différents après la migration. Si nécessaire, les comparaisons doivent être rendues explicites en utilisant LOWER() ou UPPER() des deux côtés. La conversion de syntaxe est généralement simple ; les différences sémantiques exigent plus d'attention.

Procédures stockées : migrer d'abord, optimiser ensuite

Grâce à la prise en charge native des procédures stockées dans Databricks, la plupart des procédures Synapse peuvent être migrées en conservant leur structure globale intacte. Les paramètres, les variables, la logique conditionnelle et les opérations DML sont tous pris en charge.

La procédure elle-même est rarement le problème. La complexity réside à l'intérieur : curseurs, traitement ligne par ligne, SQL dynamique et optimisations de performances spécifiques à Synapse. Ces modèles nécessitent du discernement, pas seulement une traduction.

SCD Type 2 : préserver l'historique avec Delta Lake

Les Slowly Changing Dimensions (SCD) sont l'un des domaines où les implémentations Synapse varient le plus. De nombreuses organisations ont accumulé des procédures stockées personnalisées et une logique de fusion au fil des ans. L'objectif de la migration n'est pas de reproduire exactement cette implémentation, mais de préserver l'exigence métier : conserver les versions historiques des enregistrements de dimensions tout en permettant d'interroger l'état actuel.

Une approche courante de Databricks utilise deux étapes. Tout d'abord, faire expirer les enregistrements qui ont changé. Ensuite, insérer les nouvelles versions.

Les transactions ACID de Delta Lake sécurisent ce modèle, même lorsque plusieurs opérations sont impliquées.

Gestion des erreurs

De nombreuses procédures stockées Synapse s'appuient sur des blocs TRY...CATCH pour capturer les échecs ou écrire des enregistrements d'audit. Databricks SQL fournit des équivalents natifs via des gestionnaires de conditions, de sorte que la plupart des modèles existants peuvent rester basés sur SQL.

Les scénarios simples comme la journalisation d'audit et les échecs contrôlés se traduisent généralement directement. Les flux de travail plus complexes peuvent nécessiter une conception supplémentaire, en particulier lorsqu'une coordination en aval via Databricks Workflows est impliquée.

Ce que nous enseigne l'expérience du terrain

Quelques leçons reviennent systématiquement lors des migrations Synapse, indépendamment de la taille de l'organisation ou de la complexité du patrimoine de données.

Commencez par l'évaluation, pas par la conversion. Exécutez Lakebridge Profiler and Analyzer avant d'écrire la moindre ligne de code converti. Clarifiez l'utilisation réelle, la portée, la complexité et les dépendances, puis utilisez ces données pour réduire la portée là où vous le pouvez.

Automatisez de manière agressive. Lakebridge gère 80 à 90 % de la conversion de code. Concentrez le temps d'ingénierie sur les 10 à 20 % qui nécessitent un jugement humain : curseurs, SQL dynamique, gestion complexe des erreurs.

Ne sous-estimez jamais la validation. En pratique, la validation demande souvent plus d'efforts que la migration elle-même. L'approche la plus efficace consiste à exécuter une réconciliation après chaque vague de migration, en comparant le nombre de lignes, les agrégations, les comparaisons d'enregistrements basées sur le hachage et les contrôles basés sur la tolérance pour les valeurs où une égalité exacte n'est pas appropriée. Lakebridge Reconcile prend cela en charge sur toutes ces dimensions. Pour les charges de travail critiques, l'exécution des deux environnements en parallèle avant la transition finale permet aux équipes de comparer les résultats côte à côte pendant que les utilisateurs continuent de travailler avec leurs rapports habituels.

Évitez de penser uniquement au format Synapse. La conception des tables en est un bon exemple. Les équipes tentent fréquemment de mapper directement les clés de distribution HASH de Synapse sur les colonnes de partition Delta Lake. Dans la plupart des cas, cela introduit une complexité inutile et de mauvaises performances. Les valeurs à forte cardinalité telles que les ID client ou les ID commande conviennent rarement comme clés de partition et sont souvent mieux gérées via le clustering liquide et les capacités d'optimisation automatisées de Databricks, comme la maintenance prédictive.

Ne recréez pas ce que la plateforme gère désormais. Les migrations offrent l'opportunité de simplifier les architectures plutôt que de les reproduire à l'identique. Delta Lake, l'optimisation automatisée et les modèles de lakehouse modernes éliminent bon nombre des techniques de réglage manuel qui étaient nécessaires dans les environnements d'entrepôt traditionnels. Transposer chaque décision d'optimisation historique dans Databricks préserve souvent d'anciennes contraintes sans pour autant conserver les raisons pour lesquelles ces contraintes existaient.

Préparez l'opérationnalité. Les tables Delta accumulent naturellement de petits fichiers au fil du temps à mesure que les charges de travail incrémentielles s'exécutent. Sans processus de compaction et de maintenance, les performances peuvent progressivement se dégrader. Les équipes issues de plateformes d'entrepôts de données traditionnelles sont souvent surprises de voir que l'optimisation du stockage fait partie intégrante du modèle opérationnel continu. Ce n'est pas difficile à gérer, mais cela doit être planifié dès le départ.

Planifiez la gestion du changement. La plupart des équipes Synapse découvrent Databricks, et le sous-investissement dans la montée en compétences est l'une des raisons les plus courantes pour lesquelles les projets manquent leurs objectifs d'adoption. Traitez le plan de montée en compétences avec autant de sérieux que le plan technique.

Évitez de décommissionner Synapse trop tôt. La plupart des migrations réussies maintiennent l'ancien environnement disponible pendant une certaine période après le déplacement des charges de travail de production. Les ressources de calcul peuvent être suspendues pour minimiser les coûts tout en préservant une option de retour en arrière en cas de problèmes imprévus. Plus important encore, le maintien de ce filet de sécurité donne confiance aux parties prenantes de l'entreprise pendant que la nouvelle plateforme fait ses preuves en conditions réelles.

Migrer de Synapse vers Databricks est rarement un simple projet technologique. À la base, cela consiste à simplifier une plateforme devenue de plus en plus complexe au fil du temps, tout en établissant des fondations capables de prendre en charge la prochaine génération de produits d'analyse, d'AI et de données. Bien que le travail technique soit important, les organisations qui bénéficient le plus de ces migrations sont celles qui profitent de l'occasion pour simplifier leur architecture, éliminer la complexité inutile et moderniser simultanément leurs pratiques opérationnelles. Le plus grand avantage est d'aboutir à une plateforme de données plus simple à exploiter, plus facile à faire évoluer et mieux alignée sur l'orientation future de l'organisation.

Que faire ensuite

Si vous êtes au début d'une migration Synapse :

• Exécutez Lakebridge Profiler and Analyzer sur votre environnement. Obtenez les données avant de définir la portée des travaux.
• Lisez le blog Migration Strategy: Lessons Learned et l'eBook Transforming Legacy Data Warehouses.
• Si vous souhaitez une aide pratique, l'équipe Databricks FDE et les partenaires de migration certifiés réalisent les migrations Synapse de bout en bout.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original