I.

Optimisation base de données & Talend

1-Reprise de données

En cas de reprise d’un historique de données utiliser le chargement et commit par lot en cas de grosse
volumétrie, tout en ayant une trace via une table de lot à traiter.

Par exemple si on a une reprise de 12 mois à faire sur une table on peut utiliser une table qui liste les
mois à traiter avec un flag qui est à 1 si traité et 0 sinon.

On boucle sur la table mois par mois et c’est les lignes de chaque mois qui constitue le lot avec un
commit à la fin de chaque lot.

Il y a un autre moyen de faire un traitement par lot sur talend en utilisant un paramétrage sur le
composant ‘output’ sur la partie ‘paramétrage avancé’ où il faut cocher ‘commit chaque’ et ‘utiliser la
taille de lot’. Ces deux options ne sont visibles que si l’utilisation de la connexion existante est
décochée.

Cette méthode n’est pas recommandée si la fin du programme prend des heures car en cas de plantage
on ne peut pas maîtriser où le chargement s’est arrêté et donc il faut recommencer depuis le début.

2-Utilisation du composant output

Sur le composant output de talend on peut définir les champs à mettre à jour, la clé de mise à jour et la
clé de suppression en utilisant l’option ‘utiliser l’option des champs’ sur la partie paramétrage avancé.
3-Optimisation d’une Recherche talend

Pour les recherches sur une table volumineuse,

 le plus optimal est de passer par une recherche sql, cela veut dire faire la recherche via une
jointure sur le sql placé sur le composant d’input.
 Si ce n’est pas possible, il faut passer par une option sur le tmap :

Il faut choisir mettre la valeur ‘Recharger à chaque ligne’ sur l’option ‘Lookup Model’ puis définir la
clé globalMap en indiquant la clé de jointure sur ‘EXP.’ Et la variable global à utiliser sur le sql de
recherche dans le champ à droite.

Ensuite sur le input de recherche on utilise la variable global (ici ID_TICKET_UTIL) comme le
montre la capture ci-dessous :

Il faut indexer la clé de recherche sur la table de recherche.

4-indexation  :

Il faut indexer les champs de recherche, soit une recherche sur le flux, soit une recherche pour la
restitution, soit ceux utilisés sur les jointures…

Il faut indexer les champs clé d’update ou clé de delete

5-Le composant TmsSqlRow

Pour passer une action d’insert, de delete ou d’update qui ne nécessite pas des transformations
préalable et qui concerne des champs limité, il vaut mieux de passer par le composant ‘tmsqlRow’ :

Ce composant envoie la requête directement sur le SGBD contrairement aux composants ‘TMAP
+tmsqloutput’ qui traite d’abord sur le moteur d’ETL puis envoie au SGBD.

6-Optimiser une extraction

Il faut toujours penser à faire une extraction côté sql au maximum sans passer par des jointures talend
via le tmap :
7-Optimiser l’utilisation de TMAP

Il ne faut pas dépasser deux inputs par TMAP c’est plus optimal.

8-Cas d’un lent chargement

Penser à utiliser les composants Bulkload en cas de volumétrie importante.

Essayer de ne pas utiliser le ‘OR’ sur une condition de sélection et remplacer par un between si
possible.

Dans le cas d’un chargement d’une table où il y a des index avec une grande volumétrie, il faut
désactiver les index avant lancement du chargement et les réactiver après chargement.

Pour désactiver, vous trouvez ci-dessous la démarche en prise d’écran :

Pour réactiver il faut suivre la démarche ci-dessous sur la prise d’écran :
II. Modélisation :
1-solution d’historisation

Afin de satisfaire un besoin d’historisation il y a plusieurs méthodes, on peut en distinguer deux :

La première consiste à mettre sur la table à historiser, en plus de la clé business, une clé de
substitution avec une date de début et une date de fin. La clé primaire de la table est la clé de
substitution. Cette méthode peut être réalisée via des composants ETL spécifique et qui commence
par ‘SCD’.

SK
Date_debut
Date_fin
ID_business
…

La deuxième méthode consiste à utiliser une table qui trace l’historique. La table principale contiendra
la clé de substitution qui constitue la clé primaire de la table. Un lien via cette clé de substitution est
fait avec une autre table qui contiendra la clé business, la clé de substitution, une date de début et une
date de fin.

SK
SK ID_business
… Date_debut
Date_fin

2-Modélisation de dimensions

Il est à noter qu’il y a des dimensions à créer sous forme de table si les modalités qui la représentent
dépassent deux et si elle est évolutive. Sinon il suffit de créer un champ sur la table de fait
directement. Exemple : le champ statut d’une ligne téléphonique prend deux modalités ‘Active’ ou
‘Suspendue’.
3-Infocentre

On est confronter à satisfaire des besoins utilisateurs difficiles à mettre en œuvre, parmi ces besoins
on trouve le souhait d’un utilisateur de créer des rapports pour des périodes indéterminées, cela veut
dire que l’utilisateur souhaite une visibilité de la situation d’une semaine, d’un mois, de deux mois, de
2 semaines ou autre.

Afin de répondre à cela, nous avons opté pour la création d’un infocentre. C’est un entrepôt de
données qui dresse le détail des transactions avec le niveau de granularité le plus bas, dans notre cas
c’est le jour. Ensuite, coté rapport il faut appliquer les conditions de sélection en addhoc selon la
période définie.

4-Datamart en Hybride

Lors du projet GMF nous étions amenés à concevoir des DTM en hybride pour satisfaire un besoin
reporting qui consiste à produire des TDB où on trouve sur un même TDB des informations liés à
plusieurs objets transaction. Vous trouverez ci-dessous un exemple de cette conception :