Partage via

Résoudre les problèmes de performances de l’activité de copie

  • 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 !

Cet article décrit comment résoudre les problèmes de performances de l’activité de copie dans Azure Data Factory.

Après avoir exécuté une activité de copie, vous pouvez collecter les résultats de l’exécution et les statistiques de performances dans l’affichage de l’analyse de l’activité de copie. L’image suivante en montre un exemple.

Détails de l’analyse d’une exécution d’activité de copie

Conseils sur le réglage des performances

Dans certains scénarios, lorsque vous exécutez une activité Copy, vous voyez « Conseils de réglage des performances » en haut, comme indiqué dans l'image précédente. Les conseils vous indiquent le goulot d’étranglement identifié par le service pour cette exécution de copie spécifique, ainsi que des suggestions sur la manière d’améliorer le débit de copie. Essayez d’effectuer la modification recommandée, puis réexécutez la copie.

À titre de référence, les conseils de réglage des performances fournissent actuellement des suggestions pour les cas suivants :

Category Conseils sur le réglage des performances
Spécifique au magasin de données Chargement de données dans Azure Synapse Analytics : suggérez le recours à PolyBase ou à l’instruction COPY si elle n’est pas utilisée.
  Copie de données depuis/vers Azure SQL Database : lorsque la DTU est très utilisée, suggérez une mise à niveau vers un niveau supérieur.
  Copie de données depuis/vers Azure Cosmos DB : lorsque la RU est très utilisée, suggérez une mise à niveau vers une RU plus importante.
Copie de données à partir de la table SAP : lors de la copie d'une grande quantité de données, nous vous suggérons d'utiliser l'option de partition du connecteur SAP pour activer le chargement parallèle et augmenter le nombre maximal de partitions.
  Ingestion de données à partir d’Amazon Redshift : suggérez l’utilisation de UNLOAD si elle n’est pas utilisée.
Limitation du magasin de données Si de nombreuses opérations de lecture/écriture sont limitées par le magasin de données pendant la copie, suggérez de vérifier et d'augmenter le taux de requête autorisé pour le magasin de données, ou de réduire la charge de travail simultanée.
Runtime d’intégration Si vous utilisez un runtime d’intégration (IR) auto-hébergé et que l’activité de copie attend longtemps dans la file d’attente avant que le runtime d’intégration ne dispose des ressources nécessaires à son exécution, suggérez une montée en charge ou en puissance de votre IR.
  Si vous utilisez un Azure Integration Runtime qui se trouve dans une région non optimale, ce qui entraîne une lecture/écriture lente, suggérez de configurer l’utilisation d’un IR dans une autre région.
Tolérance de panne Si vous configurez la tolérance de panne et que le fait d’ignorer des lignes incompatibles entraîne un ralentissement des performances, suggérez de vous assurer que les données de la source et du récepteur sont compatibles.
copie intermédiaire Si la copie intermédiaire est configurée, mais n’est pas utile pour votre paire source-récepteur, suggérez de la supprimer.
Reprendre Lorsque l’activité de copie est reprise à partir du dernier point d’échec, mais que vous modifiez le paramètre DIU après l’exécution d’origine, notez que le nouveau paramètre DIU n’est pas appliqué.

Comprendre les détails de l’exécution de l’activité de copie

Les détails et les durées d’exécution en bas de l’affichage de l’analyse de l’activité de copie décrivent les principales étapes de l’activité de copie (voir l’exemple au début de cet article), ce qui est particulièrement utile pour la résolution des problèmes de performances de copie. Le goulet d’étranglement de votre exécution de copie est celui dont la durée est la plus longue. Reportez-vous au tableau suivant sur la définition de chaque étape et découvrez comment résoudre les problèmes liés à l’activité de copie sur Azure IR et résoudre les problèmes liés à l’activité de copie sur un IR auto-hébergé avec ces informations.

