Application de DataOps à Azure Data Factory

2024-01-05

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Azure Data Factory correspond à l’intégration de données et au service ETL de Microsoft dans le cloud. Ce document fournit des conseils sur DataOps dans la fabrique de données. Il n’a pas vocation à constituer un tutoriel complet sur CI/CD, Git ou DevOps. Vous y trouverez plutôt les conseils de l’équipe Data Factory pour la réalisation de DataOps dans le service avec des références à des liens vers des implémentations détaillées décrivant les bonnes pratiques de déploiement d’une fabrique de données, la gestion de la fabrique et la gouvernance. Une section liste des ressources à la fin de cet article avec des liens vers des tutoriels.

Qu’est-ce que DataOps ?

DataOps est un processus que les organisations de données pratiquent à des fins de gestion des données collaborative visant à fournir une valeur plus rapide aux décideurs.

Gartner propose cette définition précise de DataOps :

DataOps est une pratique de gestion des données collaborative qui se concentre sur l’amélioration de la communication, de l’intégration et de l’automatisation des flux de données entre les gestionnaires de données et les consommateurs de données au sein d’une organisation. L’objectif de DataOps est de fournir de la valeur plus rapidement en créant une livraison et une gestion prévisibles des modifications des données, des modèles de données et des artefacts associés. DataOps utilise la technologie pour automatiser la conception, le déploiement et la gestion de la livraison des données avec des niveaux de gouvernance appropriés. Des métadonnées sont utilisées pour améliorer la facilité d’utilisation et la valeur des données dans un environnement dynamique.

Comment réaliser DataOps dans Azure Data Factory ?

Azure Data Factory fournit aux ingénieurs Données un paradigme de pipeline de données visuel pour créer facilement des projets ETL et d’intégration de données à l’échelle du cloud. La fabrique de données s’appuie sur des intégrations natives à des outils de gestion de versions sérieux comme GitHub et Azure DevOps, ainsi que l’écosystème Azure au sens large, pour fournir de nombreuses fonctionnalités intégrées afin de faciliter dataOps, notamment une collaboration, une gouvernance et des relations d’artefacts enrichies.

Plus précisément, une fois que vous avez introduit votre propre dépôt GitHub ou Azure DevOps dans la fabrique de données, le service fournit des options d’interface utilisateur intégrées intuitives pour les commandes courantes, comme les commits, l’enregistrement d’artefacts et la gestion de versions. Le service offre également la possibilité d’appliquer les bonnes pratiques en matière de CI/CD et d’archivage de code, afin de protéger la validité et l’intégrité de votre environnement de production.

« Code » dans Azure Data Factory

Tous les artefacts dans Azure Data Factory, qu’il s’agisse de pipelines, de services liés, de déclencheurs, etc. ont des représentations de « code » correspondantes en JSON derrière l’intégration de l’interface utilisateur visuelle. Ces artefacts agissent conformément aux normes des modèles Azure Resource Manager. Vous pouvez trouver le code en cliquant sur l’icône des crochets située en haut à droite du canevas. Voici ce à quoi ressemble un exemple de « code » JSON :

Capture d’écran montrant un exemple JSON pour un pipeline.

Mode réel et gestion de versions Git

Chaque fabrique a une seule source de vérité : pipelines, services liés et définitions de déclencheur stockés au sein du service. Cette source de vérité à ce que le pipeline exécute et à ce qui détermine les comportements des déclencheurs. Si vous êtes en mode réel, chaque fois que vous publiez, vous modifiez directement la source unique de vérité. L’image suivante montre ce à quoi ressemble le bouton Publier tout en mode réel.

Le mode direct peut s’avérer pratique pour une personne seule qui travaille sur des projets parallèles, car il permet aux développeurs de voir les effets immédiats de leurs modifications de code. Toutefois, il est déconseillé aux équipes de développeurs de travailler sur des projets au niveau de la production. Les risques incluent les erreurs de frappe, les suppressions accidentelles de ressources critiques, la publication de codes non testés, etc., pour n’en citer que quelques-uns. Quand vous travaillez sur des plateformes et des projets stratégiques, envisagez d’intégrer un dépôt Git et d’utiliser le mode Git dans la fabrique de données pour simplifier le processus de développement. La gestion de versions et les fonctionnalités d’archivage contrôlé du mode Git vous permettent d’éviter la plupart, voire la totalité, des accidents associés directement au mode réel.

