Migrer une base de donnée avec Azure Data Factory

La migration entre bases de données, c’est souvent une opération périlleuse. Ce n’est déjà pas évident quand on parle de la même technologie, ça devient un vrai problème quand c’est des technologies qui n’ont rien à voir ! Heureusement, il existe des solutions pour vous éviter d’être prisonnier d’une solution qui peut être dépassée ou à remplacer. On va voir ci-dessous comment vous pouvez effectuer presque n’importe quelle migration avec Azure Data Factory.

Table des matières

Qu’est-ce qu’Azure Data Factory?

Azure Data Factory est un service qui permet de manipuler les données (son nom est bien choisi, n’est-ce pas?). Plus exactement, il va permettre de créer des process autour de la manipulation de données. On va parler notamment de transformation avec les notions d’ETL et d’ELT.

Au sens où ils chargent et manipulent la donnée, ils sont très proches d’outils tels que Power Bi par exemple (voir l’article). Mais là où ce dernier manipule ces données pour offrir des statistiques, les Datas Factory se concentrent uniquement sur la data. Les Datas Factory sont les outils dont vont se servir les logiciels de BI pour justement tirer profit des données. Et Power BI intègre directement les outils ELT/ETL.

Les Data Factory ont pour but de récupérer des données d’une source (base de données, fichiers, etc.), d’agir dessus, puis de les redéposer dans une source (là encore une base, un fichier…).

*Un outil de manipulation des données, en TRÈS simplifié*

Ce type de service est intéressant car :

Ils sont très graphiques, et donc simples à utiliser
Les « Data Factory » facilitent grandement la création process de traitement (pipeline) qui peuvent être complexe
Ils possèdent un grand nombre de connecteurs, ce qui permet de récupérer et/ou d’envoyer des données sur différent type de service
Les opérations de chargement / transformations sont optimisées pour traiter de grands volumes de données
Ils ont la possibilité d’être déclenchés par des événements externes (tâches régulières, API, etc.)

En l’occurrence, migrer ses données avec Azure Data Factory est un excellent moyen de vous faciliter la vie sur ce type d’opération risquée.

Pourquoi transformer les données ?

Il y a beaucoup de réponses à cette question. Les services tels qu’Azure Data Factory couvrent plusieurs besoins, et donc un grand nombre de scénarios.

Un exemple très courant est une migration d’une vieille base de données, dont les données sont devenues incohérentes avec le temps. Il m’arrive parfois en consulting de tomber sur des projets où les bases sont sans contraintes d’intégrité. La cohérence des données n’est donc plus assurée.

Imaginez un fichier Excel dans lequel vous listez si vos 458 utilisateurs sont pour ou contre recevoir une newsletter. Et que dans la colonne des réponses, vous avez les valeurs suivantes : 0,1,true,false,vrai,faux,ok,nok …
Ce genre de fichier devient vite inexploitable ! Impossible de sortir rapidement des statistiques avec ce type de problème.

Or, ce type de cas arrivent souvent dans de vieilles applications qui ont connu des développements hasardeux. Ou quand on tente de fusionner plusieurs sources de données sans les uniformiser préalablement (par exemple, si vous recueillez les avis via un Google Form d’un côté, une app mobile de l’autre, et que les données ont un format différent).

Les outils tels qu’Azure Data Factory permettent justement d’unifier les données, de les rendre cohérentes et conformes, pour permettre leurs exploitations futures.

*Exemple de cas d’utilisation d’Azure Data Factory pour fusionner différentes sources de données afin de les rendre exploitables, pour de la BI par exemple*

Créer le service Azure Data Factory

Pour cela, c’est assez simple. Sur votre console Azure, commencez à chercher le service et lancez la création d’un nouvel Azure Data Factory.

*Si vous n’en avez pas, l’option se présente directement à vous*

*La phase 1 est classique. Vous devez choisir où sera stocké le service, et sur quel subscription le crédit sera facturé*

La phase 2 quant à elle définit le dépôt Git où seront stockées les configurations que vous allez faire. Ces dernières seront ainsi versionnées. Vous n’avez pas besoin de comprendre / maitriser Git pour utiliser Azure Data Factory.

*Azure Data Factory vous propose d’utiliser vos propres clés de chiffrement à travers Azure Key Vault*

*Une fois le service installé, vous pouvez accéder à l’Azure Data Factory Studio depuis l’overview de votre service*

Préparer sa base de destination

Une étape importante pour migrer avec Azure Data Factory (ou d’autres), c’est d’avoir sa base de données de destination prête. En l’occurrence, l’important est que vous ayez transféré le schéma de la base de données. Ainsi, vous devriez retrouver sur votre base de destination :

