Infrastructure Integration Runtime dans Azure Data Factory

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Data Factory dans Microsoft Fabric est la prochaine génération de Azure Data Factory, avec une architecture plus simple, une IA intégrée et de nouvelles fonctionnalités. Si vous débutez avec l'intégration des données, commencez par Fabric Data Factory. Les charges de travail ADF existantes peuvent être mises à niveau vers Fabric pour accéder à de nouvelles fonctionnalités dans la science des données, l’analytique en temps réel et la création de rapports.

• Démarrez un essai gratuit Fabric.
• Passer d’Azure Data Factory à Data Factory dans Microsoft Fabric.

L’exécution d’intégration (IR) est l’infrastructure de calcul utilisée par les pipelines Azure Data Factory et Azure Synapse pour fournir les capacités d’intégration de données suivantes à travers différents environnements réseau :

• Flux de données : Exécutez un flux de données dans un environnement de calcul Azure géré.
• Déplacement des données: copiez des données entre des magasins de données dans un réseau public ou privé (pour les réseaux locaux ou privés virtuels). Les connecteurs intégrés, la conversion de format, le mappage de colonnes, ainsi que les transferts de données performants et évolutifs sont pris en charge par le service.
• Répartition d’activité: répartit et surveille les activités de transformation s’exécutant sur différents services de calcul tels qu’Azure Databricks, Azure HDInsight, ML Studio (classique), Azure SQL Database, SQL Server, etc.
• Exécution des packages SSIS : exécute en mode natif les packages SSIS (SQL Server Integration Services) dans un environnement Compute Azure managé.

Dans les pipelines Data Factory et Synapse, une activité définit l’action à effectuer. Un service lié désigne un magasin de données cible ou un service de calcul. Un runtime d’intégration permet de créer une passerelle entre les activités et les services liés. Le service ou la référence d’activité lié(e) désigne et fournit l'environnement de calcul où l'activité est soit exécutée directement, soit envoyée. Cette association permet à l’activité d’être effectuée dans la région la plus proche possible du magasin de données cible ou du service de calcul afin d’optimiser les performances tout en permettant de répondre aux exigences de sécurité et de conformité.

Les runtimes d’intégration peuvent être créés dans l’interface utilisateur Azure Data Factory et Azure Synapse via le hub de gestion directement, et à partir de toutes les activités, jeux de données ou flux de données qui les référencent.

Types de runtime d’intégration

Data Factory propose trois types d’exécution d’intégration (IR), et vous devriez choisir celui qui correspond le mieux à vos capacités d’intégration de données et aux besoins de votre environnement réseau. Les trois types d'IR sont les suivants :

• Azure
• Auto-hébergé
• Azure-SSIS

Note

Les pipelines Synapse ne prennent actuellement en charge que les runtimes d’intégration Azure ou auto-hébergés.

Le tableau suivant décrit les fonctionnalités et l’environnement réseau pour chaque type de runtime d’intégration :

Type de runtime	Prise en charge du réseau public	Prise en charge de la liaison privée
Azure	Flux de données Déplacement des données Répartition des activités	Flux de données Déplacement des données Répartition des activités
Auto-hébergé	Déplacement des données Répartition des activités	Déplacement des données Répartition des activités
Azure-SSIS	Exécution de package SSIS	Exécution de package SSIS

Note

Les contrôles sortants varient selon le service pour Azure IR. Dans Synapse, les espaces de travail offrent des options pour limiter le trafic sortant du réseau virtuel géré lorsque vous utilisez Azure IR. Dans Data Factory, tous les ports sont ouverts pour les communications sortantes lorsque vous utilisez Azure IR. Azure-SSIS IR peut être intégré à votre réseau virtuel pour fournir des contrôles de communications sortantes.

Runtime d’intégration Azure

Un runtime d'intégration Azure peut :

• Exécuter des flux de données dans Azure
• Exécuter des activités de copie entre les entrepôts de données dans le cloud
• Répartir les activités de transformation suivantes dans un réseau public :
  • Activité personnalisée .NET
  • Activité de fonction Azure
  • Activité de Databricks Notebook / Jar / Python
  • Activité d’obtention des métadonnées
  • Activité Hive HDInsight
  • Activité Pig HDInsight
  • Activité MapReduce HDInsight
  • Activité HDInsight Spark
  • Activité de diffusion en continu HDInsight
  • Activité de recherche
  • Activité d'exécution par lot de Machine Learning Studio (classique)
  • Activité de mise à jour de ressource dans Machine Learning Studio (classique)
  • Activité de procédure stockée
  • Activité de validation
  • Activité web