Notes

En mode Git, le bouton Publier ou Publier tout est remplacé par Enregistrer ou Enregistrer tout et vos changements sont commités dans vos propres branches (sans modifier directement les codebases réels).

Configuration de l’intégration GitHub et Azure DevOps

Dans Azure Data Factory, il est vivement recommandé de stocker votre dépôt dans GitHub ou Azure DevOps. Le service prend entièrement en charge les deux méthodes et le choix du dépôt à utiliser dépend des normes propres à votre organisation. Il existe deux méthodes pour configurer un nouveau dépôt ou se connecter à un dépôt existant : utiliser le portail Azure ou créer un dépôt à partir de l’interface utilisateur Azure Data Factory Studio.

Création d’une fabrique avec le portail Azure

Quand vous créez une fabrique de données à partir du portail Azure, le dépôt Git par défaut est Azure DevOps. Vous pouvez également sélectionner GitHub comme dépôt et configurer vos paramètres de dépôt.

À partir du portail Azure, sélectionnez le type de dépôt et entrez les noms du dépôt et de la branche pour créer une fabrique intégrée en mode natif à Git.

Capture d’écran montrant l’interface utilisateur Créer une fabrique de données Azure avec les paramètres de configuration Git affichés.

Application de l’utilisation de Git avec Azure Policy dans votre organisation

L’utilisation de Git dans vos projets Azure Data Factory est une bonne pratique fortement recommandée. Même si vous n’implémentez pas un processus CI/CD complet, l’intégration de Git à ADF permet d’enregistrer vos artefacts de ressources dans votre propre environnement de bac à sable (branche Git) où vous pouvez tester vos changements indépendamment du reste des branches de la fabrique. Vous pouvez utiliser Azure Policy pour appliquer l’utilisation de Git dans la fabrique de votre organisation.

Azure Data Factory Studio

Après avoir créé votre fabrique de données, vous pouvez également vous connecter à votre dépôt par le biais d’Azure Data Factory Studio. Sous l’onglet Gérer, vous allez voir l’option permettant de configurer votre dépôt et ses paramètres.

Par le biais d’un processus guidé, vous êtes accompagné tout au long d’une série d’étapes pour configurer le dépôt de votre choix et vous y connecter facilement. Une fois la configuration effectuée, vous pouvez commencer à travailler en collaboration et à enregistrer vos ressources dans votre dépôt.

Capture d’écran montrant la page de configuration du dépôt.

Intégration continue et livraison continue (CI/CD)

CI/CD est un paradigme de développement de code dans lequel les changements sont inspectés et testés à mesure qu’ils passent par différentes étapes : développement, test, préproduction, etc. Après avoir été examinés et testés à chaque étape, ils sont finalement publiés sur des codebases réels dans un environnement de production.

L’intégration continue (CI) est la pratique qui consiste à tester et valider automatiquement chaque changement apporté par un développeur à votre codebase. La livraison continue (CD) signifie qu’une fois les tests d’intégration continue réussis, les changements passent à l’étape suivante en continu.

Comme indiqué brièvement auparavant, le « code » dans Azure Data Factory prend la forme d’un modèle Azure Resource Manager au format JSON. Ainsi, les changements qui passent par le processus d’intégration et de livraison continues (CI/CD) comprennent des ajouts, des suppressions et des modifications d’objets blob JSON.

Exécutions de pipeline dans Azure Data Factory

Avant de parler de CI/CD dans Azure Data Factory, nous avons besoin de présenter la manière dont le service exécute un pipeline. Avant que la fabrique de données exécute un pipeline, elle effectue les opérations suivantes :

Tirage (pull) de la dernière définition publiée du pipeline et de ses ressources associées, comme des jeux de données, des services liés, etc.
Compilation du pipeline en actions. Si la fabrique de données l’a exécuté récemment, elle récupère les actions dans les compilations mises en cache.
Exécution du pipeline.

L’exécution du pipeline implique les étapes suivantes :

