Les limites d'Azure Data Factory : le coût caché des pipelines assemblés à la main et des transformations Spark

Azure Data Factory est l’outil par défaut dans chaque parc Azure et il mérite cette position en tant que couche de transport : Copy Activities, déclencheurs, déplacement de fichiers entre services. Les problèmes commencent quand il devient aussi la couche de modélisation et de transformation, et ils apparaissent à trois endroits qui ont chacun leur propre article dans cette série.

Trois obstacles, une seule cause

• Le canvas. Des centaines d’activités reliées à la main, copiées source par source, que personne ne comprend en dehors de ceux qui les ont construites. Voir l’article sur les pipelines visuels à grande échelle.
• La release. Des templates ARM, des fichiers de paramètres par environnement, et un déploiement qui échoue sur une seule incohérence de type. Voir l’article sur les déploiements JSON.
• La facture Spark. Les Mapping Data Flows démarrent un cluster managé à chaque exécution, pour des chargements qui tiennent en une instruction SQL dans l’entrepôt. Voir l’article sur le coût des Mapping Data Flows.

Ces trois obstacles viennent de la même décision : la structure de l’entrepôt est exprimée sous forme de configuration de pipelines dans un service cloud, au lieu d’un modèle qui génère les pipelines.

Le quatrième obstacle : vous ne pouvez pas changer de cloud

Un pipeline ADF est une ressource Azure. Il n’en existe aucune version qui tourne sur AWS ou GCP, et Fabric Data Factory, le successeur de Microsoft, est tout aussi lié à Azure. Cela ne pose aucun problème tant que le parc est Azure et le reste. Cela devient une réécriture le jour où une fusion, une décision d’achat ou une politique multicloud en décide autrement, parce que la logique de transformation est liée au cloud, et non à l’entrepôt. Un entrepôt décrit dans un modèle n’a pas ce lien : le SQL généré s’exécute là où l’entrepôt s’exécute.

Ce qui change avec Datavault Builder

Datavault Builder décrit l’entrepôt dans un modèle visuel et en génère les chargements de staging, de vault et de livraison, avec le déploiement, le rollback, la documentation et le lineage, en tournant nativement sur Fabric, Synapse, Azure SQL et SQL Server.

• Vous modélisez le métier, la plateforme construit le reste. Décrivez une fois les entités, les clés et les relations ; les structures et tous les chargements en sont générés. Une nouvelle source est un mapping, pas une chaîne d’activités copiées. Le canvas se réduit au déplacement de fichiers et à un déclencheur.
• Les releases sont générées, rollback inclus. Des scripts de déploiement par environnement issus du modèle, comparés avant de s’exécuter. Aucun template ARM à tenir à jour à la main.
• Les chargements s’exécutent dans le moteur. Du SQL delta ensembliste pour la plateforme cible. Aucun cluster pour le travail standard de l’entrepôt.
• Le modèle est portable. Fabric aujourd’hui, une autre plateforme demain, le même modèle. Un changement de cloud est un changement de cible, pas une réécriture.
• ADF garde un rôle réduit. Le déplacement de fichiers et les événements peuvent toujours passer par Data Factory, et il peut déclencher un job Datavault Builder. L’orchestration des chargements reste dans la plateforme.

Par où commencer

Deux listes. Les activités du plus grand pipeline qui n’existent que pour copier, faire un lookup ou appeler une procédure par source, et les lignes Mapping Data Flow de la facture Azure triées par nombre de lignes par exécution. La première est le canvas qu’un modèle devrait générer. La seconde est le calcul qui a sa place dans l’entrepôt. Les deux représentent en général l’essentiel de la factory.