Environnement réseau Azure IR

L’exécution d’intégration Azure permet de connecter les magasins de données et les services de calcul avec des points de terminaison accessibles publiquement. Lorsque vous activez le Managed Réseau virtuel, l’exécution d’intégration Azure permet de se connecter aux magasins de données en utilisant Private Link dans un environnement réseau privé. Dans Synapse, les espaces de travail ont des options pour limiter le trafic sortant à partir du réseau virtuel managé IR. Dans Data Factory, tous les ports sont ouverts pour les communications sortantes. Azure-SSIS IR peut être intégré à votre réseau virtuel pour fournir des contrôles sur les communications sortantes.

Ressources de calcul et mise à l’échelle d’Azure IR

Le runtime d’intégration Azure fournit une expérience de calcul entièrement gérée, sans serveur dans Azure. Vous n’avez pas à vous soucier du provisionnement d’infrastructure, de l’installation logicielle, de la mise à jour corrective ou de la mise à l’échelle de capacité. De plus, vous ne payez que pour ce que vous utilisez.

Le runtime d’intégration Azure fournit le calcul natif pour déplacer des données entre les magasins de données cloud de manière sécurisée, fiable et efficace. Vous pouvez définir combien d’unités d’intégration de données utiliser sur l’activité de copie, et la taille de calcul de l’IR Azure est élastiquement mise à l’échelle en conséquence sans avoir à ajuster explicitement la taille de l’exécution d’intégration Azure.

La répartition d’activité est une opération légère pour acheminer l’activité vers le service de calcul cible, il n’est donc pas nécessaire d’augmenter la taille de calcul dans ce scénario.

Pour en savoir plus sur la création et la configuration d’un runtime d’intégration Azure, consultez la rubrique Guide pratique pour créer et configurer Azure Integration Runtime.

Note

Le runtime d’intégration Azure possède des propriétés liées au runtime de Data Flow, qui définit l’infrastructure de calcul sous-jacente utilisée pour exécuter les flux de données.

Runtime d’intégration auto-hébergé

Un runtime d’intégration auto-hébergé peut :

• Exécution d’une activité de copie entre un stockage de données cloud et un stockage de données dans un réseau privé.
• Répartir les activités de transformation suivantes selon les ressources de calcul dans le réseau local ou Azure :
  • Activité de fonction Azure
  • Activité personnalisée (s’exécute sur Azure Batch)
  • Activité d’obtention des métadonnées
  • Activité Hive HDInsight (BYOC : apportez votre propre certificat)
  • Activité Pig HDInsight (BYOC)
  • Activité MapReduce HDInsight (BYOC)
  • Activité Spark HDInsight (BYOC)
  • Activité diffusion en continu HDInsight (BYOC)
  • Activité de recherche
  • Activité d'exécution par lot de Machine Learning Studio (classique)
  • Activité de mise à jour de ressource dans Machine Learning Studio (classique)
  • Activité Execute Pipeline Machine Learning
  • Activité de procédure stockée
  • Activité de validation
  • Activité web

Note

Utilisez un environnement d’exécution d’intégration auto-hébergé pour supporter les magasins de données nécessitant un pilote à apporter votre propre pilote, tels que SAP HANA et MySQL. Pour plus d’informations, voir les magasins de données pris en charge.

Note

L’environnement d’exécution Java (JRE) est une dépendance de l’IR auto-hébergé. Vérifiez que le JRE est installé sur le même hôte.

Environnement réseau du runtime d'intégration auto-hébergé

Si vous souhaitez intégrer vos données en toute sécurité dans un environnement réseau privé sans visibilité directe depuis l’environnement de cloud public, vous pouvez installer un runtime d’intégration auto-hébergé dans l’environnement local derrière votre pare-feu, ou à l’intérieur d’un réseau privé virtuel. Le runtime d’intégration auto-hébergé établit uniquement des connexions HTTP sortantes pour l’accès à Internet.

Ressources de calcul et mise à l’échelle du runtime d'intégration auto-hébergé

Installez le runtime d’intégration auto-hébergé sur un ordinateur local ou sur une machine virtuelle située à l’intérieur d’un réseau privé. Actuellement, le runtime d’intégration auto-hébergé est pris en charge uniquement sur système d’exploitation Windows. Pour obtenir un runtime d’intégration hautement disponible et évolutif, vous pouvez effectuer un scale-out du runtime d’intégration auto-hébergé en associant l’instance logique avec plusieurs ordinateurs locaux en mode actif/actif. Consultez l’article sur la Procédure de création et de configuration d’un IR auto-hébergé pour plus d’informations.

