Votre canvas Azure Data Factory est-il devenu trop grand pour ceux qui l'ont construit ?

Azure Data Factory est l’outil d’intégration par défaut dans chaque parc Azure, et pour une poignée d’activités il est exactement ce qu’il faut : glissez une copy activity, pointez-la vers une source, terminé. Les ennuis commencent quand la même approche est utilisée pour tout l’entrepôt, et que le canvas contient des centaines d’activités que seules les personnes qui les ont câblées peuvent lire.

Pourquoi le canvas cesse de passer à l’échelle

• Le canvas est la documentation. Il n’y a pas de modèle derrière un pipeline, seulement le câblage. Ce qu’un pipeline fait est ce que font ses boîtes et ses flèches, et cela se lit boîte par boîte.
• Chaque source est une copie de la précédente. Une nouvelle table signifie dupliquer une chaîne de copy activities, de lookups et d’appels de procédures stockées, puis éditer chaque étape. La dérive entre les copies est garantie.
• Les changements se font à la main dans une interface. Une flèche de dépendance mal placée ou une mauvaise référence de dataset a l’air correcte jusqu’à l’exécution.
• Travailler en équipe signifie merger du JSON. Deux personnes qui éditent un pipeline dans deux branches se retrouvent dans un merge de JSON de pipeline généré, ce que personne ne relit avec confiance.

Rien de tout cela n’est la faute d’ADF. Un canvas est le bon outil pour orchestrer quelques éléments et le mauvais outil pour exprimer un modèle de données.

Où le câblage devrait se situer

• Dans un modèle, pas sur un canvas. Les clés métier, les relations et les attributs devraient être déclarés une seule fois, et les pipelines qui les chargent dérivés de cette déclaration.
• Générés, pour que les copies ne puissent pas dériver. Si chaque chargement de staging et de vault vient du même générateur, il n’y a pas de version par source à garder alignée.
• L’orchestration des chargements va avec les chargements. Datavault Builder exécute des ensembles de chargements sous forme de jobs, dans l’ordre des dépendances, avec journalisation et reprise. Ce qui reste pour ADF est le déplacement de fichiers, les événements et un déclencheur.

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, d’historisation et de livraison, tournant nativement sur Fabric, Synapse, Azure SQL ou 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 hubs, links, satellites et tous les chargements en sont générés. Il n’y a pas de canvas à garder synchronisé avec la réalité.
• Une nouvelle source est un mapping. Mappez la table de chargement au modèle et régénérez. Pas de chaîne d’activités à copier et ajuster.
• Le modèle est lisible. Les concepts métier, les clés et le lineage sont visibles en un seul endroit, pour les utilisateurs métier comme pour les ingénieurs.
• Les changements sont relus comme des changements de modèle. Support de Git et Gitflow avec des scripts de déploiement et de rollback générés, plutôt qu’un merge de JSON de pipeline.
• ADF garde un rôle réduit. Le déplacement de fichiers et les événements peuvent toujours passer par ADF, et il peut déclencher un job Datavault Builder. L’orchestration des chargements eux-mêmes reste dans la plateforme.

Ce qu’il faut décider

Ouvrez le plus grand pipeline et comptez les activités qui n’existent que pour copier, faire un lookup ou appeler une procédure stockée par source. Ce nombre est la partie du canvas qu’un modèle devrait générer.