Il y a quelque temps, Microsoft a annoncé un type de job particulier, les « Copy job » : Announcing Public Preview: Copy Job in Microsoft Fabric | Microsoft Fabric Blog. Dans de nombreux projets, pour des raisons d’impact sur les bases opérationnelles, nous faisons des copies des données sources pour travailler de façon autonome par la suite. Ce type de job est justement là pour traiter ce cas d’usage et nous allons faire un petit essai sur son utilisation.
Près requis
En soi, le « Copy job », ne demande pas de près-requis. Dans cet article, nous allons cependant utiliser une source SQL Serveur OnPrem que nous allons attaquer via une passerelle de donnée. La passerelle est la même que celle utilisé pour PowerBI. Si vous en avez déjà une, vous pouvez l’utiliser ou en installer une : How to access on-premises data sources in Data Factory – Microsoft Fabric | Microsoft Learn
Création du Copy job
Pour créer notre job de copie, nous allons ajouter un nouvel item dans notre workspace et chercher « copy ». Nous trouverons facilement le « Copy job » qui existe dans plusieurs catégories.
La première étape consiste à nommer notre job pour le reconnaitre facilement.
Nous sommes maintenant confrontés à un wizard qui va nous permettre de configurer notre job depuis la connexion à la donnée source, jusqu’à sa destination.
Pour notre cas d’usage qui est la récupération de données depuis notre SQL Server OnPrem, nous allons sélectionner la source appropriée qui est généralement accessible directement sur la première page. Sinon, il suffit de la rechercher.
Nous allons maintenant nous connecter directement à notre base de données via la passerelle de données.
Si la connexion existe déjà, nous pourrons la réutiliser. Le wizard détectera automatiquement une connexion existante grâce au serveur et la base de données renseignée. Nous pourrons malgré tout en utiliser une nouvelle si nous voulons par exemple utiliser une autre passerelle ou un autre utilisateur.
Une fois connectés, nous nous retrouvons devant une interface assez similaire à ce qui existe côté PowerQuery, ou nous pouvons sélectionner nos tables (et vues), tout en ayant un aperçu des données pour nous aider dans notre décision.
Après avoir défini nos sources de données, nous allons choisir la destination. Et encore une fois, si notre destination existe déjà, il nous suffira de la sélectionner, et sinon de la créer directement dans le wizard. Nous commençons à peine dans l’utilisation de Fabric et l’extraction de données, nous allons donc créer un nouveau Lakehouse qui correspondra à notre zone « Bronze » de l’architecture Médaillon.
Pour notre nouveau Lakehouse, nous avons l’opportunité de choisir le workspace qui l’hébergera. Effectivement, si les workspaces servent à « cloisonner », nos données et nos développements, nous pouvons tout à faire interagir depuis un workspace sur un autre. Ceci relève d’un choix d’architecture et dans mon cas, je vais faire regrouper dans le même workspace les jobs et les données « par zone ».
Nous allons maintenant définir le mapping des données sources vers notre destination. Etant dans un lakehouse, nous pouvons choisir d’écrire « simplement » des fichiers ou directement des tables (qui seront au final des fichiers « delta parquet »).
Nous allons ici travailler au niveau table afin de « faciliter » la lecture après la copie. Nous avons maintenant deux niveaux de mapping disponibles. Le premier est au niveau « table ». Nous pouvons choisir le nom de la table de destination dans notre lakehouse.
Et nous avons le deuxième niveau qui nous permettra de travailler notre mapping au niveau colonne.
Options d’alimentations
Nous pouvons maintenant choisir le mode de copie que l’on souhaite. Avec une base SQL comme source de donnée, nous ne pourrons pas faire du Streaming, mais nous aurons le choix entre « Full copy » ou « Incremental copy ».
Full copy
Le mode full copy fera une extraction complète à chaque exécution sans filtres. Cela revient à faire un snapshot lors de chaque exécution et nous serons libres de traiter les évolutions (ou non) dans nos zones/étapes suivantes.
Dans ce mode de fonctionnement, il n’y a rien à configurer de plus.
Incremental copy
Dans ce mode, nous allons uniquement traiter les « modifications » de données. On parle d’alimentation incrémentielle ou de « delta ». Ce mode nous permet d’alléger considérablement nos traitements, car nous n’allons pas recharger l’intégralité de nos données à chaque exécution comme ce serait le cas pour le Full copy.
Il existe malgré tout une contrainte forte lorsque l’on travail avec de l’incrémental. Nous avons besoin d’une colonne sur laquelle se baser pour définir la portion de donnée à récupérer à chaque traitement. Nous pouvons très souvent utiliser une date de dernière modification ou un numéro de séquence incrémental. Dans notre exemple, les tables de WorldWideImporters comportent une colonne « LastEditedWhen » que nous pourrons utiliser.
Nous avons maintenant une dernière page de revue avant de sauvegarder et de choisir si l’on veut commencer nos transferts immédiatement.
Une fois validés nous arrivons sur la page principale de notre job de copie.
Schedule
Comme nous avions laissé cocher le démarrage immédiat de nos activités, un Schedule a été automatiquement créé pour nous qu’il va falloir modifier selon nos besoins.
Pour changer le Schedule, rien de plus simple, il suffit d’ouvrir le menu dédié et de configurer à notre convenance. Nous pouvons aussi arrêter le schedule si nécessaire.
Il est aussi possible de lancer de façon unitaire le job. Et si nous avons alimenté de nouvelles données dans notre base (comme décrit ici : Wide World Importers – BDD source du projet) nous aurons uniquement les nouvelles données de chargés.
Tables dans le lakehouse
Comme défini précédemment dans notre job, nous avons créé (automatiquement) des tables dans notre lakehouse. Nous pouvons donc dès maintenant aller les requêter via le endpoint SQL sans actions supplémentaire.
Malgré tout, nous sommes dans un lakehouse et donc tout est fichier. Nous pouvons donc aller voir directement nos fichiers parquet sous le format delta.
Destination fichier dans le lakehouse
Pour une destination lakehouse, nous avions le choix entre tables et fichiers. Si techniquement parlant tout est fichier, nous allons pouvoir voir certaines différences en faisant le choix « files » pour notre destination.
En recréant un copy job et utilisant la destination fichier, nous avons cette fois le choix du format de fichier. Nous avons le choix entre deux formats bien connus que sont le parquet ou le texte délimité (la version générique du CSV).
En choisissant le format délimité, nous aurons quelques options proposées pour les délimiteurs de colonnes et de lignes, mais pas moyen de faire du complètement spécifique (pour le moment ?).
Pour le format parquet, nous aurons simplement le choix de la compression et de l’utilisation (ou non) de l’optimisation « V-Order »
J’utilise personnellement le format parquet qui est plutôt efficace pour tout travail avec Spark.
Une fois exécutés, nous pourrons cette fois retrouver nos fichiers dans le répertoire « Files » de notre lakehouse dans le chemin indiqué dans notre configuration.
Conclusion
Je n’ai pas (encore) beaucoup d’expérience sur le calcul de CU donc je n’ai pas de points de repère. Il sera intéressent de faire des comparaisons avec d’autres méthodes de copie de données et de les mettre en perspectives du temps de développement et de maintenance nécessaire à la mise en place de ces « copy job ».
Globalement l’expérience est très fluide pour faire de la « simple » copie de donnée, cependant la nature propre de ces jobs empêche la paramétrisation à outrance et donc l’externalisation de la configuration des sources comme j’ai pu le faire avec Synapse dans l’article suivant : Paramétrer les Pipeline Azure Synapse Analytics sans ouvrir Synapse !