Runtime d’intégration Azure SSIS

Pour transférer et adapter la charge de travail SSIS existante, vous pouvez créer un Azure-SSIS Integration Runtime pour exécuter les packages SSIS en mode natif.

Environnement réseau du runtime d'intégration Azure SSIS

Le runtime d'intégration Azure-SSIS IR peut être provisionné soit dans un réseau public, soit dans un réseau privé. Le support d'accès aux données sur site est assuré en associant Azure-SSIS IR à un réseau virtuel connecté à votre réseau local.

Ressources de calcul et mise à l’échelle du runtime Azure-SSIS IR

Le runtime d’intégration Azure SSIS est un cluster entièrement géré de machines virtuelles Azure qui est chargé d’exécuter vos packages SSIS. Vous pouvez utiliser votre propre base de données SQL Azure ou instance managée SQL pour le catalogue de projets/packages SSIS (SSISDB). Vous pouvez monter en puissance le calcul en spécifiant la taille du nœud et augmenter la taille des instances en spécifiant le nombre de nœuds du cluster. Vous pouvez gérer le coût d’exécution de votre Azure-SSIS en l’arrêtant et en le relançant selon vos besoins.

Pour plus d’informations, voir Comment créer et configurer l'IR Azure-SSIS. Une fois votre runtime d’intégration créé, vous pouvez déployer et gérer vos packages SSIS existants, sans changement ou presque, à l’aide des outils SQL Server Data Tools (SSDT) et SQL Server Management Studio (SSMS), comme si vous utilisez SSIS en local.

Pour plus d’informations sur le runtime Azure-SSIS, voir les articles suivants :

• Didacticiel : deploy SSIS packages to Azure (Déployer des packages SSIS vers Azure). Cet article fournit des instructions détaillées pour créer une instance Azure-SSIS Integration Runtime qui utilise une instance Azure SQL Database pour héberger le catalogue SSIS.
• Procédure : Créer un runtime d’intégration Azure-SSIS. Cet article s’appuie sur le tutoriel et fournit des instructions sur la façon d’utiliser une instance managée SQL et de joindre le runtime d’intégration à un réseau virtuel.
• Surveiller le runtime d’intégration Azure-SSIS. Cet article vous explique comment récupérer des informations sur un IR Azure-SSIS, ainsi que des descriptions des statuts dans les informations renvoyées.
• Gérer un runtime d’intégration Azure-SSIS (Manage an Azure-SSIS IR). Cet article explique comment arrêter, démarrer ou supprimer un Azure-SSIS Integration Runtime. Il vous montre également comment mettre à l'échelle votre Azure-SSIS IR en lui ajoutant des nœuds supplémentaires.
• Joindre un environnement d'exécution Azure-SSIS à un réseau virtuel. Cet article fournit des informations conceptuelles sur la façon d’attacher un runtime d’intégration Azure-SSIS à un réseau virtuel Azure. Il fournit également les étapes permettant d’utiliser le portail Azure pour configurer un réseau virtuel et y joindre un Azure-SSIS Integration Runtime.

Emplacement du runtime d’intégration

Relation entre l'emplacement de l'usine et l'emplacement de l'IR

Lorsque vous créez une instance de Data Factory ou un espace de travail Synapse, vous devez spécifier son emplacement. Les métadonnées de l’instance sont stockées ici et le déclenchement du pipeline est initié à partir d’ici. Les métadonnées sont stockées uniquement dans la région choisie et ne sont pas stockées dans d’autres régions.

Un pipeline peut toutefois accéder à des magasins de données et à des services de calcul situés dans d’autres régions Azure pour déplacer des données entre des magasins de données ou pour traiter des données à l’aide des services de calcul. Ce comportement se réalise grâce au runtime d’intégration globalement disponible pour garantir la conformité des données et l’efficacité, et réduire les frais de sortie de réseau.

L’emplacement IR définit l’emplacement de son calcul en arrière-plan, ainsi que l’endroit où sont effectués les déplacements des données, le dispatch d’activités et l’exécution du paquet SSIS. L’emplacement du runtime d’intégration peut être différent de l’emplacement de la fabrique de données à laquelle il appartient.

Emplacement d'Azure IR

Vous pouvez définir la région d’emplacement d’Azure IR, auquel cas l’exécution ou la répartition de l’activité se produit dans la région sélectionnée.

Le comportement par défaut consiste à résoudre automatiquement l’Azure IR dans le réseau public. Avec cette option :