Étape Description
File d'attente Temps écoulé jusqu’à ce que l’activité de copie commence sur le runtime d’intégration.
Script de pré-copie Le temps écoulé entre le démarrage de l'activité Copy sur IR et la fin de l'activité de copie exécutant le script de pré-copie dans le magasin de données récepteur. Appliquez-le lorsque vous configurez le script de pré-copie pour les récepteurs de base de données, par exemple, lors de l’écriture de données dans Azure SQL Database, effectuez un nettoyage avant de copier de nouvelles données.
Transférer Temps écoulé entre la fin de l’étape précédente et le transfert par le runtime de toutes les données de la source vers le récepteur.
Notez que les sous-étapes du transfert s'exécutent en parallèle et que certaines opérations ne sont pas affichées maintenant, par exemple l'analyse/génération du format de fichier.

- Temps jusqu’au premier octet : Temps écoulé entre la fin de l’étape précédente et l’heure à laquelle le runtime d'intégration reçoit le premier octet du magasin de données source. S’applique aux sources non basées sur des fichiers.
- Liste des sources : Durée d’énumération des fichiers sources ou des partitions de données. Ce dernier s'applique lorsque vous configurez des options de partition pour les sources de base de données, par exemple, lors de la copie de données à partir de bases de données telles qu'Oracle/SAP HANA/Teradata/Netezza/etc.
- Lecture à partir de la source : Durée de récupération des données dans le magasin de données source.
- Écriture dans le récepteur : Durée d’écriture des données dans le magasin de données récepteur. Notez que certains connecteurs ne disposent pas de cette mesure pour le moment, notamment Azure AI Search, Azure Data Explorer, Stockage Table Azure, Oracle, SQL Server, Common Data Service, Dynamics 365, Dynamics CRM, Salesforce/Salesforce Service Cloud.

Résoudre les problèmes liés à l’activité de copie sur Azure IR

Suivez la procédure de réglage des performances pour planifier et effectuer un test de performances pour votre scénario.