Le service prend l’instantané à un point dans le temps de la définition du pipeline.
Pendant toute la durée du pipeline, les définitions ne changent pas.
Même si vos pipelines s’exécutent longtemps, ils ne sont pas affectés par les changements ultérieurs apportés après leur démarrage. Si vous publiez des changements sur le service lié, les pipelines, etc., pendant l’exécution, ceux-ci n’affectent pas les exécutions en cours.
Lorsque vous publiez des modifications, les exécutions suivantes démarrées après la publication utilisent les définitions mises à jour.

Publication dans Azure Data Factory

Que vous déployiez des pipelines avec Azure Release Pipeline pour automatiser la publication ou avec un déploiement manuel de modèles Resource Manager, dans le back-end, la publication est une série d’opérations de création/mise à jour sur des jeux de données, des services liés, des pipelines et des déclencheurs, pour chacun des artefacts. L’effet est le même que si vous effectuiez les appels d’API REST sous-jacents directement.

Voici quelques éléments qui proviennent des actions :

Tous ces appels d’API sont synchrones, ce qui signifie que l’appel est retourné uniquement quand la publication réussit/échoue. Il n’y aura pas d’état de déploiement partiel pour l’artefact.
Les appels d’API sont, dans une large mesure, séquentiels. Nous essayons de paralléliser les appels, tout en conservant les dépendances référentielles des artefacts. L’ordre des déploiements est service lié -> jeu de données/runtime d’intégration -> pipeline -> déclencheur. Cet ordre garantit que les artefacts dépendants peuvent référencer correctement leurs dépendances. Par exemple, les pipelines dépendent des jeux de données et la fabrique de données les déploie après les jeux de données.
Les déploiements de services liés, jeux de données, etc. sont indépendants des pipelines. Dans certaines situations, la fabrique de données met à jour les services liés avant la mise à jour d’un pipeline. Nous aborderons cette situation dans la section Quand arrêter un déclencheur.
Le déploiement ne supprime pas les artefacts des fabriques. Vous avez besoin d’appeler explicitement les API de suppression pour chaque type d’artefact (pipeline, jeu de données, service lié, etc.) pour nettoyer une fabrique. Reportez-vous à l’exemple de script post-déploiement d’Azure Data Factory par exemple.
Même si vous n’avez pas touché un pipeline, un jeu de données ou un service lié, il effectue quand même un appel d’API de mise à jour rapide de la fabrique.

Déclencheurs de publication

Les déclencheurs ont un état : démarré ou arrêté.
Vous ne pouvez pas apporter de changements à un déclencheur en mode démarré. Vous avez besoin d’arrêter un déclencheur avant de publier des changements.
Vous pouvez appeler l’API de création ou mise à jour d’un déclencheur sur un déclencheur en mode démarré.
- Si la charge utile change, l’API échoue.
- Si la charge utile reste inchangée, l’API réussit.
Ce comportement exerce un fort impact sur le moment auquel arrêter un déclencheur.

Quand arrêter un déclencheur

Dans le cas d’un déploiement sur une fabrique de données de production, avec des déclencheurs réels qui démarrent en permanence des exécutions de pipeline, la question se pose de savoir si nous avons intérêt à les arrêter.

La réponse rapide est que dans les quelques scénarios suivants uniquement, il est préférable d’envisager d’arrêter le déclencheur :

Vous avez besoin d’arrêter le déclencheur si vous mettez à jour ses définitions, notamment des champs comme la date de fin, la fréquence et l’association de pipeline.
Il est recommandé d’arrêter le déclencheur si vous mettez à jour les jeux de données ou les services liés référencés dans un pipeline réel. Par exemple, si vous effectuez une rotation des informations d’identification pour SQL Server.
Vous pouvez choisir d’arrêter le déclencheur si le pipeline associé génère des erreurs, échoue et accable vos serveurs.

Voici les quelques points à prendre en compte sur l’arrêt des déclencheurs :