Les tables de votre schéma, avec les colonnes et les types de données. Dans l’idéal, faites la migration « iso », avec les mêmes noms (quitte à faire des renommages en étape 2). Vous vous faciliterez ainsi la vie sur le mappage des données
Les index et les contraintes. Vous pouvez les désactiver ou les réinstaller après la migration (notamment si vous avez des dépendances circulaires). Si vous choisissez de le faire dans un second temps, pensez à prendre vos dispositions pour ne pas oublier
Les vues, les procédures stockées, les fonctions, les triggers …
Les tables doivent être vides. Si vous relancez une procédure de migration, il faudra vider les tables de vos données

Créer les connexions dans Azure Data Factory

Votre migration va se faire depuis une base, vers une autre. Vous devez par conséquent créer les connexions entre les deux qui nous serviront plus tard, lors de la création du pipeline de copie.

*La création de connexion se fait dans la section « Manage » d’Azure Data Factory*

*La force de l’outil est que vous pouvez vous lier à une grande quantité de sources de données*

⚠ Conseil sécurité

Lorsque vous paramétrez la connexion à votre service, vous avez deux solutions : la « connection string » avec mot de passe, ou Azure Key Vault. Choisissez toujours la seconde option ! En effet, pour rappel, le service stocke ses configurations dans le dépôt Azure DevOps ou Github que vous avez créé à cet effet. Ça implique que vos mots de passe stockés en clair ici seront sauvegardés sur ce stockage.

Aussi, si vous utilisez Azure key Vault, vous évitez de voir vos credentials « oubliés » sur un dépôt qui peut être piraté, ou accessible à des utilisateurs n’ayant pas l’autorisation d’accès à ces fameux credentials.

*Le paramétrage peut se faire par connection string, mais privilégiez toujours l’utilisation d’Azure Key Vault.*

Préparer le pipeline

Maintenant qu’on a préparé nos accès aux bases de données, on va pouvoir attaquer la migration à proprement parler. Pour cela, il existe deux cas d’utilisation. Le premier est très simple, et permettra de rapidement lancer la migration, et aussi de comprendre le fonctionnement de l’outil. Cependant, si vous avez des paramétrages spécifiques sur une table, ou des contraintes de Foreign Key que vous n’avez pas désactivé, vous risquez fortement d’avoir des problèmes.
Le second exemple est plus complexe, mais permet d’avoir plus la main sur le paramétrage.

Cas simple : l’assistant de copie

*L’assistant de copie se trouve dans le menu « Author » d’Azure Data Factory*

*L’outil de copie vous permet de créer un process programmable, ou de faire une copie exécutable manuellement*

*On sélectionne les différentes tables que l’on veut synchroniser. Il est aussi possible de passer par une requête.*

*On va ensuite mapper les table source et destination. Comme dit dans la section « préparation », le schéma doit déjà être présent sur la base de données de destination*

Le mappage des colonnes doit être OK. Si vous avez des erreurs, vous pouvez traiter la donnée en amont, supprimer les colonnes en souffrance, ou passer par la configuration de pipelines personnalisés pour utiliser l’ELT

*Vous pouvez paramétrer votre processus pour sa rapidité et sa gestion d’erreur. Ces paramètres peuvent se changer après-coup*

Vous pouvez exécuter la copie en cliquant sur le bouton « Debug ». Il est aussi possible de voir le code qui sert à générer la copie, avec la liste des tables et le mappage, en cliquant sur le bouton « code ». L’ensemble des tables se copieront en parallèle.

Cas avancé : utilisation des pipelines

*Vous pouvez créer des blocs « copie » unitairement pour une ou plusieurs tables, permettant de facilement paramétrer ou debuguer chacune d’entre elles*

L’utilisation des flèches permet de définir la priorité des actions. Le bouton « auto-align » rend votre graphique plus facilement lisible. Les événements se déroulent de gauche à droite. Tous les éléments d’une même « colonne » sont exécutés en parallèle.

Monitorer la migration

Une fois le débug lancé, il est important de pouvoir surveiller le bon déroulement des opérations. Pour cela, l’onglet « output » est votre allié ! Vous pourrez observer les process en cours d’exécution, leurs durées, et leurs états. Si vous cliquez sur le bouton d’information de la ligne, représenté par des lunettes, une popup d’informations complémentaire s’affichera, décrivant notamment la quantité de données à transférer.

L’écran vous permet de surveiller l’avancée de chaque process. Une icône vous indique si le process est en cours ou terminé. Chaque bloc (B1, B2, B3) s’exécute en parallèle. Le bloc suivant ne s’exécute que si l’ensemble de ses pré-requis, représenté par des flèches, sont terminés avec succès