Si les performances de l’activité de copie ne répondent pas à vos attentes et si vous voyez Conseils sur le réglage des performances affiché dans la vue de l’analyse de copie, appliquez la suggestion, puis réessayez pour résoudre les problèmes liés à l’activité de copie unique exécutée sur Azure Integration Runtime. Dans le cas contraire, comprenez les détails de l’exécution de l’activité de copie, vérifiez quelle étape a la durée la plus longue et appliquez les conseils ci-dessous pour améliorer les performances de copie :

  • Le « script pré-copie » a connu une longue durée de vie : cela signifie que le script de pré-copie exécuté sur la base de données du récepteur prend du temps à se terminer. Ajustez la logique du script de pré-copie spécifié pour améliorer les performances. Si vous avez besoin d’aide pour améliorer le script, contactez votre équipe de base de données.

  • Le « transfert – temps jusqu’au premier octet » a connu une longue durée de travail : cela signifie que votre requête source prend beaucoup de temps pour retourner des données. Vérifiez et optimisez la requête ou le serveur. Si vous avez besoin d’une aide supplémentaire, contactez votre équipe de magasin de données.

  • Le « transfert – liste des sources » a connu une longue durée de travail : cela signifie que l’énumération des fichiers sources ou des partitions de données de la base de données source est lente.

    • Lorsque vous copiez des données à partir d’une source basée sur des fichiers, si vous utilisez le filtre de caractères génériques sur le chemin d’accès au dossier ou le nom de fichier (wildcardFolderPath ou wildcardFileName), ou si vous utilisez le filtre de l’heure de dernière modification du fichier (modifiedDatetimeStart ou modifiedDatetimeEnd), notez qu’un tel filtre entraînerait une activité de copie répertoriant tous les fichiers sous le dossier spécifié vers le côté client puis appliquerait le filtre. Cette énumération de fichiers peut devenir le goulot d’étranglement, en particulier lorsque seul un petit ensemble de fichiers répond à la règle de filtre.

    • Vérifiez si le service signale une erreur de limitation sur la source ou si votre magasin de données est dans un état d’utilisation élevée. Si c’est le cas, réduisez vos charges de travail sur le magasin de données ou essayez de contacter votre administrateur de magasin de données pour augmenter la valeur de limitation ou la ressource disponible.

    • Utilisez Azure IR dans la région de votre magasin de données source ou près de celle-ci.

  • Le « transfert – lecture à partir de la source » a connu une longue durée de travail :

    • adoptez les meilleures pratiques de chargement de données spécifiques au connecteur si elles s’appliquent. Par exemple, lorsque vous copiez des données à partir d’Amazon Redshift, configurez l’utilisation de Redshift UNLOAD.

    • Vérifiez si le service signale une erreur de limitation sur la source ou si votre magasin de données est soumis à une utilisation intensive. Si c’est le cas, réduisez vos charges de travail sur le magasin de données ou essayez de contacter votre administrateur de magasin de données pour augmenter la valeur de limitation ou la ressource disponible.

    • Vérifiez votre modèle de source et de récepteur de copie :

    • Utilisez Azure IR dans la région de votre magasin de données source ou près de celle-ci.

  • Le « transfert – écriture dans le récepteur » a connu une longue durée de travail :

    • Adoptez les meilleures pratiques de chargement de données spécifiques au connecteur si elles s’appliquent. Par exemple, pour copier des données dans Azure Synapse Analytics, utilisez PolyBase ou l’instruction COPY.

    • Vérifiez si le service signale une erreur de limitation sur le récepteur ou si votre magasin de données est soumis à une utilisation intensive. Si c’est le cas, réduisez vos charges de travail sur le magasin de données ou essayez de contacter votre administrateur de magasin de données pour augmenter la valeur de limitation ou la ressource disponible.

    • Vérifiez votre modèle de source et de récepteur de copie :

      • Si votre modèle de copie prend en charge plus de quatre unités d'intégration de données (DIU), reportez-vous à cette section pour plus de détails. En général, vous pouvez essayer d'augmenter les DIU pour obtenir de meilleures performances.

      • Sinon, ajustez progressivement les copies parallèles. Trop de copies parallèles pourraient même nuire aux performances.

    • Utilisez Azure IR dans la région de votre magasin de données récepteur ou près de celle-ci.

Résoudre les problèmes liés à l’activité de copie sur IR auto-hébergé

Suivez la procédure de réglage des performances pour planifier et effectuer un test de performances pour votre scénario.

