Partager via

Infrastructure Integration Runtime dans Azure Data Factory

  • Article

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Le runtime d’intégration (IR) représente 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 dans 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 lié ou les références d’activité et fournit l’environnement de calcul dans lequel l’activité est exécutée directement ou distribué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 de runtime d’intégration (IR). Vous devez choisir le type qui répond le mieux à vos besoins en matière de fonctionnalités d’intégration de données et d’environnement réseau. Les trois types de runtime d’intégration sont les suivants :

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

Notes

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 Data Flow
Déplacement des données
Répartition des activités		 Data Flow
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

Notes

Les contrôles sortants varient selon le service pour Azure IR. Dans Synapse, les espaces de travail ont des options pour limiter le trafic sortant à partir du réseau virtuel managé lors de l’utilisation d’Azure IR. Dans Data Factory, tous les ports sont ouverts pour les communications sortantes lors de l’utilisation d’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 magasins de données cloud
  • Répartir les activités de transformation suivantes dans un réseau public :
    • Activité personnalisée .NET
    • Activité de fonction Azure
    • Activité Databricks Notebook/Jar/Python
    • Activité U-SQL Data Lake Analytics
    • 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 Machine Learning Studio (classique)
    • Activité de ressource de mise à jour Machine Learning Studio (classique)
    • Activité de procédure stockée
    • Activité de validation
    • Activité web

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

L'infrastructure Azure Integration Runtime prend en charge les connexions aux magasins de données et aux services de calcul à l'aide de points de terminaison publiquement accessibles. Lorsque vous activez le réseau virtuel managé, Azure Integration Runtime prend en charge la connexion aux magasins de données à l’aide du service de liaison privée dans un environnement de 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 Integration Runtime peut être intégré à votre réseau virtuel pour fournir des contrôles de communications sortantes.

Ressources de calcul et mise à l’échelle du runtime d'intégration Azure

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é. En outre, vous payez uniquement pendant l’utilisation réelle.

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 le nombre d’unités d’intégration des données à utiliser sur l’activité de copie. Ainsi, la taille de calcul du runtime d’intégration Azure est mise à l’échelle sans que vous deviez ajuster la taille du runtime d’intégration Azure.

La répartition des activités est une opération légère pour acheminer l’activité vers le service de calcul cible. Par conséquent, vous n’avez pas besoin de mettre la taille de calcul à l’échelle pour 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.

Notes

Le runtime d’intégration Azure possède des propriétés liées au runtime Data Flow, définissant l’infrastructure de calcul sous-jacente qui sera 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écuter une activité de copie entre des magasins de données cloud et un magasin de données situé sur 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é U-SQL Data Lake Analytics
    • 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 Machine Learning Studio (classique)
    • Activité de ressource de mise à jour Machine Learning Studio (classique)
    • Activité d’exécution des pipelines Machine Learning
    • Activité de procédure stockée
    • Activité de validation
    • Activité web

Remarque

Utilisez le runtime d’intégration auto-hébergé pour prendre en charge les magasins de données qui nécessitent votre propre pilote, comme SAP Hana, MySQL, etc. Pour plus d’informations, consultez Magasins de données pris en charge.

Notes

