Sommaire
Introduction
Aujourd'hui de nombreux outils sont disponibles pour vous aider à mettre en place et à effectuer vos migrations de données. L'outil qui vous est proposé vise la simplicité et la flexibilité. En effet il ne dépend d'aucune librairie annexe et accepte tout les protocoles d'accès aux données.
La problématique
La problématique de la migration de données est nécessaire quand il faut procéder au changement ou à la mise à jour de systèmes informatiques. Cet outil a donc été développé pour faciliter la migration de données car cette opération est généralement longue, fastidieuse et surtout comporte des risques non négligeables.
Une migration de données est un processus à préparer avec précautions car on ne sait jamais immédiatement si le processus se passera bien, si les données vont être préservées, … voici une liste (non exhaustive) d'étapes clés d'une migration de données.
- Préparation des données à migrer, on va déterminer le type de migration a effectuer. Par exemple migrer des données d'un github vers un gitlab ou passer des données d'une version X à une version Y.
- Choix des moyens de migration utilisés, il existe plusieurs outils comme Django, SQL direct, et maintenant celui que nous vous proposons.
- Réservation du temps de migration, plannification de la migration avec l'équipe, cette étape nécessite du temps, on va également choisir l'heure d'execution, la mise en place éventuelle d'alertes, …
- Sauvegarde des données, c'est une étape clé pour la réussite de la migration car elle permet de protéger les données d'une éventuelle erreur, en les sauvegardant, on peut si besoin revenir en arrière, le système ne sera donc pas impacté (ou très peu) par l'erreur. Dans cette étape on va aussi déterminer les mesures à prendre en cas d'erreur et quelles sont les informations à remonter après chaque migration.
- Migration, cette étape consiste à lancer la migration des données.
La migration de données d'une version X à une version Y va être prise comme exemple pour vous expliquer le fonctionnement de l'outil présenté.
Solution apportée
Habituellement, toutes les personnes qui vont intervenir sur les données doivent connaître la structure de ces données et/ou les impacts de la migration sur le système.
L'outil va faciliter ce travail en automatisant la préparation des données et le choix des moyens de migration car il vous suffit de ce seul outil pour gérer toute votre migration.
Le programme permettra donc un gain de temps et de ressources humaines, il sera utilisé directement dans Canopsis (pour plus d'information sur ce logiciel : http://linuxfr.org/news/presentation-technique-de-canopsis). Des protocoles d'accès aux storages ont été développés pour que Canopsis puisse faire de la migration de données entre storages.
L'outil peut également être utilisé en dehors de Canopsis car il est totalement indépendant de celui-ci. Cet outil est basé sur la notion de schéma, un schéma va décrire la structure de vos données et va ensuite servir à valider cette structure avant d'utiliser les données.
Fonctionnement
Pour le moment la migration est basée sur des schémas JSON mais par la suite, il sera possible d'utiliser également d'autres formats comme XML par exemple. En effet, une factory qui va récupérer le format de vos schémas et ensuite appeler la classe traduisant les fonctions particulières au traitement de ce format a été développée, cette classe est abstraite ce qui va vous permettre de rajouter une classe définissant les fonctions particulières à un format (JSON, XML, …).
Les schémas vont être traités par la classe Schema qui va utiliser les fonctions traduites par la classe correspondante au format des schémas, ici JsonSchema.
Les Patch de transformation vont être identifiés et traités par la classe Patch qui va appeler les fonctions traduites par la classe correspondante au format du patch, ici JSONPatch.
La classe transformation va instancier les classes patch et schéma, récupérer les informations nécessaires à la transformation des données et appliquer la transformation.
Avant de lancer votre migration de données, il vous faudra écrire les documents suivant :
- document de transformation : il regroupe les informations nécessaires à votre migration.
À savoir :
- Input/Output : ex : file:///dossier/sous_dossier/fichier.json; Les informations d'input/output servent à donner au programme les protocoles d'accès aux données mais aussi à renseigner les chemins d'accès aux schémas de structure des données entrantes et sortantes, un filtre éventuel, le format des données, … - patch : tableaux des opérations de transformation
Vous pouvez également ajouter d'autres champs si vous en avez besoin comme un filtre pour sélectionner les données.
Pour reprendre l'exemple :
Une donnée en version X « Madonnee » qui se trouve dans un dossier « Mondossier »
Dans l'exemple, on va migrer cette donnée d'une version X, vers une version Y, ma donnée se verra alors ajouter un champ « name ».
Il faut, dans un premier temps, écrire les schémas d'entrée et de sortie appelés respectivement VX et VY.
{
"$schema": "http://json-schema.org/draft-04/schema#", #ligne d'héritage du schéma
"id": "file://Mondossier/VX.json", #id du schéma, identifiant unique
"title": "VX",
"description": "exemple schema VX",
"type": "object", #type de schéma, peut être array, object, item
"properties": {
"version": {
"type": "string"
}
}
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"id": "file://Mondossier/VY.json",
"title": "VY",
"description": "exemple schema VY",
"type": "object",
"properties": {
"version": {
"type": "string"
},
"name": {
"type": "string"
}
}
}
Ensuite le document de transformation de cet exemple, pour rappelle vous pouvez le personnaliser pour vos propres migrations.
{
"id": "X:Y", #identifiant unique du document
"patch": [
#cette opération va ajouter le champ « name » qui aura pour valeur « Madonnee »
"op": "add" ,
"path": "/name",
"value": "Madonnee",
#cette opération va remplacer la valeur actuelle du champ « version » par « 2.0.0 »
"op": "replace",
"path": "/version",
"value": "2.0.0"
],
"output": "file:///Mondossier/Madonnee",
"input": "file:///Mondossier/Madonnee", #file:// est un protocole qui va utiliser la migration pour un fichier, il est fourni avec l'outil et va nous servir d'exemple pour la suite des explications.
}
Pour personnaliser votre migration, vous pouvez créer vos propres protocoles d'input/output et leur associer des IOInterfaces spécifiques aux protocoles que vous voulez.
Le patch de transformation est lui aussi entièrement malléable à vos besoins, vous pouvez écrire autant d'opérations que vous souhaitez et celles que vous souhaitez (add, copy, move, remove, replace). Si vous ne souhaitez que déplacer vos données, tant que vous lui fournissez les schémas de structure et le document de transformation vous pouvez ne pas ajouter le patch au document de transformation.
La migration est gérée par la fonction migrate(). Elle prend en paramètre le chemin vers le document de transformation et effectue votre migration.
La définition d'un nouveau protocole d'accès aux données se fait simplement et dynamiquement à l'aide du design pattern factory qui fournit des objets héritant de l'interface IOInterface. Il suffit d'hériter de cette interface pour que le nouveau protocole soit automatiquement enregistré par la factory et utilisable à partir d'un document de migration.
Cela vous permet d'implémenter votre propre classe d'IOInterface, ainsi vos données peuvent être migrées de n'importe quel input vers n'importe quel output. Vous pouvez donc par exemple créer vos propres protocoles d'input/output et choisir le comportement de la migration par rapport à ce protocole.
Pour utiliser la migration il vous suffit d'importer le module de migration et de taper la commande qui suit dans Python :
from schema.migration.core import migrate
migrate(path_transfo)
#path_transfo : chemin d'accès vers le document de transformation
Conclusion
Cet outil est entièrement malléable et simple grâce à plusieurs choses :
- le développement des factory
- la mise en place d'une metaclasse
- l'implémentation d'IOInterfaces
- acceptation de tous les protocoles d'accès aux données
- dépendance à aucune librairie tierce
Vous pouvez télécharger cet outil sur : https://git.canopsis.net/jvanglabeke/data_migration.git
installation : pip install data_migration
Je remercie les gérants du projet Canopsis Mr. Mikaël Mourcia et Mr. Edouard Huault qui ont financé le développement de ce projet.
# une catastrophe se prépare
Posté par steph1978 . Évalué à 5. Dernière modification le 14 septembre 2016 à 11:52.
Tu illustres bien la nécessité de sauvegarder ses données avant de les migrer.
J'ajouterai une étape dans ta procédure qui consisterai en la validation des données migrées.
Par exemple est-ce que ton application en version VY arrive bien à lire toutes les données.
Bien souvent des cas limites échappent longtemps à une élaboration de processus de migration…
Le risque à ne pas le faire est de s'apercevoir après un usage prolongé de VY que des données sont invalides. Comme, par ailleurs, des données auront été modifiées et ajoutées, il sera très difficile voire impossible de rejouer une migration VX->VY corrigée et il faudra refaire pas mal de reprise à la main.
[^] # Re: une catastrophe se prépare
Posté par b3j0f . Évalué à 1.
Il me semble que l'article sous-entend que les données en sortie sont validées par le schéma de sortie, sinon, quel est l'intérêt de demander un "SCHEMA VY" ?
Après, entre ce qui est sous-entendu et ce qui est réellement fait, il y a souvent un gap :)
L'auteur pourra nous rassurer sur la question…
[^] # Re: une catastrophe se prépare
Posté par steph1978 . Évalué à 5. Dernière modification le 14 septembre 2016 à 17:09.
La schéma qui est présenté ici est principalement utilisé pour décrire la transformation à faire : ajouter un champ name, changer le champ version.
Mais il n'est pas issue du ou des logiciels qui vont utiliser les données. Donc rien ne te garantie que les données produites seront utilisables par le logiciel.
[^] # Re: une catastrophe se prépare
Posté par David Delassus (site web personnel) . Évalué à 3.
Ce qui signifierai qu'il faudrait que le driver utilisé en Input et en Output soit capable d'extraire le schéma afin que ce ne soit pas l'utilisateur qui le fasse.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: une catastrophe se prépare
Posté par steph1978 . Évalué à 3.
C'est une possibilité qui fiabiliserait le procédé en effet.
Après, aucun langage de schéma n'a la sémantique suffisante pour décrire n'importe quelle règle de gestion implémenté dans un logiciel. D'autant que beaucoup sont implicites et découle seulement de l'implémentation.
Bref, rien ne remplace une phase de qualif AMHA.
[^] # Re: une catastrophe se prépare
Posté par b3j0f . Évalué à 2.
En plus de décrire les opérations à effectuer pour la migration (patch), il référence également les schémas des données en entrée et en sortie qui valident les données en entrée et en sortie.
Oui, on supposera que le schéma de sortie correspond bien au logiciel qui vont utiliser les données en sortie. Il convient alors de s'assurer en amont que le schéma de sortie soit valide.
[^] # Re: une catastrophe se prépare
Posté par lyly . Évalué à 2.
Bonjour,
Tout d'abord Merci pour les commentaires, pour le moment l'outil n'est encore qu'en version 0.1, le développement n'est pas finit. Par la suite nous voulions intégrer d'autres outils pour l'enrichir comme par exemple un outil qui permettrait à l'utilisateur de ne pas avoir à écrire les schémas de structure.
Bonne journée à tous
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.