Si les performances de copie ne répondent pas à vos attentes et si vous voyez Conseils sur le réglage des performances affiché dans la vue de l’analyse de copie, appliquez la suggestion, puis réessayez pour résoudre les problèmes liés à l’activité de copie unique exécutée sur Azure Integration Runtime. Dans le cas contraire, comprenez les détails de l’exécution de l’activité de copie, vérifiez quelle étape a la durée la plus longue et appliquez les conseils ci-dessous pour améliorer les performances de copie :

  • La « file d’attente » a connu une longue durée : cela signifie que l’activité de copie attend longtemps dans la file d’attente avant que votre IR auto-hébergé ne dispose des ressources nécessaires à son exécution. Vérifiez la capacité et l’utilisation du runtime d’intégration, puis montez en puissance ou en charge en fonction de votre charge de travail.

  • Le « transfert – temps jusqu’au premier octet » a connu une longue durée de travail : cela signifie que votre requête source prend beaucoup de temps pour retourner des données. Vérifiez et optimisez la requête ou le serveur. Si vous avez besoin d’une aide supplémentaire, contactez votre équipe de magasin de données.

  • Le « transfert – liste des sources » a connu une longue durée de travail : cela signifie que l’énumération des fichiers sources ou des partitions de données de la base de données source est lente.

    • Vérifiez si l’ordinateur IR auto-hébergé a une faible latence lors de la connexion au magasin de données source. Si votre source est dans Azure, vous pouvez utiliser cet outil pour vérifier la latence de l’ordinateur IR auto-hébergé dans la région Azure, sachant que moins la latence est importance, mieux c’est.

    • Lorsque vous copiez des données à partir d’une source basée sur des fichiers, si vous utilisez le filtre de caractères génériques sur le chemin d’accès au dossier ou le nom de fichier (wildcardFolderPath ou wildcardFileName), ou si vous utilisez le filtre de l’heure de dernière modification du fichier (modifiedDatetimeStart ou modifiedDatetimeEnd), notez qu’un tel filtre entraînerait une activité de copie répertoriant tous les fichiers sous le dossier spécifié vers le côté client puis appliquerait le filtre. Cette énumération de fichiers peut devenir le goulot d’étranglement, en particulier lorsque seul un petit ensemble de fichiers répond à la règle de filtre.

    • Vérifiez si le service signale une erreur de limitation sur la source ou si votre magasin de données est dans un état d’utilisation élevée. Si c’est le cas, réduisez vos charges de travail sur le magasin de données ou essayez de contacter votre administrateur de magasin de données pour augmenter la valeur de limitation ou la ressource disponible.

  • Le « transfert – lecture à partir de la source » a connu une longue durée de travail :

    • Vérifiez si l’ordinateur IR auto-hébergé a une faible latence lors de la connexion au magasin de données source. Si votre source est dans Azure, vous pouvez utiliser cet outil pour vérifier la latence de l’ordinateur IR auto-hébergé dans les régions Azure, sachant que moins la latence est importance, mieux c’est.

    • Vérifiez si l’ordinateur IR auto-hébergé a suffisamment de bande passante entrante pour lire et transférer les données efficacement. Si votre magasin de données source est dans Azure, vous pouvez utiliser cet outil pour vérifier la vitesse de téléchargement.

    • Vérifiez la tendance d’utilisation de l’UC et de la mémoire de l’IR auto-hébergé dans le Portail Azure -> votre fabrique de données ou espace de travail Synapse -> page de vue d’ensemble. Envisagez de monter en puissance ou en charge l’IR si l’utilisation de l’UC est élevée ou si la mémoire disponible est faible.

    • Adoptez les meilleures pratiques de chargement de données spécifiques au connecteur si elles sont applicables. Par exemple :

      • Lorsque vous copiez des données à partir des magasins de données Oracle, Netezza, Teradata, SAP HANA, SAP Table et SAP Open Hub, activer les options de partition de données pour copier les données en parallèle.

      • Lorsque vous copiez des données à partir de HDFS, configurez l’utilisation de DistCp.

      • Lorsque vous copiez des données à partir d’Amazon Redshift, configurez l’utilisation de Redshift UNLOAD.

    • Vérifiez si le service signale une erreur de limitation sur la source ou si votre magasin de données est soumis à une utilisation intensive. Si c’est le cas, réduisez vos charges de travail sur le magasin de données ou essayez de contacter votre administrateur de magasin de données pour augmenter la valeur de limitation ou la ressource disponible.

    • Vérifiez votre modèle de source et de récepteur de copie :

  • Le « transfert – écriture dans le récepteur » a connu une longue durée de travail :

    • Adoptez les meilleures pratiques de chargement de données spécifiques au connecteur si elles s’appliquent. Par exemple, pour copier des données dans Azure Synapse Analytics, utilisez PolyBase ou l’instruction COPY.

    • Vérifiez si l’ordinateur IR auto-hébergé a une faible latence lors de la connexion au magasin de données du récepteur. Si votre récepteur est dans Azure, vous pouvez utiliser cet outil pour vérifier la latence de l’ordinateur IR auto-hébergé dans la région Azure, sachant que moins la latence est importance, mieux c’est.

    • Vérifiez si l’ordinateur IR auto-hébergé a suffisamment de bande passante sortante pour transférer et écrire les données efficacement. Si votre magasin de données récepteur est dans Azure, vous pouvez utiliser cet outil pour vérifier la vitesse de chargement.

    • Vérifiez la tendance d’utilisation de l’UC et de la mémoire de l’IR auto-hébergé dans le Portail Azure -> votre fabrique de données -> page de vue d’ensemble. Envisagez de monter en puissance ou en charge l’IR si l’utilisation de l’UC est élevée ou si la mémoire disponible est faible.

    • Vérifiez si le service signale une erreur de limitation sur le récepteur ou si votre magasin de données est soumis à une utilisation intensive. Si c’est le cas, réduisez vos charges de travail sur le magasin de données ou essayez de contacter votre administrateur de magasin de données pour augmenter la valeur de limitation ou la ressource disponible.

    • Envisagez de régler progressivement les copies parallèles. Trop de copies parallèles pourraient même nuire aux performances.