Comme expliqué dans la section Exécutions de pipeline dans Azure Data Factory, quand un déclencheur démarre une exécution de pipeline, il prend un instantané des définitions du pipeline, du jeu de données, du runtime d’intégration et des services liés. Si le pipeline s’exécute avant que les changements ne soient renseignés dans le back-end, le déclencheur démarre une exécution avec l’ancienne version. Dans la plupart des cas, cela fonctionne bien.
Comme expliqué dans la section Déclencheurs de publication, quand un déclencheur est à l’état démarré, il ne peut pas être mis à jour. Par conséquent, si vous avez besoin de modifier des détails de la définition du déclencheur, arrêtez le déclencheur avant de publier les changements.
Comme expliqué dans la section Publication dans Azure Data Factory, les changements apportés aux jeux de données ou aux services liés sont publiés avant les changements du pipeline. Pour veiller à ce que les exécutions de pipeline utilisent les informations d’identification correctes et communiquent avec les serveurs appropriés, nous vous recommandons d’arrêter aussi le déclencheur associé.

Préparation des changements de « code »

Nous vous recommandons de suivre ces bonnes pratiques pour les demandes de tirage (pull requests).

Chaque développeur doit travailler sur ses propres branches individuelles et, en fin de journée, créer des demandes de tirage vers la branche primaire du dépôt. Consultez les tutoriels sur les demandes de tirage dans GitHub et DevOps.
Quand les gardiens (gatekeepers) approuvent les demandes de tirage et fusionnent les changements dans la branche primaire, le processus CI/CD peut démarrer. Il existe deux méthodes suggérées pour promouvoir des changements dans tous les environnements : automatisée et manuelle.
Une fois que vous êtes prêt à lancer des pipelines CI/CD, vous pouvez le faire généralement en utilisant Azure Pipeline Release ou vous pouvez effectuer des déploiements de pipelines individuels spécifiques à l’aide de cet utilitaire open source issu du Lecteur Azure.

Déploiement automatisé des changements

Pour faciliter les déploiements automatisés, nous vous recommandons d’utiliser le package npm des utilitaires Azure Data Factory. L’utilisation du package npm permet de valider toutes les ressources incluses dans un pipeline et de générer les modèles ARM pour l’utilisateur.

Pour bien démarrer avec le package npm des utilitaires Azure Data Factory, reportez-vous à Publication automatisée pour l’intégration et la livraison continues.

Déploiement manuel des changements

Une fois que vous avez fusionné votre branche avec la branche de collaboration primaire de votre dépôt Git, vous pouvez publier manuellement vos changements sur le service Azure Data Factory réel. Le service offre un contrôle d’interface utilisateur sur la publication à partir de fabriques hors développement avec l’option Désactiver la publication (à partir d’ADF Studio).

Capture d’écran montrant la page de modification d’un dépôt Git et le bouton Désactiver la publication (à partir d’ADF Studio).

Déploiement sélectif

Le déploiement sélectif s’appuie sur une fonctionnalité de GitHub et d’Azure DevOps, appelée cherry picking. Cette fonctionnalité vous permet de déployer uniquement certains changements, mais pas d’autres. Par exemple, un développeur a apporté des changements à plusieurs pipelines, mais pour le déploiement d’aujourd’hui, vous avez peut-être envie de déployer ces changements sur un seul pipeline.

Suivez les tutoriels d’Azure DevOps et de GitHub pour sélectionner les commits pertinents pour le pipeline dont vous avez besoin. Vérifiez que tous les changements, y compris les changements pertinents apportés aux déclencheurs, aux services liés et aux dépendances associés au pipeline, ont fait l’objet d’un cherry picking.

Une fois que vous avez appliqué un cherry picking aux changements et effectué une fusion avec le pipeline de collaboration primaire, vous pouvez lancer le processus CI/CD pour les changements proposés. Pour plus d’informations sur la façon de corriger à chaud, d’appliquer un cherry picking ou d’utiliser des frameworks externes pour un déploiement sélectif, consultez la section Tests automatisés de cet article.

Effectuer des tests unitaires

Les tests unitaires forment une partie importante du processus de développement de nouveaux pipelines ou de modification d’artefacts de fabrique de données existants, qui se concentre sur les tests des composants du code. Data Factory autorise les tests unitaires individuels au niveau du pipeline et de l’artefact du flux de données à l’aide de la fonctionnalité de débogage du pipeline.

