Dans cette édition d’Aventures dans Fabric, nous explorons l’orchestration dans Microsoft Fabric à travers le prisme d’Apache Airflow. Nous partageons notre première expérience d’utilisation d’Airflow en tant qu’offre au sein de Fabric, décrivons les fonctionnalités clés, notons les limitations actuelles et discutons de l’opérateur natif Fabric récemment publié par Microsoft.
Certains d’entre vous entendent peut-être parler d’Airflow pour la première fois, tandis que d’autres le connaissent peut-être dans sa version open source. Le fait que Microsoft Fabric intègre Airflow en tant qu’offre SaaS signifie que nous pouvons utiliser cet outil d’orchestration sans avoir à configurer et à gérer l’infrastructure de calcul sous-jacente.
L’orchestration ne reçoit pas souvent les feux de la rampe, mais c’est un composant fondamental de toute architecture ETL robuste. Elle garantit que les tâches sont exécutées de manière fiable, que les dépendances sont gérées et que les flux de travail s’adaptent efficacement. Même les processus ETL les plus avancés sont inefficaces sans une orchestration appropriée pour coordonner, automatiser et gérer l’exécution.
En résumé, l’orchestration fait référence à l’automatisation et à la coordination des tâches entourant vos processus ETL, en séquençant les activités en parallèle ou en série en fonction des exigences du flux de travail.
Les composants clés de l’orchestration comprennent :
• La planification
• La gestion des dépendances
• La gestion et la récupération des erreurs
• La surveillance et la journalisation
• L’évolutivité
Sans orchestration, les tâches doivent être exécutées manuellement, ce qui n’est ni durable ni évolutif. Plus important encore, l’orchestration doit être pilotée par les données, permettant aux flux de travail de s’adapter et d’évoluer grâce à des paramètres configurables au lieu d’une logique codée en dur.
Comment tout exécuter
L’orchestration pilotée par les données s’appuie sur la configuration pour piloter l’exécution. Les systèmes d’orchestration sont responsables de la sélection des paramètres corrects pour chaque exécution, permettant au même code de fonctionner efficacement sur plusieurs tables en parallèle. Ces paramètres sont stockés dans une base de données de configuration, que l’orchestrateur utilise pour construire et exécuter dynamiquement le flux de travail.
Cette architecture permet des capacités puissantes. L’ajout d’une nouvelle table devient aussi simple que l’insertion d’un nouvel enregistrement de configuration. Ces configurations peuvent prendre en charge des déclencheurs basés sur des événements, l’exécution conditionnelle de tâches, le séquençage dynamique, la gestion des erreurs, et plus encore, le tout sans réécrire de code.
Chez Ateko, nous avons construit notre accélérateur Fabric Manager avec cette flexibilité à l’esprit. Notre objectif était de rendre les modèles d’accélérateur aussi réutilisables et évolutifs que possible. Par exemple, nous utilisons un seul notebook et une seule bibliothèque de code pour lire une table d’extraction (couche bronze) et la fusionner dans une table traitée (couche argent) tout en conservant l’historique de chaque enregistrement en fonction de la clé métier (Type II).
Orchestration dans Fabric avec Airflow
Pour prendre en charge l’orchestration à grande échelle, Microsoft Fabric inclut Apache Airflow, signalant la reconnaissance par Microsoft de sa valeur dans la gestion des pipelines de données. Airflow est un outil d’orchestration largement adopté, entièrement piloté par le code. Il utilise Python pour définir des DAG (Graphes Acycliques Dirigés), permettant des flux de travail à grande échelle, contrôlés et reproductibles.
Étant donné que l’implémentation d’Airflow s’exécute dans l’écosystème Fabric, elle bénéficie de la même sécurité renforcée et de la même interopérabilité transparente que les autres composants Fabric.
Fonctionnalités prêtes à l’emploi
D’emblée, Airflow offre une surveillance et une journalisation puissantes grâce à une interface utilisateur intuitive, ainsi qu’une récupération de tâche intégrée à partir de n’importe quel point de défaillance. Si la tâche 98 sur 100 échoue, vous pouvez résoudre le problème et reprendre à partir de ce point sans réexécuter l’ensemble du pipeline. Ce niveau de récupération nécessitait auparavant une ingénierie personnalisée dans d’autres outils. Avec Airflow, cette capacité est incluse par défaut.
Les tâches dans Airflow peuvent être exécutées dynamiquement en fonction des configurations, simplement en utilisant Python pour appeler des API Python avec des paramètres. Airflow est également intégré à Azure Key Vault, ce qui nous permet de sécuriser les données confidentielles et de déployer facilement différents environnements en mettant à jour uniquement le Key Vault et la configuration.
Premières observations : l’intégration d’Airflow par Fabric
Au moment de la rédaction de cet article, l’implémentation d’Airflow par Fabric vient de sortir de la préversion publique. Bien qu’elle offre une orchestration puissante, elle est encore en cours de maturation. Voici quelques limitations que nous avons rencontrées :
Maturité de l’outil
L’éditeur de code Web de Fabric est censé être une alternative plus pratique au développement Airflow local traditionnel, mais il lui manque actuellement des fonctionnalités clés :
- Renommer des fichiers : Vous ne pouvez pas renommer les fichiers une fois créés, même s’il n’y a aucune raison du point de vue d’Airflow de verrouiller les noms de fichiers.
- Tabulation : La touche de tabulation ne fonctionne pas pour passer à l’élément suivant. Si vous travaillez en Python, vous comprenez l’importance de la tabulation.
- Interface : L’interface utilisateur globale de l’éditeur de code Web est décevante, ce qui est particulièrement frustrant étant donné que l’interface utilisateur Web du notebook de Fabric est déjà si performante.
Gestion des clusters
La modification des paramètres d’Airflow nécessite d’arrêter et de redémarrer le cluster. Alors que les environnements Airflow dédiés et locaux offrent des arrêts/redémarrages rapides, l’implémentation de Fabric est légèrement plus capricieuse. Les redémarrages prennent plus de temps que prévu et, en de rares occasions, l’interface utilisateur Web reste bloquée dans un état de « démarrage ». La seule solution que nous ayons trouvée dans de tels cas est de supprimer et de recréer le flux de travail.
Prise en charge de Git
L’intégration Git de Fabric est actuellement limitée. Bien qu’il existe une prise en charge basée sur les fichiers, les DAG et les plugins doivent résider dans des dossiers de niveau racine nommés « dags » et « plug-ins ». C’est un anti-modèle pour nous chez Ateko, car nous suivons une structure de dossiers définie pour tous les dépôts. La configuration actuelle supprime également la possibilité de modifier le code directement dans le navigateur, nous obligeant à nous fier entièrement au développement local.
Bien que des outils comme VS Code offrent plus de contrôle et de flexibilité pour travailler avec les fichiers DAG, il est toujours utile d’avoir la possibilité d’éditer dans le navigateur. Des améliorations de l’intégration de Git sont sur la feuille de route de Microsoft, et nous sommes impatients de voir ces mises à jour.
Et ensuite : explorer l’opérateur natif de Fabric
Airflow définit les flux de travail comme des Graphes Acycliques Dirigés (DAG), où chaque tâche est représentée par un Opérateur. Les opérateurs sont des classes Python qui abstrayent la logique des tâches individuelles, comme appeler une API, exécuter une requête SQL ou exécuter une fonction Python, ce qui les rend réutilisables et faciles à gérer au sein d’un DAG.
Alors que les opérateurs génériques fonctionnent pour les tâches de base, la plupart des grandes plateformes telles que Databricks, Snowflake et Azure Data Factory ont contribué des opérateurs personnalisés au projet Airflow pour simplifier l’intégration. Databricks fournit des opérateurs d’exécution de tâches, Snowflake en a une suite, et Microsoft lui-même a des opérateurs personnalisés pour fonctionner avec les API d’Azure Data Factory.
Pendant le développement par Ateko de notre accélérateur Fabric Manager, Microsoft n’avait pas encore publié d’opérateur spécifique à Fabric pour exécuter et surveiller les objets Fabric. Les API étaient disponibles, nous avons donc créé le nôtre. Cependant, notre opérateur nécessite l’utilisation d’un service sans assistance et sans MFA, car les API Fabric n’étaient pas prises en charge avec SPN. Nous avons développé une solution de contournement qui permet à un SPN d’assumer les informations d’identification d’un compte de service et d’exécuter les tâches en tant que ce compte. Cependant, lors de l’utilisation de la bibliothèque MSAL pour Python pour récupérer les informations d’identification d’Entra, le processus échoue si la MFA est activée.
Microsoft a depuis publié un opérateur natif Fabric, et nous sommes ravis d’explorer ses capacités. Bien qu’il ne résolve pas entièrement le défi d’exiger qu’un principal de service (SPN) assume le rôle d’un compte d’utilisateur, il introduit une voie potentielle en prenant en charge la MFA via des informations d’identification déléguées, comme indiqué dans l’article de Microsoft Learn, Tutoriel : Exécuter un pipeline de données et un notebook Fabric à l’aide de DAG Apache Airflow.
De plus, l’approche de Microsoft consistant à appliquer une exécution de pipeline synchrone, où Airflow attend que l’exécution soit terminée, peut offrir de meilleures performances sur le cluster Airflow par rapport à la méthode actuelle d’Ateko. Avec l’opérateur natif maintenant disponible, nous sommes impatients de tester l’opérateur Fabric par rapport à notre propre solution interne.
Conclusion
Chez Ateko, nous sommes confiants dans la valeur à long terme d’Apache Airflow en tant qu’offre dans Microsoft Fabric et ravis de travailler avec un outil d’orchestration puissant et communautaire intégré directement dans l’écosystème. Bien que certaines limitations existent encore, l’investissement continu de Microsoft dans Fabric renforce notre confiance dans sa direction. Étant donné que l’accélérateur Fabric Manager d’Ateko est déjà construit sur une base Airflow, nous suivons de près chaque mise à jour et attendons avec impatience les nouvelles fonctionnalités et améliorations à venir.
Ateko fournit des services gérés qui permettent aux clients d’adopter les solutions Fabric de Microsoft en plus d’autres services natifs d’Azure.
