Développement ADF

Les bases

La tentation est grande de commencer à développer afin de mettre en place un premier pipeline Azure Data Factory. Il est toutefois bon de prendre quelques minutes afin de définir des règles pour faciliter la maintenabilité et l’exploitation des développements ADF.

1. Convention de nommage

Dans la lignée des conventions de nommage éditées par Jamie Thomson sur SSIS, voici quelques pistes sur Azure Data Factory. L’objectif principal étant d’être capable de se retrouver facilement parmi les centaines de pipelines, activités, services liés, déclencheurs, et autres objets utilisés au sein d’ADF.

a. Azure Data Factory

Il est possible de créer plusieurs Data Factory, cela permet de séparer les différents périmètres et de limiter le nombre d’objets tout en matérialisant une séparation métier entre les flux de chargement. Plusieurs mécanismes rendent cohérente cette séparation tels que : les Integrations Runtimes Auto-Hébergées qui peuvent être partagées entre plusieurs ADF ou la possibilité de monitorer plusieurs ADF avec Azure Data Factory Analytics.

Pas d’impératif en termes de nommage sur l’Azure Data Factory en elle-même, celle-ci s’inscrivant plus largement dans les conventions de nommage des objets Azure propres à votre Système d’Information.

La séparation entre différentes Azure Data Factory se fera en fonction de plusieurs variables telles que la taille du projet et des équipes. En effet, si le projet concerne le chargement de l’entrepôt de données d’une entreprise et qu’il implique un seul développeur, inutile de séparer chaque domaine fonctionnel (Finance, Marketing, Comptabilité, etc.) dans des Azure Data Factory différentes. Cependant, si chacun des périmètres fonctionnels est développé par des équipes différentes, cela fait sens de séparer les Azure Data Factory, éventuellement en partageant un socle commun dans une Azure Data Factory partagée.

b. Pipeline

Afin de simplifier le débogage et la maintenance des pipelines, il est souhaitable de découper ceux-ci en plusieurs sous-pipelines. L’utilisation...

Premiers pipelines

L’objectif de ce premier pipeline est d’intégrer le fichier Customer.csv depuis le disque d’une machine sur le réseau interne de l’entreprise vers une base SQL Azure dans le Cloud.

Toutes les sources sont disponibles dans les éléments à télécharger avec l’ouvrage.

La première difficulté est la récupération des données On-Premise, qui ne sont pas directement accessibles depuis le Cloud public. Pour accéder à ces données, il est nécessaire d’avoir un Integration Runtimes Auto-Hébergé installé sur un serveur local dans le même réseau privé (VNET) que les données.

1. Integration Runtimes Auto-Hébergé

L’installation d’un Integration Runtimes Auto-Hébergé permet le transfert des données d’un réseau privé vers Azure, celui-ci sera en charge de pousser les données sur la base SQL Azure.

Si l’Integration Runtimes utilise principalement les ports 80 et 443, celui-ci utilise le port 1433 dans le cas d’une base de données SQL dans Azure. S’il n’est pas possible d’ouvrir un port sortant sur le 1433 dans votre réseau d’entreprise, il est nécessaire de charger les données sur un stockage Azure au préalable.

L’Integration Runtimes va faire transiter l’intégralité des données sur le réseau et éventuellement appliquer des changements de types. C’est pour cela qu’il est nécessaire de l’installer sur une machine taillée convenablement. La taille minimale recommandée par Microsoft est la suivante :

CPU 2 GHz avec 4 cœurs
Mémoire 8 Gb
80 Gb de disque

La position centrale de l’Intégration Runtimes mérite de monitorer celui-ci et de s’assurer qu’il ne devienne pas un point de contention du chargement de données. Il ne faudra donc pas hésiter à augmenter la taille de la machine ou à mettre en place du Scale Out en installant plusieurs IR.

L’installation de l’Integration Runtimes peut être faite depuis le portail Azure, depuis le SDK C# (ou dans un autre langage s’appuyant sur l’API d’Azure Data Factory), ainsi qu’en...