Performances du connecteur et du runtime d’intégration (IR)

Cette section explore certains guides de résolution des problèmes en matière de performances pour un type de connecteur spécifique ou pour le runtime d’intégration.

Le temps d'exécution de l'activité varie selon qu’Azure Integration Runtime est utilisé ou non par le réseau virtuel Azure

La durée d’exécution de l’activité varie quand le jeu de données est basé sur différents runtime d’intégration.

  • Symptômes : L’activation/désactivation de la liste déroulante Service lié dans le jeu de données effectue les mêmes activités de pipeline, mais avec des délais d’exécution radicalement différents. Lorsque le jeu de données est basé sur le runtime d’intégration de réseau virtuel géré, il faut plus de temps en moyenne que n’en nécessite l’exécution quand elle est basée sur le runtime d’intégration par défaut.

  • Cause : En vérifiant les détails des exécutions de pipeline, vous pouvez voir que le pipeline lent s’exécute sur le réseau virtuel géré (Virtual Network) IR tandis que le pipeline normal s’exécute sur Azure IR. De par sa conception, l'IR de réseau virtuel géré prend plus de temps en file d'attente qu'Azure IR, car nous ne réservons pas un nœud de calcul par instance de service. Il y a donc un préchauffage pour chaque activité Copy à démarrer, et cela se produit principalement lors de la jonction au réseau virtuel plutôt que lors de l'IR Azure.

Faible niveau de performance pendant le chargement de données dans Azure SQL Database

  • Symptômes : La copie de données dans Azure SQL Database devient lente.

  • Cause : La cause racine du problème est principalement provoquée par le goulot d’étranglement du côté d’Azure SQL Database. Voici quelques causes possibles :

    • Le niveau de base de données Azure SQL n’est pas suffisamment élevé.

    • L’utilisation des DTU d’Azure SQL Database est proche de 100 %. Vous pouvez superviser le niveau de performance et envisager une mise à niveau d’Azure SQL Database.

    • Les index ne sont pas définis correctement. Supprimez tous les index avant le chargement des données, puis recréez-les une fois le chargement terminé.

    • WriteBatchSize n'est pas assez grand pour s'adapter à la taille des lignes du schéma. Essayez d’attribuer une valeur supérieure à la propriété pour résoudre le problème.

    • Une procédure stockée est utilisée à la place de l’insertion en bloc, ce qui est censé amoindrir le niveau de performance.