*Sur un process en cours d’exécution, vous pouvez cliquer sur l’icône « lunettes » pour obtenir plus de détails sur la copie en question*

La gestion des erreurs dans Azure Data Factory

A moins que votre cas ne soit simple, ou que vous ayez déjà une certaine expérience dans le sujet, il est peu probable que votre migration se passe sans accroc dès la première tentative. Aussi, il est intéressant de savoir où glaner les informations. Je vous indiquerais aussi quelques cas d’erreur qui se sont présentés à moi, et comment je les ai résolues.

L’écran de débug (output)

L’écran de debug est la base. Il permet de suivre l’avancement des différents process, et leurs temps d’exécution (ce qui influe sur votre facture). En cas d’erreur, une fenêtre est disponible pour voir le message d’erreur, afin de le comprendre et si possible, de le résoudre.

La console de debug vous permet de suivre l’avancement des différents process et leurs statuts. En cas d’erreur, vous pouvez consulter le message d’erreur en passant votre souris sur la ligne, puis en cliquant sur le rapport.

*Les messages d’erreurs contiennent plusieurs sections utiles pour le debug*

La gestion des dépendances circulaires

Un des problèmes assez courants lorsqu’on souhaite migrer une table complexe, c’est lorsque vous avez des dépendances circulaires avec des ForeignKey. Vous pouvez très bien avoir un trio (ou plus) dont les éléments sont dépendants les uns des autres (pour des raisons diverses), et sur lequel vous ne pouvez pas directement insérer les données.

*Un exemple simple : si un user possède une liaison vers sa dernière utilisation de service, cela bloque la migration*

Souvent, cela provient d’un champ d’accès rapide à une ou plusieurs tables d’historique. Le champ est « nullable », ce qui ne pose aucun souci lors de l’utilisation du logiciel. Mais une fois rempli et utilisé, on ne peut migrer la ligne seule sans ses dépendances, mais la dépendance est circulaire.

Vous avez plusieurs solutions en ce cas :

Désactiver les ForeignKey pour la migration
Supprimer la ForeignKey, et la réinstaller après
Migrer les données, sans cette colonne / liaison qui est nullable. Faire une seconde étape de migration en rajoutant spécifiquement cette colonne aux données déjà existantes

Le fenêtrage

Les erreurs de fenêtrage proviennent du fait que les données à charger sont trop imposantes pour les paramètres utilisés, ce qui peut provoquer des timeout, des erreurs de réseaux…

Pour traiter cela, faites attention à savoir de quel côté l’erreur se produit. Une fois détecté, vous pouvez agir sur plusieurs paramètres :

💥 La quantité de données envoyées
🕙 La durée du timeout
🔱 Le type de traitement de l’information
💲 La puissance de la base de données ?

Limitations de bloc

Les pipelines sont limités à 40 blocs. Attention à ne pas paramétrer trop de choses à la fois. Si besoin, vous pouvez générer des templates pour les réutiliser. Il est aussi possible de copier / coller les éléments entre les pipelines, ou encore de passer directement par l’outil « code » pour les plus expérimentés.

Retour d’expérience sur la migration avec Azure Data Factory

Le coût

Le coût pour avoir migré avec Azure Data Factory n’est pas très élevé. Pour avoir fait plusieurs tests, avec une centaine de tables, et des centaines de gigas de datas à déplacer, la facture totale aura été de moins de 15€. Les services et applications de migration sont souvent beaucoup plus chers que cela.

La durée

Pour le schéma utilisé, le nombre de tables et le volume donné, il m’aura fallu un run de 5h ~ pour une migration complète.

Le bilan

Avantages :

Sécurité : le process est programmé. Aussi, il est aisé de faire des tests en répétant l’opération, pour être sur que tout soit opérationnel le jour J
Simplicité : Créer le processus est certes long, mais bien moins que de devoir tout coder soi-même !
Maintenabilité : Le pipeline étant très graphique, vous pouvez le conserver et le réutiliser plus tard sans soucis, pour d’autres types d’opérations
Souplesse : votre processus de copie est relativement indépendant de la base de données en face. Si votre structure de données reste la même, le mappage est très simple et rapide à refaire. Aussi, vous pouvez changer de base de données de réception très facilement.
Coût : J’avais peur que la facturation s’envole vite pour mon besoin, notamment car je savais avoir besoin de nombreux tests. Au final, la migration a été moins coûteuse que prévu.

Désavantages :

Prise en main : Lorsqu’on ne connait pas du tout l’outil, on ne sait pas par quel bout commencer (d’où cet article)

A DevOps journey