Un cadre de décision pour la migration ETL vers Databricks

Votre équipe dispose de centaines de procédures stockées, de quelques planificateurs, de permissions éparpillées entre les rôles et les schémas, et la date limite de renouvellement de votre data warehouse cloud approche. Personne ne s'accorde sur ce qu'il faut migrer en premier. Certains veulent tout réécrire en PySpark. D'autres veulent migrer le SQL en l'état et s'en tenir là. Les grands oubliés de la discussion : les métadonnées, le lignage et les permissions qui accompagnent le code, sans oublier l'opportunité de les consolider au passage.

Aucun de ces extrêmes ne fonctionne. Les équipes qui réussissent leur migration de data warehouse analysent chaque charge de travail individuellement et choisissent le bon outil pour chaque tâche. Cet article propose un cadre de décision pour vous guider : quand utiliser Lakehouse (Databricks SQL), Spark Declarative Pipelines ou PySpark, et comment planifier le travail par étapes pour livrer des résultats concrets plutôt que de faire du surplace.

Trois voies, une seule migration

Sur Databricks, vous pouvez migrer les pipelines ETL de trois manières principales, souvent complémentaires.

Lakehouse (Databricks SQL)

C'est la voie la plus directe pour les équipes très axées sur le SQL. Elle couvre un large éventail de cas, du plus simple au plus complexe. Elle s'exécute sur des SQL warehouses, accélérés par Photon par défaut et entièrement compatibles avec ANSI et Spark SQL (%sql). Choisissez Serverless pour les charges de travail variables ou imprévisibles (démarrage rapide, mise à l'échelle à zéro, paiement à la seconde). Choisissez Classic pour les charges de travail régulières ou lorsque vous avez besoin de contrôles réseau ou de coûts spécifiques.

Une tâche SQL simple :

Lorsque la logique nécessite un contrôle de flux (conditions), des boucles, des variables, la gestion des erreurs ou une exécution pilotée par des paramètres, les procédures stockées vous apportent cette couche procédurale. Elles sont gouvernées via Unity Catalog et peuvent être appelées depuis Workflows avec des paramètres.

La règle d'or : si votre code hérité est une simple instruction SQL, migrez-le sous forme de tâche SQL. S'il contient une logique procédurale (variables, boucles, paramètres, gestion des erreurs), encapsulez-le dans une procédure stockée, gouvernée par Unity Catalog et appelable depuis Workflows. N'encapsulez pas un SQL simple dans une procédure uniquement parce que le système d'origine l'exigeait.

Spark Declarative Pipelines (SDP)

Qui fait partie de Lakeflow, adopte une approche différente. Vous déclarez ce que votre pipeline doit produire et le moteur gère l'ordre d'exécution, les tentatives et la mise à l'échelle. Vous bénéficiez de contraintes de qualité des données intégrées, d'une résolution automatique des dépendances et d'une approche unifiée batch et streaming dans la même définition.

Sous le capot, Enzyme décide quand effectuer une mise à jour incrémentielle ou recalculer entièrement les tables dérivées. L'autoscaling ajuste la capacité en fonction des variations du volume de données, sans intervention manuelle. Des entreprises comme Block s'appuient sur ce modèle déclaratif pour simplifier l'orchestration des pipelines à mesure que l'utilisation augmente.

PySpark et notebooks Spark SQL

Qui vous offrent un contrôle total. Ils s'exécutent sur des clusters de jobs et gèrent les charges de travail qui ne conviennent pas à un SQL Warehouse ou à un pipeline déclaratif.

Optez pour PySpark lorsque la charge de travail nécessite une logique métier complexe, de l'ingénierie de fonctionnalités ML (feature engineering), des intégrations d'API ou des validations personnalisées. L'exemple ci-dessous évalue des transactions à l'aide d'un modèle enregistré dans Unity Catalog :

Optez pour Spark SQL dans un notebook lorsque le langage reste le SQL mais que la charge de travail dépasse les capacités d'un SQL Warehouse : très grandes tables, shuffles importants, ETL batch de longue durée pour lesquels vous souhaitez un contrôle explicite sur le partitionnement, les jointures de type broadcast ou la mise en cache.

Activez Photon sur le cluster de jobs pour les travaux SQL ou DataFrame limités par le calcul : jointures volumineuses, agrégations, fonctions de fenêtre (window functions), scans de grandes tables colonnaires. Photon est un moteur natif et vectorisé qui accélère ces modèles sans modification de code, y compris pour les UDF Pandas (basées sur Arrow). Évitez Photon lorsque les UDF Python par ligne prédominent, que les jeux de données sont petits ou que le job est purement limité par les I/O.

Les notebooks s'intègrent également très bien dans les pipelines hybrides : ingestion dans SDP, enrichissement dans une tâche de notebook.

Matrice de décision

Le tableau ci-dessous est un point de départ pour les discussions d'équipe, pas une règle absolue.

Grille de décision rapide

Trouvez votre équipe dans les colonnes et la complexité de votre charge de travail dans les lignes. La cellule correspondante vous indiquera par où commencer.

Quatre phases plutôt qu'un « big bang »

Plutôt que de décider d'une « approche globale unique », déterminez « la prochaine étape » pour chaque phase.

Phase 1 — Évaluer. Collectez les métriques de votre entrepôt de données hérité : temps CPU, temps d'exécution, fréquence, tables sources et cibles. Classifiez les charges de travail par complexité. Utilisez des outils de migration, si possible, pour créer un inventaire évalué selon la valeur par rapport à la difficulté. L'endroit où vous trouverez ces données dépend de la source. Sur Teradata, interrogez DBC.QryLog. Sur SQL Server, utilisez sys.dm_exec_query_stats. Sur Oracle, les rapports AWR. Sur Snowflake, QUERY_HISTORY. Les détails peuvent varier. Si vous disposez déjà d'un outil d'intégration, vous pouvez exploiter ses métadonnées pour identifier les relations entre les tables, ou vous appuyer sur un LLM pour vous aider à construire cette traçabilité (lineage). Le résultat est une carte, pas un plan de réécriture. L'objectif reste le même : classer les charges de travail par consommation de ressources et par niveau de dépendance afin de savoir par où commencer. Bien menée, cette évaluation prend quelques jours à l'aide d'outils de migration, et non des semaines de scripts manuels.

Phase 2 — Victoires rapides. Choisissez des charges de travail qui combinent un faible risque de migration avec des cas d'usage à forte visibilité commerciale. Cela peut signifier commencer par des tâches SQL lourdes et faciles à convertir, ou par des pipelines de reporting qui présentent rapidement la nouvelle plateforme aux parties prenantes. Les instructions simples deviendront des tâches SQL dans Workflows. La logique procédurale devient des procédures stockées. Utilisez des transpileurs et la conversion assistée par AI pour la traduction initiale. Exécutez les deux systèmes en parallèle et comparez le nombre de lignes, les sommes de contrôle (checksums) et les enregistrements d'échantillon. Le but est de renforcer la confiance, tant sur le plan technique qu'organisationnel.

Walgreens, par exemple, a retiré son infrastructure Teradata sur site lors d'une migration progressive et traite désormais environ 40 000 événements de données par seconde sur le lakehouse, alimentant l'optimisation de la chaîne d'approvisionnement dans près de 9 000 magasins.

Phase 3 — Moderniser. Redessinez maintenant les pipelines qui méritent d'être modernisés. Les candidats idéaux : les flux où les contraintes de qualité des données et la traçabilité (lineage) réduisent les vérifications manuelles, les tâches par lots (batch) qui bénéficient des tables de streaming et du CDC, les pipelines où les vues matérialisées réduisent la complexité, ainsi que les métadonnées, les autorisations et l'audit qui résidaient auparavant dans des outils distincts, désormais consolidés sous Unity Catalog. Un modèle courant consiste à conserver la procédure héritée comme solution de secours pendant que le nouveau pipeline fonctionne en parallèle jusqu'à ce qu'il soit validé. Les pipelines modernisés réduisent souvent les fenêtres de traitement par lots d'heures en minutes et éliminent le besoin d'outils de DQ distincts.

Phase 4 — Optimiser. Consolidez les pipelines ETL redondants qui n'existaient que pour contourner les limites de l'ancien DW. Déplacez les points chauds complexes vers PySpark lorsque cela simplifie la logique. Reconsidérez les frontières entre traitement par lots (batch) et streaming maintenant que vous disposez d'un moteur unifié. C'est là que la migration porte ses fruits : l'ancienne plateforme est éteinte, les pipelines redondants ont disparu et l'architecture fonctionne sur un seul système au lieu de deux.

La place des outils de migration et de l'AI

Les outils de migration automatisent le travail mécanique mais ne remplacent pas les décisions architecturales. Trois rôles typiques :

• Profilage et évaluation. Découvrez les procédures stockées, les scripts SQL et les tâches ETL. Cartographiez les dépendances. Lakebridge propose un composant Analyzer qui analyse les anciennes plateformes d'entrepôt de données et génère un inventaire des objets, des modèles d'utilisation et de la complexité.
• Conversion de code. Traduisez le SQL et l'ETL de Teradata, Oracle, SQL Server, DataStage, Informatica et SSIS en pipelines Lakehouse ou déclaratifs. Le Converter de Lakebridge gère les procédures stockées et les flux ETL, avec des recommandations publiques faisant état d'une automatisation allant jusqu'à 80 % et de délais de projet environ deux fois plus rapides.
• Validation. Comparez les résultats entre les systèmes grâce à des vérifications automatisées des schémas, du nombre de lignes et des agrégats. Lakebridge comprend un outil de validation (validator). La méthodologie de migration de Databricks traite la réconciliation comme une phase de premier ordre, et non comme une réflexion après coup.

Une approche pragmatique : laissez les outils prendre en charge 60 à 80 % de la conversion initiale et réservez le temps des ingénieurs pour les modèles que vous souhaitez réellement moderniser. Cela évite de transférer la dette technique à l'identique.

Ce qui est supprimé

Les migrations réussies mettent activement hors service les anciens systèmes, au-delà de la simple conversion de code : serveurs de planification (schedulers) autonomes, frameworks de DQ personnalisés, outils de traçabilité (lineage) et de métadonnées distincts, compilateurs de procédures stockées propres aux fournisseurs et outils de validation développés en interne. La migration n'est pas terminée tant que ces systèmes ne sont pas éteints et que les factures ne cessent de tomber.

Trois anti-patterns qui freinent les migrations

• Choisir une seule voie pour tout sans tenir compte des compétences de l'équipe, du profil de risque et du type de charge de travail. L'équipe qui ne jure que par le SQL passe à côté des opportunités de modernisation. L'équipe 100 % PySpark réécrit du SQL simple sans aucune raison.
• Mesurer uniquement le « pourcentage migré » tout en ignorant la durée de l'exécution en parallèle, le temps de validation et la mise hors service réelle des anciens systèmes. Cinquante pour cent de migration ne signifie rien si l'ancienne plateforme d'entrepôt de données fonctionne toujours à plein coût.
• Recréer d'anciens planificateurs (schedulers) et couches intermédiaires sur le lakehouse au lieu d'utiliser des workflows et des pipelines déclaratifs. La migration est une occasion de simplifier l'orchestration des pipelines. Saisissez-la.

Si l'ETL SQL reste fragmenté entre différents moteurs, couches et outils, la plateforme reste fragmentée, même si les données reposent sur des formats ouverts.

Il n'y a pas une seule bonne façon de migrer des pipelines de données. Le Lakehouse vous y amène rapidement : des tâches simples pour une logique simple, des procédures stockées lorsque vous avez besoin d'un contrôle procédural. Le SDP vous offre des pipelines ETL modernes avec qualité et traçabilité (lineage) intégrées. Les Notebooks gèrent le reste, que vous fassiez appel à PySpark ou à Spark SQL. Échelonnez le travail, commencez par des victoires rapides et utilisez tous les accélérateurs possibles.

Explorez le guide de migration Databricks pour des démonstrations techniques, ou essayez par vous-même avec Databricks Free Edition.

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