• Pour l’activité de copie, un effort maximal est fait pour détecter automatiquement l’emplacement de votre magasin de données récepteur, puis d’utiliser l'IR dans la même région, si possible, ou dans la région la plus proche géographiquement ; si la région du magasin de données récepteur n’est pas détectable, l'IR dans la région de l’instance est utilisé à la place.

  Par exemple, un espace de travail Data Factory ou Synapse a été créé dans l’est des États-Unis,

  • Lorsque vous copiez des données vers un objet blob Azure dans la région USA Ouest, si l’objet blob est détecté dans la région USA Ouest, l’activité de copie est exécutée sur le runtime d’intégration dans la région USA Ouest ; si la détection de région échoue, l’activité de copie est exécutée sur le runtime d’intégration dans la région USA Est.
  • Lorsque vous copiez des données vers Salesforce, pour lesquelles la région n’est pas détectable, l’activité de copie est exécutée sur l'IR dans la région Est des États-Unis.

  Conseil

  Si vous avez des exigences strictes de conformité aux données et devez vous assurer que les données ne quittent pas une certaine géographie, vous pouvez explicitement créer un IR Azure dans une région donnée et orienter le service lié vers cet IR en utilisant la propriété ConnectVia. Par exemple, si vous souhaitez copier des données d'un blob dans le sud du Royaume-Uni vers un espace de travail Azure Synapse dans le sud du Royaume-Uni et que vous voulez vous assurer que les données ne quittent pas le Royaume-Uni, créez un IR Azure dans le sud du Royaume-Uni et liez les deux services liés à cet IR.

• Pour l’exécution des activités Lookup/GetMetadata/Delete (activités Pipeline), la répartition des activités de transformation (activités externes) et les opérations d’authoring (connexion de test, liste de dossiers et tableaux, et données d’aperçu), l’IR dans la même région que la Data Factory ou l’espace de travail Synapse est utilisé.

• Pour Data Flow, l’IR dans la région Data Factory ou Synapse workspace est utilisée.

  Conseil

  Une meilleure pratique consiste à s’assurer que les flux de données s’exécutent dans la même région que vos magasins de données correspondants, dans la mesure du possible. Vous pouvez soit obtenir cela avec l’autorésolution pour Azure IR (si l’emplacement du stockage de données est le même que celui de l’espace de travail Data Factory ou Synapse), soit en créant une nouvelle instance Azure IR dans la même région que vos archives de données puis en exécutant les flux de données dessus.

Si vous activez Managed Réseau virtuel avec autorésolution pour Azure IR, l’IR dans la région Data Factory ou Synapse est utilisée.

Vous pouvez surveiller l’emplacement de runtime d’intégration utilisé lors de l’exécution de l’activité dans la vue Surveillance de l’activité du pipeline dans Data Factory Studio ou Synapse Studio, ou dans la charge utile Surveillance de l’activité.

Emplacement du runtime d’intégration auto-hébergé

L’IR auto-hébergé est logiquement enregistré dans l’espace de travail Data Factory ou Synapse, et vous fournissez le calcul utilisé pour supporter ses fonctionnalités. Par conséquent, il n’existe aucune propriété d’emplacement explicite pour l’IR auto-hébergé.

Lorsqu'il est utilisé pour effectuer le déplacement de données, l'IR auto-hébergée extrait les données de la source et les écrit dans la destination.

Emplacement du Azure-SSIS IR

Note

Les environnements d'exécution Azure-SSIS ne sont pas actuellement pris en charge dans les pipelines Synapse.

Le choix de l’emplacement pour votre runtime d’intégration Azure SSIS est essentiel pour parvenir à un niveau de performance élevé dans vos flux de travail ETL (extraction, transformation et chargement).

• L’emplacement de votre Azure-SSIS Integration Runtime n’a pas besoin d’être identique à l’emplacement de votre fabrique de données, mais il doit être identique à l’emplacement de votre propre instance Azure SQL Database ou SQL Managed Instance où se trouve SSISDB. Ainsi, votre runtime d’intégration Azure-SSIS peut facilement accéder à la SSISDB sans encourir un trafic excessif entre différents emplacements.
• Si vous n’avez pas de base de données SQL existante ou SQL Managed Instance, mais que vous disposez de sources/destinations de données locales, vous devez créer une instance Azure SQL Database ou SQL Managed Instance dans le même emplacement qu’un réseau virtuel connecté à votre réseau local. De cette façon, vous pouvez créer votre Azure-SSIS Integration Runtime en utilisant la nouvelle Azure SQL Database ou SQL Managed Instance, et rejoindre ce réseau virtuel. Tout se trouve dans le même emplacement, réduisant le déplacement des données et les coûts associés, tout en optimisant les performances.
• Si l'emplacement de votre Azure SQL Database ou SQL Managed Instance existant n'est pas le même que celui d'un réseau virtuel connecté à votre réseau sur site, créez d'abord votre IR Azure-SSIS en utilisant un Azure SQL Database ou un SQL Managed Instance existant et rejoindre un autre réseau virtuel au même endroit. Ensuite, configurez une connexion de réseau virtuel à réseau virtuel entre les différents sites.

