• Arnaud Mauduit

L'Optimisation des performances de SAP BUsiness Objects Data Services


SAP Data Services propose une solution d’entreprise unique pour l’intégration, le profilage et le traitement des données de texte qui vous permet d’intégrer, de transformer, d’améliorer et de fournir des données sécurisées aux processus de gestion critiques. La solution propose une interface utilisateur de développement, un référentiel des métadonnées, une couche de connectivité de données, un environnement d’exécution et une console de gestion, permettant aux entreprises de réduire leur coût total en matière de propriété et d’accélérer la valeur temps.


Les performances ETL reposent sur l’efficacité qui permette aux moteurs ETL et aux bases de données de traiter rapidement en effectuant moins d’opérations coûteuses. La conception d’un flux de données très efficace n’est pas anodine et nécessite une connaissance et une compréhension importantes du moteur SAP Data Services ainsi que de la manière dont il interagit avec le moteur de base de données. Lors du traitement de millions d’enregistrements, l’opération la plus coûteuse peut être l’acte de déplacer toutes ces données du serveur de base de données vers le serveur ETL et inversement.


Il n’est pas aisé de se lancer dans un chantier d’optimisation, car le contexte n’est généralement pas simple. Pour ceux qui ont eu l’occasion d’aborder ce genre d’audit ils vous diront que c’est différent d’un client à l’autre. Malheureusement, on en arrive toujours à mettre des chantiers d’optimisations en place lorsqu’apparaissent des traitements d’alimentation de plus en plus longs.


Après l’audit, on s’aperçoit souvent qu’une majorité des problèmes aurait pu être évitée, si l’on avait suivi quelques conseils, qui s’apparentent plus à de la logique qu’à de l’expertise. L’objectif de cet article est de décrire les méthodes utilisées pour optimiser les flux au niveau technique et les outils efficaces qui permettront d’exploiter au mieux les ressources de Data Services.


I. Gestion du cache


Vous pouvez améliorer les performances des transformations de données qui se produisent en mémoire en mettant en cache autant de données que possible. En mettant en cache les données, vous limitez le nombre de fois où le système doit accéder à la base de données.


Data Services offre l’option de cacher les données dans la mémoire pour améliorer les opérations dans les flux de données telles que :


1 Mise en cache des sources


Par défaut, l’option « Cache » est définie sur « Oui » dans une table source ou un éditeur de fichier pour spécifier que les données de la source sont mises en cache à l’aide de mémoire sur l’ordinateur Job Server. Lorsque les sources sont jointes à l’aide de la transformation de requête (Query transform), le paramètre de cache dans la transformation de requête a la priorité sur le paramètre de la source.


2 La mise en cache des jointures


Dans l’éditeur de requête, le paramètre de cache est défini sur Automatique par défaut. L’automatique paramètre reporte le paramètre de la table source.


Dans l’éditeur de requête, mettez en cache une source uniquement si elle est utilisée comme source interne dans une jointure.


Une source est utilisée comme source interne dans une jointure dans les conditions suivantes :

  • La source est spécifiée comme la source interne d’une jointure externe gauche.

  • Dans une jointure interne entre deux tables, la source a un rang de jointure inférieur.

La mise en cache n’affecte pas l’ordre dans lequel les tables sont jointes. Si les conditions d’optimisation sont telles que le logiciel pousse les opérations vers la base de données sous-jacente, il ignore votre paramètre de cache.

Si une table devient trop grande pour tenir dans le cache, assurez-vous que le type de cache est paginable (pageable cache).


3 Lookups


Mettez en cache les données lorsque vous recherchez des valeurs individuelles à partir de tables et de fichiers. Vous pouvez améliorer les performances en mettant en cache les données lorsque vous recherchez des valeurs individuelles à partir de tables et de fichiers. Utiliser une fonction de recherche dans une requête ou utilisation d’un ensemble de tables source comme jointure externe. SAP Data Services possède trois fonctions de recherche : « lookup », « lookup_seq » et « lookup_ext ». lookup et lookup_ext ont des options de cache. La mise en cache des sources de recherche améliore les performances car DS évite la tâche coûteuse de créer une requête de base de données ou une analyse complète des fichiers sur chaque ligne.


On a le choix entre PRE_LOAD_CACHE, DEMAND_LOAD_CACHE et NO_CACHE. Selon le nombre de ligne de la table de lookup, par rapport au nombre de lignes en entrées, il peut ne pas être nécessaire de mettre la table de lookup en cache.


4 Table Comparison