Quand vous développez des flux de données, vous pouvez obtenir des insights sur chaque transformation individuelle et chaque changement de code à l’aide de la fonctionnalité d’aperçu des données pour effectuer des tests unitaires avant de déployer vos changements en production.

Le service fournit des commentaires en direct et interactifs sur vos activités de pipeline dans l’interface utilisateur lors du débogage et des tests unitaires dans Azure Data Factory.

Tests automatisés

Il existe plusieurs outils disponibles pour les tests automatisés que vous pouvez utiliser avec Azure Data Factory. Étant donné que le service stocke des objets sous forme d’entités JSON, il peut s’avérer pratique d’utiliser le framework de test unitaire .NET open source NUnit avec Visual Studio. Reportez-vous à ce billet sur la configuration des tests automatisés pour Azure Data Factory qui fournit une explication détaillée de la manière de configurer un environnement de test unitaire automatisé pour votre fabrique. (Un grand merci à Richard Swinbank qui a donné son autorisation pour utiliser ce blog.)

Les clients peuvent également exécuter des pipelines TEST avec PowerShell ou l’interface CLI AZ dans le cadre du processus CI/CD pour les étapes de pré-déploiement et de post-déploiement.

Un avantage non négligeable de la fabrique de données réside dans son paramétrage des jeux de données. Cette fonctionnalité permet aux clients d’exécuter les mêmes pipelines avec différents jeux de données pour veiller à ce que leur nouveau développement réponde à toutes les exigences de source et de destination.

Capture d’écran montrant l’Explorateur de tests pour Azure Data Factory.

Autres frameworks CI/CD pour Azure Data Factory

Comme décrit précédemment, l’intégration Git prédéfinie est disponible en mode natif par le biais de l’interface utilisateur Azure Data Factory, notamment la fusion, la création de branches, la comparaison et la publication. Toutefois, il existe d’autres frameworks CI/CD utiles bien connus au sein de la communauté Azure, qui fournissent d’autres mécanismes pour fournir des fonctionnalités similaires. La méthodologie Git Azure Data Factory se base sur des modèles ARM, tandis que les frameworks comme ADFTools de Kamil Nowinski adoptent une approche différente en s’appuyant sur des artefacts JSON individuels plutôt issus de votre fabrique. Les ingénieurs Données calés en Azure DevOps qui préfèrent travailler dans cet environnement (par opposition à l’approche de l’interface utilisateur ARM que le service propose prête à l’emploi) peuvent trouver que ce framework fonctionne bien pour eux et pour les scénarios courants comme les déploiements partiels. Ce framework peut également simplifier la gestion des déclencheurs lors du déploiement dans des environnements qui ont des états de déclencheur en cours d’exécution.

Gouvernance des données dans Azure Data Factory

La gouvernance des données est un aspect important de l’efficacité de DataOps. Pour des outils ETL d’intégration de données, la traçabilité des données et les relations d’artefacts peuvent fournir des informations importantes à un ingénieur Données afin de comprendre l’impact des changements en aval. Data Factory fournit des vues d’artefacts associés intégrées qui constituent l’implémentation de votre fabrique.

Capture d’écran montrant les artefacts liés à une fabrique de données pour un exemple de jeu de données.

L’intégration native à Microsoft Purview offre aussi une traçabilité, une analyse d’impact et un catalogage des données.

Microsoft Purview est une solution de gouvernance des données unifiée qui permet de gérer et de gouverner vos données locales, multiclouds et SaaS (software as a service). Elle vous permet de créer facilement une carte holistique actualisée du paysage de vos données, avec la découverte automatisée des données, la classification des données sensibles et la traçabilité des données de bout en bout. Ces fonctionnalités donnent les moyens aux consommateurs de données d’accéder à une gestion des données utile et fiable.

Capture d’écran montrant le suivi de la traçabilité des données possible avec Microsoft Purview.

Grâce à l’intégration native à votre catalogue de données Purview, la fabrique de données permet de rechercher et de découvrir facilement les ressources de données à utiliser dans vos pipelines d’intégration de données sur toute l’étendue du patrimoine de données de votre organisation.

Vous pouvez utiliser la barre de recherche principale d’Azure Data Factory Studio pour trouver des ressources de données dans votre catalogue Purview.