Le schéma suivant représente les paramètres d’emplacement de Data Factory et de ses runtimes d’intégration :

Détermination du runtime d'intégration à utiliser

Si une activité s’associe à plusieurs types de runtime d’intégration, elle se résout à l’une d’entre elles. L’exécution d’intégration auto-hébergée prime sur l’exécution d’intégration Azure dans Azure Data Factory ou les instances de l’espace de travail Synapse qui utilisent un réseau virtuel géré. Et ce dernier est prioritaire sur le runtime d’intégration Azure global.

Par exemple, une activité de copie est utilisée pour copier des données de la source vers le récepteur. Le runtime d’intégration Azure global est associé au service lié à la source, et un runtime d'intégration Azure dans le réseau virtuel géré d'Azure Data Factory est associé au service lié au puits. Ainsi, les services liés de la source et du puits utilisent le runtime d'intégration Azure dans le réseau virtuel géré d'Azure Data Factory. Toutefois, si un runtime d'intégration auto-hébergé est associé au service lié pour la source, alors les services liés source et récepteur utilisent le même runtime d'intégration auto-hébergé.

Activité de copie

Pour l’activité de copie, les services liés source et récepteur doivent être indiqués pour définir la direction du flux de données. La logique suivante est utilisée pour déterminer l’instance de runtime d’intégration qui effectue la copie :

• Copie entre deux sources de données cloud : lorsque les services liés source et récepteur utilisent tous deux Azure IR, le runtime d’intégration Azure IR régional est utilisé s’il a été spécifié, ou l’emplacement du runtime d’intégration Azure est automatiquement déterminé si l’option de runtime d’intégration à résolution automatique (par défaut) a été choisie comme décrit dans la section Emplacement du runtime d’intégration.
• Copie entre une source de données cloud et une source de données d’un réseau privé : si le service lié source ou récepteur pointe vers un runtime d’intégration auto-hébergé, l’activité de copie est exécutée sur ce runtime d’intégration.
• Copie entre deux sources de données d’un réseau privé : les services liés source et récepteur doivent tous deux pointer vers la même instance du runtime d’intégration. Ce runtime d’intégration est utilisé pour exécuter l’activité de copie.

Activité Lookup/GetMetadata

L’activité Lookup/GetMetadata est exécutée sur le runtime d'intégration associé au service lié de la banque de données.

Activité de transformation externe

Chaque activité de transformation externe utilisant un moteur de calcul externe possède un service lié au calcul cible, qui pointe vers un temps d’exécution d’intégration. Cette instance du runtime d’intégration détermine l’emplacement à partir duquel l’activité de transformation externe codée manuellement est distribuée.

Activité Data Flow

Les activités Data Flow sont exécutées sur le runtime d’intégration Azure associé à celles-ci. Les propriétés de flux de données dans votre Azure IR déterminent le calcul Spark utilisé, et sont entièrement gérées par le service.

Temps d’exécution d’intégration en CI/CD

Les runtimes d’intégration ne changent pas souvent et sont similaires dans toutes les phases de CI/CD. Data Factory s’attend à ce que vous ayez le même nom et le même type de runtime d’intégration dans toutes les phases de CI/CD. Si vous souhaitez partager des environnements d'exécution d'intégration à travers toutes les phases, envisagez d'utiliser une usine dédiée destinée uniquement à contenir les environnements d'exécution d'intégration partagés. Vous pouvez alors utiliser cette fabrique partagée dans tous vos environnements en tant que type de runtime d’intégration lié.

Contenu connexe

Voir les articles suivants :

• Créer un runtime d’intégration Azure
• Créer un runtime d’intégration auto-hébergé
• Créer un runtime d’intégration Azure-SSIS. Cet article s’appuie sur le tutoriel et fournit des instructions sur la façon d’utiliser une instance managée SQL et de joindre le runtime d’intégration à un réseau virtuel.