Vous pouvez améliorer les performances de la transformation Table Comparison « Table Comparison transform » en mettant en cache la table de comparaison. Il y a trois modes de comparaison :

  • Sélection ligne par ligne (Row-by-row)

  • Tableau de comparaison mis en cache (cached comparison table)

  • Entrée triée (sorted input)

Si le nombre de lignes en entrée est faible, et que la table cible est volumineuse, il peut être plus optimal de choisir un mode sélection ligne par ligne « Row-by-row ». Lorsque le volume en entrée est très important, et que le volume de la table cible l’est aussi, il est peut-être plus optimal de trier les lignes en entrée, et d’utiliser l’algorithme Entrée triée « sorted input » pour le chargement de la table cible.


II. Options de performances basées sur la source


Vous pouvez ajuster trois domaines pour les sources de données lorsque vous configurez des « jobs » :

  • L’ordre des jointures (Join order)

  • Données extraites (Extracted data)

  • Taille de récupération du tableau (Array fetch size)

1 Join Rank


Utilisez le rang de jointure pour contrôler l’ordre dans lequel les sources sont jointes. Le rang de jointure indique le rang d’une source par rapport aux autres tables et fichiers joints dans un flux de données. Prenant en considération rang de jointure, l’Optimiseur de services de données joint les sources avec un rang de jointure plus élevé avant de rejoindre les sources avec un rang inférieur. Le rang de jointure doit être un entier non négatif. La valeur par défaut est 0. Bien qu’il soit possible de définir le rang des jointures dans l’onglet FROM de l’éditeur de requête ou dans un éditeur source, la meilleure pratique consiste à spécifiez le rang de jointure directement dans l’éditeur de requête.


2 Minimiser les données extraites


La meilleure façon de minimiser la quantité de données extraites des systèmes source est de récupérer uniquement les données qui ont changé depuis la dernière fois que vous avez effectué l’extraction. Cette technique est appelée capture de données modifiées (changed-data capture).


3 Utilisation de la taille de récupération du tableau


SAP Data Services fournit un moyen simple de demander et d’obtenir plusieurs lignes de données à partir de bases de données source. La fonction de taille de récupération de tableau vous permet de récupérer des données en utilisant moins de demandes, réduisant ainsi considérablement le trafic sur votre réseau. Le réglage de la taille d’extraction du tableau peut également réduire la quantité d’utilisation du processeur sur l’ordinateur Job Server.


La fonction de récupération de tableau réduit le nombre de demandes de base de données en « récupérant » plusieurs lignes (un tableau) de données à chaque demande. Entrez le nombre de lignes à récupérer par demande dans l’option de taille de récupération de tableau sur n’importe quelle table source éditeur ou éditeur SQL transform. Le paramètre par défaut est 1000, ce qui signifie qu’à chaque demande de base de données, le logiciel récupérera automatiquement 1000 lignes de données de votre base de données source. La taille maximale de récupération du tableau que vous pouvez spécifier est de 5000 octets.


III. Options de performances basées sur les cibles


1 Méthode de chargement


Vous pouvez choisir d’utiliser un chargement régulier ou un chargement en masse (bulk loading). Pour une charge régulière, l’option SQL paramétré est automatiquement sélectionnée lors de la génération, de l’analyse et de la compilation de l’instruction. En utilisant SQL paramétré, le logiciel peut minimiser ses efforts en utilisant « one handle » pour un ensemble de valeurs au lieu de « one handle » par valeur. De nombreuses bases de données ne prennent pas en charge le chargement en masse avec les options suivantes :

  • Charge à correction automatique (Auto-correct load)

  • Activer le partitionnement (Enable Partitioning)

  • Nombre de chargeurs (Number of Loaders)

  • Poussée complète vers une base de données (Full push down to a database)


Le logiciel sélectionne automatiquement ce processus d’optimisation lorsque les conditions suivantes sont remplies :

  • La source et la cible dans un flux de données se trouvent sur la même base de données.

  • La base de données prend en charge les opérations dans le flux de données.

Si l’optimiseur pousse vers le bas les opérations sources ou cibles, il ignore les options de performances définies pour sources (taille de récupération de tableau, mise en cache et classement de jointure) car il ne traite pas uniquement le flux de données.


Pour améliorer les performances pour une charge régulière (SQL paramétré), vous pouvez sélectionner les options suivantes dans l’éditeur de table cible. Notez que si vous en utilisez un, vous ne pouvez pas utiliser les autres pour la même cible.


Activer le partitionnement


Option de chargement parallèle. Le nombre de charges parallèles est déterminé par le nombre de partitions dans la cible table.


