Optimisation des performances dans Informatica : didacticiel complet

Par : David Carter David Carter
Hours Le kit de préparation mis à jour

⚡ Résumé intelligent

L'optimisation des performances dans Informatica supprime le maillon le plus lent d'une session, couche par couche, en partant de la cible et en remontant vers la source, la carte.ping, la session et enfin le système d'exploitation.

  • (I.e. Ordre fixe : Informatica recommande de rechercher les goulots d'étranglement dans l'ordre suivant : cible, puis source, puis mappageping, puis session, puis système.
  • 🧵 Les statistiques du fil de discussion parlent d'elles-mêmes : Le fil le plus actif parmi ceux du lecteur, de la transformation et de l'écrivain désigne la couche qui nécessite un travail.
  • 🚿 Filtrer tôt : Les lignes écartées lors du qualificateur de source n'entrent jamais dans le pipeline, elles ne coûtent donc rien en aval.
  • 🇧🇷 Transférer les données vers la base de données : Les jointures, les tris et les filtres s'exécutent généralement plus rapidement en SQL que dans une transformation.
  • 🧊 Discipline du cache : Moins de ports et moins de colonnes de recherche signifient des caches plus petits et moins de pagination disque.
  • ⚙️ Les paramètres de session sont importants : La taille du tampon DTM, la taille des blocs de tampon, l'intervalle de validation et l'optimisation du pushdown sont ajustés après la map.ping est propre.
En savoir plus

Optimisation des performances dans Informatica

Qu'est-ce que l'optimisation des performances dans Informatica ?

L'optimisation des performances dans Informatica consiste à identifier le composant qui ralentit l'exécution d'une session, à supprimer ce facteur limitant, puis à répéter l'opération avec le composant qui devient ensuite le plus lent. La vitesse d'une session étant toujours limitée par son composant le plus lent, optimiser une transformation qui n'a jamais été la cause du problème n'apporte aucun gain mesurable.

Informatica identifie cinq points où un goulot d'étranglement peut se situer et recommande de les vérifier dans un ordre précis.

Commande Couche Cause typique
1 Target Écritures lentes, intervalles de points de contrôle courts, taille réduite des paquets réseau de la base de données
2 Matériau Requête lente, index manquants, lecture de colonnes inutiles
3 Carteping Transformations coûteuses ou mal placées, caches surdimensionnées
4 Session Buffer mémoire, intervalle de validation, partitionnement, type de chargement
5 Système Saturation du processeur, attentes d'E/S, pagination sur la machine du service d'intégration

L'ordre est délibéré. ​​Une cible incapable d'absorber les lignes assez rapidement ralentira toutes les couches en amont ; elle est donc vérifiée en premier. La méthode complète est documentée dans le… Guide de réglage des performances PowerCenter.

Comment identifier les goulots d'étranglement en matière de performance

Deviner quelle couche est lente fait perdre plus de temps que de la mesurer. Quatre techniques permettent de traiter les cinq couches mentionnées ci-dessus.

  • Lancez une session de test. Configurez une copie de Session Pour écrire dans un fichier plat, si la vitesse de la session augmente sensiblement, le goulot d'étranglement se situe au niveau du fichier cible. L'opération inverse, consistant à lire depuis un fichier plat, permet d'isoler le goulot d'étranglement au niveau de la source.
  • Analyser les statistiques du fil de discussion. Le gestionnaire de transformation des données exécute un thread de lecture, un ou plusieurs threads de transformation et un thread d'écriture. Le thread présentant le temps d'activité le plus élevé dans le journal de session pointe directement vers la couche à traiter : le thread de lecture pour la source, le thread de transformation pour la carte.ping, écrivain pour la cible.
  • Analyser les détails de performance. Activez la collecte des données de performance sur la session et consultez les compteurs. Un nombre élevé de lignes d'erreur ou un grand nombre de lignes dans un cache de recherche indiquent un problème de mappage.ping Un problème plutôt qu'un problème de base de données.
  • Surveillez le système. OperaLes outils système affichant l'utilisation du processeur, les temps d'attente d'E/S et la pagination, ainsi que les Surveillance des flux de travail Les vues des ressources révèlent une machine tout simplement saturée.

Une fois la couche responsable identifiée, les conseils relatifs à la transformation présentés dans les sections suivantes deviennent pertinents. Ces sections sont organisées selon l'ordre du pipeline, à partir du point d'entrée des données. planping au point où il est agrégé.

Transformation de qualificateur de source

Chaque ligne non lue par le qualificateur de source est une ligne qu'aucune autre transformation n'a à traiter, ce qui en fait l'endroit le moins coûteux de toute la carte.ping gagner du temps.

  • Apportez uniquement les colonnes requises de la source. La plupart du temps, toutes les colonnes de la table source ne sont pas obligatoires, apportez donc uniquement les champs obligatoires en supprimant les colonnes inutiles.
  • Évitez d'utiliser la clause ORDER BY à l'intérieur de la clause ORDER BY. Qualificatif de source Surcharge de la requête SQL. La clause ORDER BY nécessite un traitement supplémentaire ; les performances peuvent être améliorées en l'évitant.

ARTICLES LIÉS

Transformation de filtre

Le filtrage suit le même principe une étape plus loin dans le pipeline : supprimer les lignes indésirables dès que possible.ping possède suffisamment d'informations pour les identifier.

  • Utilisez le transformation de filtre le plus tôt possible à l'intérieur de la cartepingSi les données indésirables peuvent être éliminées dès le début de la carteping, cela augmenterait le débit.
  • Utilisez un qualificateur de source pour filtrer les données. Vous pouvez également utiliser une substitution SQL du qualificateur de source pour filtrer les enregistrements, au lieu d'utiliser une transformation de filtre.

Transformation de menuisier

L'adhésion est la première opération véritablement coûteuse dans une carte typiqueping, car la source principale doit être mise en cache avant que les lignes de détail puissent y être comparées.

  • Il est toujours préférable d'effectuer les jointures directement dans la base de données, car elles sont plus rapides que celles créées dans Informatica. transformation de menuisier.
  • Triez les données avant de joindre si possible, car cela diminue les E/S de disque effectuées lors de la jointure.
  • Choisissez comme table principale la table comportant le moins de lignes.

Le troisième point est celui qui est le plus souvent négligé. Le service d'intégration met en cache la source principale ; par conséquent, désigner la table plus petite comme table principale permet de limiter la taille de ce cache.

Transformation de recherche

Une recherche interroge soit la base de données une fois par ligne, soit construit un cache en mémoire, et les deux méthodes permettent d'obtenir une source de recherche plus petite et mieux indexée.

  • Créez un index pour la colonne dans un table de correspondance Cette condition est utilisée pour la recherche. Étant donné que la table de recherche sera interrogée pour trouver les données correspondantes, l'ajout d'un index améliorerait les performances.
  • Si possible, au lieu d'utiliser la transformation de recherche, utilisez la jointure dans la base de données. Comme les jointures de bases de données sont plus rapides, les performances seront augmentées.
  • Supprimez les colonnes inutiles de la table de recherche et conservez uniquement les colonnes requises. Cela réduira la surcharge liée à la récupération des colonnes supplémentaires de la base de données.

Transformation Agrégation

An Aggregator Elle stocke les données dans un cache tout en regroupant les lignes ; par conséquent, tout ce qui réduit le volume de données qui lui parviennent réduit la taille du cache dont elle a besoin.

  • Filtrez les données avant de les agréger. Si vous utilisez une transformation de filtre dans la carteping, filtrez ensuite les données avant d'utiliser l'agrégateur, car cela réduira les opérations d'agrégation inutiles.
  • Limitez le nombre de ports utilisés dans la transformation d'agrégation. Cela réduira le volume de données stockées dans le cache par cette transformation.

Réglage au niveau de la session dans Informatica

Lorsque la carteping Le système en lui-même est propre ; les gains restants proviennent des propriétés de la session. Il est conseillé de modifier ces paramètres un par un, en effectuant un test chronométré après chaque modification, car plusieurs d'entre eux privilégient la vitesse à la mémoire.

Paramètres Ce qu'il contrôle Quand le changer
Taille du tampon DTM Mémoire totale allouée par le service d'intégration aux blocs de données source et cible Augmentez cette valeur lorsque la session gère de nombreuses partitions, sources ou cibles.
Buffer taille de bloc Taille d'un bloc de mémoire individuel Augmenter la valeur pour les lignes exceptionnellement longues ; diminuer la valeur lorsque la mémoire physique est limitée.
Intervalle d'engagement Combien de lignes sont écrites avant qu'un commit ne soit émis ? Augmentez ce seuil lorsque le thread d'écriture passe son temps à attendre les points de contrôle de la base de données.
Optimisation par poussée Quelle portion de la carteping La logique est convertie en SQL et exécutée par la base de données. À utiliser lorsque la source et la cible se trouvent sur la même base de données puissante.

Buffer La mémoire est allouée selon un calcul précis et documenté, et non par estimation. Le service d'intégration alloue au moins deux blocs pour chaque partition source et cible. Le nombre de blocs de mémoire tampon de session est donc égal à (nombre total de sources + nombre total de cibles) multiplié par deux, et la taille de la mémoire tampon DTM est égale à ce nombre de blocs multiplié par la taille d'un bloc de mémoire tampon et divisé par 0.9.

L'optimisation pushdown mérite d'être abordée avec prudence. Elle n'est utile que lorsque la base de données est réellement plus rapide que le serveur d'intégration et que la logique de transformation peut être exprimée en SQLLes éléments logiques non traduisibles restent dans la session, ce qui explique que le gain soit souvent inférieur aux attentes. Il est préférable de mesurer avant et après l'activation plutôt que de l'activer par défaut.

FAQ

Le partitionnement est utile lorsque la machine du service d'intégration dispose de ressources CPU disponibles et que la source et la cible peuvent gérer des connexions parallèles. Sur une machine saturée ou avec une cible mono-thread, les partitions supplémentaires engendrent une surcharge sans pour autant réduire la durée d'exécution.

Configurez l'index et le cache de données avec une taille suffisante pour contenir l'intégralité de la source de recherche ; sinon, les pages du service d'intégration seront écrites sur le disque. Les journaux de session indiquent la taille de cache réellement nécessaire ; effectuez donc une première exécution avec le dimensionnement automatique et consultez la valeur obtenue.

Chaque insertion met à jour tous les index et contraintes de la table cible, et ce coût augmente avec sa taille. Des statistiques de base de données obsolètes aggravent la situation. Le thread d'écriture devient alors le plus sollicité, ce qui constitue le signe classique d'un goulot d'étranglement au niveau de la cible.

Oui, car la transformation peut libérer chaque groupe dès sa fin au lieu de tout mettre en cache. Les lignes entrantes doivent déjà être triées selon les ports de regroupement ; dans le cas contraire, la session échoue.

Pour une charge importante uniquement en inserts, laissez tomberping Il est généralement plus rapide de créer d'abord les index et les contraintes, puis de les reconstruire ensuite. Les commandes SQL de pré-session et de post-session dans les propriétés de session constituent l'endroit idéal pour scripter ces deux étapes.

Le mode « batch » contourne une grande partie de la journalisation de la base de données et accélère le chargement, mais il empêche la récupération et n'est pas compatible avec toutes les cibles ni avec toutes les stratégies de mise à jour. Le mode normal écrit via le chemin de journalisation habituel et reste récupérable.

Les modèles entraînés sur les durées d'exécution historiques détectent les sessions dont la durée s'est écartée de la normale bien avant que quiconque ne s'en aperçoive, ainsi que les défaillances liées aux clusters. Ils pointent vers l'exécution concernée ; la couche responsable doit encore être identifiée à partir des statistiques des threads.

Il peut réécrire une requête, suggérer des index candidats et expliquer un plan d'exécution collé dans l'éditeur. Il n'a pas accès au référentiel ni au journal de session ; par conséquent, toute réécriture doit être validée par rapport au plan réel et au nombre de lignes.

Résumez cet article avec :