Aggregator Transformation

L'Aggregator Transformation est l'un des composants les plus importants des traitements ETL PowerCenter. Une "mauvaise" utilisation de ce composant peut être fatale pour les performances en cas de grosse volumétrie.

L'Aggregator Transformation est une transformation active (le nombre de lignes en entrée et en sortie n'est jamais le même) et connectée qui permet d'effectuer des calculs tels que les moyennes et les sommes.

L'Aggregator Transformation est différent de l'Expression Transformation par le fait qu'il permet d'effectuer des calculs sur des groupes, tandis que l'Expression Transformation permet d'effectuer des calculs ligne par ligne seulement.
 

Principaux composants de l'Aggregator Transformation:

• L'expression de calcul

On utilise le langage de transformation et les fonctions de calcul (AVG, COUNT, MAX, MIN, SUM...etc) pour écrire l'expression. On peut utiliser les clauses conditionnelles pour filtrer les lignes (ex: SUM( Salaire, Salaire > 1000)), offrant plus de souplesse que le langage SQL.

• Les ports du "Group by"

L'Aggregator permet de définir des groupes pour les agrégats, plutôt que d'effectuer l'agrégation sur l'ensemble des lignes en entrée.

Dans l'exemple, on calcul la somme des unités par employé. 

• Sorted Input  

Cette option est très importante. Elle est utilisée pour améliorer les performances de la session en cas de grosse volumétrie.

Pour utiliser "Sorted Input", nous devons transmettre à l'Aggregator des données triées sur les champs du "group by", par ordre croissant ou décroissant.
Si l'option est cochée et que les données ne sont pas triées, la session tombe en failed.
L'option "Sorted Input" ne peut pas être utilisée dans les cas suivants : 
- La session est en "Treat Source Rows as = Data Driven"

- La session utilise l'Agrégation Incrémentale

- L'expression de calcul dans l'Aggregator contient des fonctions d'agrégation imbriquées

• Le Cache

L'Integration Service lit les données en provenance de la source, les stocke dans le Data Cache et l'Index Cache, effectue les calculs et puis envoie les données à la transformation suivante.
Ces fichiers sont supprimés à la fin du traitement s'il ne tombe pas en failed. 
L'Index Cache contient les colonnes du "Group by", tandis que le Data Cache contient les autres colonnes non "Group by" (y compris les colonnes de type variable).

Tips & Performance

Pour optimiser l'Aggregator transformation en cas de forte volumétrie, il faut utiliser l'option "Sorted Input" car dans ce cas, l'Integration Service utilise la mémoire pour effectuer le calcul (In-Memory ça vous dit quelques choses ?). Il n'utilise pas de cache.

Si le flux en entrée n'est pas trié, on peut le trier par l'une des deux méthodes suivantes :
- Soit utiliser le Sorter Transformation avant l'Aggregator si une des sources est un fichier plat ou si l'Aggregator est utilisé loin de la source avec un tri non adéquat
- Soit utiliser le tri généré par le Source Qualifier (SQ) si les sources sont des tables relationnelles: en renseignant "Number Of Sorted Ports" dans le SQ non surchargé, ou "Order By" en dur dans la requête du SQ surchargé.

Illustration du gain avec un exemple
Considérons le mapping simple suivant:

Source : fichier texte contenant 10 millions de lignes
Cible : fichier texte
Aggregator : calcul le nombre d'unités détenues par chacun des employés.
Nous utilisons le même mapping avec deux configurations, une sans l'option "Sorted Input" et l'autre avec. 

• Sans l'option "Sorted Input" => le traitement a duré 8 minutes

Les fichiers Cache sont générés en cours de traitement et sont supprimés une fois le workflow terminé:

• Avec l'option "Sorted Input" => le traitement a duré 33 secondes

aucun fichier cache n'est généré.

La différence est énorme ! non ?