Java Runtime Environment (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 effectuer une opération lift-and-shift sur la charge de travail SSIS existante, vous pouvez créer un runtime d’intégration Azure SSIS 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 peut être configuré dans un réseau public ou un réseau privé. L’accès aux données sur site est pris en charge en associant le runtime d’intégration Azure SSIS à un réseau virtuel connecté à votre réseau local.

Ressources de calcul et mise à l’échelle du runtime d’intégration Azure SSIS

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 maîtriser le coût d’exécution de votre runtime d’intégration Azure SSIS en l’arrêtant et en le démarrant comme vous le souhaitez.

Pour plus d’informations, voir Comment créer et configurer un runtime d’intégration 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.
  • Monitor an Azure-SSIS IR (Surveiller le runtime d’intégration Azure-SSIS). Cet article explique comment récupérer des informations sur un runtime d’intégration Azure-SSIS ainsi que des descriptions d’état dans les informations renvoyées.
  • Manage an Azure-SSIS IR (Gérer un runtime d’intégration Azure-SSIS). Cet article vous explique comment arrêter, démarrer ou supprimer un runtime d’intégration Azure-SSIS. Il vous montre également comment effectuer un scale-out en lui ajoutant des nœuds supplémentaires.
  • Joindre un runtime d’intégration 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 la fabrique et l’emplacement du runtime d’intégration

Lorsque vous créez une instance 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 du runtime d’intégration définit l’emplacement de son calcul principal, mais aussi l’emplacement où le déplacement des données, la répartition des activités et l’exécution des packages SSIS sont effectués. L’emplacement du runtime d’intégration peut être différent de l’emplacement de la fabrique de données à laquelle il appartient.

Emplacement du runtime d'intégration Azure

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.

La valeur par défaut consiste à résoudre automatiquement Azure IR dans le réseau public. Avec cette option :

  • Pour l’activité de copie, il est préférable de détecter automatiquement l’emplacement de votre magasin de données récepteur, puis d’utiliser le runtime d’intégration dans la même région, le cas échéant, ou le plus proche dans la même zone géographique ; si la région du magasin de données récepteur n’est pas détectable, le runtime d'intégration dans la région de l’instance est utilisé à la place.

    Par exemple, un espace de travail Data Factory ou Synapse dans la région USA Est,

    • 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 le runtime d’intégration dans la région USA Est.

    Conseil

    Si vous avez des exigences strictes en matière de conformité des données et que vous devez vous assurer que les données ne quittent pas une certaine zone géographique, vous pouvez créer explicitement Azure IR dans une certaine région et pointer le service lié vers ce runtime d’intégration à l’aide de la propriété ConnectVia. Par exemple, si vous souhaitez copier des données d’un objet blob au Royaume-Uni Sud vers un espace de travail Azure Synapse au Royaume-Uni Sud et que vous souhaitez vous assurer que les données ne quittent pas le Royaume-Uni, créez un Azure IR au Royaume-Uni Sud et liez les deux services liés à ce runtime d’intégration.

  • Pour l’exécution des activités Lookup/GetMetadata/Delete (activités Pipeline), la répartition des activités de transformation (activités External) et les opérations de création (tester la connexion, parcourir la liste des dossiers et des tables, prévisualiser les données), l’IR dans la même région que l’espace de travail Data Factory ou Synapse est utilisé.

  • Pour Data Flow, c’est l’IR de la région de l’espace de travail Data Factory ou Synapse qui est utilisé.

    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 effectuer cette opération avec la résolution automatique pour le runtime d’intégration Azure (si l’emplacement du magasin de données est identique à l’emplacement de l’espace de travail Data Factory ou Synapse), ou en créant une instance Azure IR dans la même région que vos magasins de données, puis en exécutant les flux de données sur celui-ci.

Si vous activez le réseau virtuel managé avec la résolution automatique pour Azure IR, le runtime d’intégration dans la région Data Factory ou Espace de travail Synapse est utilisé.

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é

Le runtime d’intégration auto-hébergé est logiquement inscrit auprès de l’espace de travail Data Factory ou Synapse, et il vous revient de fournir le calcul utilisé pour prendre en charge 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 procéder au déplacement des données, le runtime d’intégration auto-hébergé extrait des données de la source et les écrit dans la destination.

Emplacement du runtime d’intégration Azure SSIS

Remarque

Azure-SSIS Integration Runtime ne sont actuellement pas 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. De cette manière, le runtime d’intégration Azure SSIS peut facilement accéder au SSISDB sans être entravé par le trafic entre les 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 à l’aide de la nouvelle instance managée ou Azure SQL Database, et joindre 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 base de données SQL Azure ou instance managée SQL existante n’est pas le même que celui d’un réseau virtuel connecté à votre réseau local, créez d’abord votre runtime d’intégration Azure-SSIS en utilisant une base de données SQL Azure ou une instance managée SQL existante et en joignant un autre réseau virtuel situé au même emplacement. Ensuite, configurez un réseau virtuel sur une connexion de réseau virtuel entre les différents emplacements.

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

Montre les emplacements des runtimes d’intégration Data Factory.

Choix du runtime d’intégration

Si une activité s’associe à plusieurs types de runtime d’intégration, elle se résout à l’une d’entre elles. Le runtime d’intégration auto-hébergé est prioritaire sur le runtime d’intégration Azure dans les instances d’espace de travail Data Factory ou Synapse qui utilisent un réseau virtuel managé. 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 Azure Data Factory managé est associé au service lié au récepteur. Ainsi, la source et le service lié du récepteur utilisent le runtime d’intégration Azure dans le réseau virtuel Azure Data Factory managé. Toutefois, si un runtime d’intégration auto-hébergé est associé au service lié pour la source, le service lié source et récepteur utilise le 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 qui utilise un moteur de calcul externe a un service de calcul cible lié qui pointe vers un runtime 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 du flux de données dans Azure Integration Runtime déterminent le calcul Spark utilisé et sont entièrement gérées par le service.

Runtime d’intégration pour l’intégration continue et la livraison continue

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 voulez partager les runtimes d’intégration dans toutes les phases, envisagez d’utiliser une fabrique dédiée qui contiendra uniquement les runtimes 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 :