Délai d'attente ou performances lentes lors de l'analyse d'un fichier Excel volumineux

  • Symptômes :

    • Lorsque vous créez un ensemble de données Excel et importez un schéma à partir d'une connexion/d'un magasin, prévisualisez des données, répertoriez ou actualisez des feuilles de calcul, vous pouvez rencontrer une erreur de délai d'attente si le fichier Excel est volumineux.

    • Lorsque vous utilisez l'activité Copy pour copier des données d'un fichier Excel volumineux (>= 100 Mo) vers un autre magasin de données, vous pouvez rencontrer des performances lentes ou un problème OOM.

  • Cause :

    • Pour des opérations telles que l'importation de schémas, la prévisualisation de données et la liste de feuilles de calcul sur un ensemble de données Excel. Le délai d'attente est de 100 s et statique. Pour les fichiers Excel volumineux, ces opérations peuvent ne pas se terminer dans le délai imparti.

    • L’activité de copie lit l’intégralité du fichier Excel en mémoire, puis localise la feuille de calcul et les cellules spécifiées pour lire les données. Ce comportement est dû à l’utilisation du Kit de développement logiciel (SDK) sous-jacent.

  • Résolution :

    • Pour importer un schéma, vous pouvez générer un exemple de fichier plus petit représentant un sous-ensemble du fichier d’origine, puis choisir « import schema from sample file » (importer le schéma à partir d’un exemple de fichier) au lieu de « import schema from connection/store » (importer le schéma à partir d’une connexion/d’un magasin).

    • Pour répertorier les feuilles de calcul, dans la liste déroulante des feuilles de calcul, vous pouvez sélectionner « Modifier » et saisir le nom/l'index de la feuille à la place.

    • Pour copier un fichier Excel volumineux (>100 Mo) dans un autre magasin, vous pouvez utiliser le flux de données source Excel qui prend en charge la diffusion en continu et offre de meilleures performances.

Problème de mémoire insuffisante (OOM) lié à la lecture de fichiers JSON/Excel/XML volumineux

  • Symptômes : lorsque vous lisez des fichiers JSON/Excel/XML volumineux, vous rencontrez le problème de mémoire insuffisante (OOM) pendant l’exécution de l’activité.

  • Cause :

    • Pour des fichiers XML volumineux : le problème OOM lié à la lecture de fichiers XML volumineux est normal. La raison en est que l’intégralité du fichier XML doit être lue en mémoire, car il s’agit d’un objet unique. Le schéma est ensuite déduit et les données sont récupérées.
    • Pour des fichiers Excel volumineux : le problème OOM lié à la lecture de fichiers Excel volumineux est normal. En effet, le Kit de développement logiciel (SDK) POI/NPOI utilisé doit lire l’intégralité du fichier Excel en mémoire, puis déduire le schéma et obtenir des données.
    • Pour des fichiers JSON volumineux : le problème OOM lié à la lecture de fichiers JSON volumineux est normal lorsque le fichier JSON est un objet unique.

  • Recommandation : appliquez l’une des options suivantes pour résoudre votre problème.

    • Option 1 : inscrivez un runtime d’intégration auto-hébergé en ligne à l’aide d’un ordinateur puissant (processeur/mémoire élevée) pour lire les données de votre fichier volumineux via votre activité de copie.
    • Option 2 : utilisez une mémoire optimisée et un cluster de grande taille (par exemple, 48 cœurs) pour lire les données de votre fichier volumineux via l’activité de flux de données de mappage.
    • Option 3 : fractionnez le fichier volumineux en petits fichiers, puis utilisez l’activité de flux de données de mappage ou de copie pour lire le dossier.
    • Option-4 : Si vous êtes bloqué ou rencontrez le problème OOM lors de la copie du dossier XML/Excel/JSON, utilisez l'activité ForEach + l'activité de flux de données de copie/flux de données de mappage dans votre pipeline pour gérer chaque fichier ou sous-dossier.
    • Option 5 : autres :
      • Pour XML, utilisez l’activité Notebook avec un cluster mémoire optimisé pour lire les données à partir des fichiers si chaque fichier a le même schéma. Actuellement, Spark dispose de différentes implémentations pour gérer XML.
      • Pour JSON, utilisez différents formulaires de document (par exemple, Document unique, Document par ligne et Tableau de documents) dans les paramètres JSON sous source de flux de données de mappage. Si le contenu du fichier JSON est Document par ligne, il consomme peu de mémoire.

Autres références

Voici les références de surveillance et de réglage des performances pour certains des magasins de données pris en charge :

Contenu connexe

Consultez les autres articles relatifs à l’activité de copie :