Nombre de chargeurs


Option de chargement parallèle. Le nombre de charges parallèles est déterminé par le nombre que vous entrez pour cette option.


2. Lignes par commit


Les lignes par commit pour un chargement normal par défaut sont de 1000 lignes. La définition des lignes par commit affecte la performance de Job. Ajustez la valeur des lignes par commit de validation dans l’Options tab de l’éditeur de table cible, en notant la règle suivante :

  • N’utilisez pas de signes numériques négatifs et d’autres caractères non numériques.

  • Si vous n’entrez rien ou 0, la zone de texte affichera automatiquement 1000.

  • Si vous entrez un nombre supérieur à 5000, la zone de texte affiche automatiquement 5000.

Il est recommandé de définir des lignes par commit entre 500 et 2000 pour de meilleures performances.


IV. Maximiser les opérations Push-Down : (Poussée des opérations vers le bas et vers le serveur de base de données)


Pour les sources et les cibles SQL, SAP Data Services crée des instructions SQL spécifiques à la base de données basées sur les données diagrammes de flux dans un travail (job). Le logiciel génère des instructions SQL SELECT pour récupérer les données de la source bases de données. Pour optimiser les performances, le logiciel pousse autant d’opérations SELECT que possible vers la base de données source et combine autant d’opérations que possible en une seule demande à la base de données. Il peut pousser les opérations SELECT telles que les jointures, Grouper par (Group By) et les fonctions communes telles que les fonctions de décodage (decode) et de chaîne.


1 Push-down opérations


En déplaçant les opérations vers la base de données source, Data Services réduit le nombre de lignes et d’opérations que le moteur doit récupérer et traiter, ce qui améliore les performances. Lors de la détermination des opérations à pousser vers la base de données, Data Services examine la base de données et son environnement. Le logiciel effectue deux types d’opérations déroulantes : complète et partielle.


2 Complète (Full) push-down opérations


L’optimiseur essaie toujours d’abord d’effectuer une opération de push-down complète. Une opération de poussée complète est lorsque toutes les opérations de transforms peuvent être transférées vers les bases de données et les flux de données directement de la base de données source vers la base de données cible. SAP Data Services envoie des instructions SQL INSERT INTO … SELECT à la base de données cible où SELECT récupère les données de la source.


Le logiciel effectue une opération push-down complète vers les bases de données source et cible lorsque les conditions suivantes sont remplies :

  • Toutes les opérations entre la table source et la table cible peuvent être poussées vers le bas.

  • Les tables source et cible proviennent du même magasin de données, elles se trouvent dans des magasins de données qui ont un lien de base de données définis entre eux, ou si le magasin de données a lié des serveurs distants. Pour activer une liste push-down complète de la source vers la cible, vous pouvez également utiliser les fonctionnalités suivantes :

  • Data_Transfer transform

  • Liens de base de données (Database links)

  • Utiliser l’option Serveurs distants liés (Use Linked Remote Servers option)

3 Partielle (Partial) push-down operations


Lorsqu’une opération d’extraction complète n’est pas possible, SAP Data Services pousse toujours l’instruction SELECT vers la base de données source. Les opérations de l’instruction SELECT que le logiciel peut envoyer à la base de données sont les suivantes : Aggregations, Distinct rows, Filtering, Joins, Ordering, Projection, Functions.


3 Data_Transfer transform


Il est possible d’utiliser la transformation « Data_Transfer » pour pousser vers le bas des opérations consommatrices de ressources n’importe où dans un flux de données vers la base de données. Les opérations consommatrices de ressources incluent les jointures, GROUP BY, ORDER BY et DISTINCT.


Conclusion


On peut avoir mis en place une super architecture, des serveurs de folies, suivre les normes de développements et avoir optimisé la base de données, et être pénalisé par le débit du réseau. Aussi on peut avoir une bonne architecture, des serveurs bien taillés, des bases optimisées, mais ne pas avoir anticipé les nombreux projets qui démarrent tous en même temps.


Ce qui est passionnant dans ce genre de travail d’optimisation, c’est qu’on doit s’intéresser à une pléthore de paramètres illustrés par la diversité de la population concernée. On peut aller discuter avec un développeur SQL ou avec un DBA, en passant par l’architecte, le responsable réseau ou encore le DSI.


Les problématiques varient d’un client à l’autre, le plus important, est de ne pas se disperser. Il faut avant tout cartographier l’environnement et saucissonner l’architecture, puis identifier les goulots d’étranglements pour affiner au fur et à mesure.

49 vues

Posts récents

Voir tout