DataStage Stages Join, Lookup & Merge
Par Ethan TANG Le 25 juin 2009 10:19 | Lu 358 fois 3 Commentaires

La version DataStage Entreprise Edition fournit 3 stages dit de jointures :
- Join
- Lookup
- Merge
Ces 3 stages combinent généralement 2 ou plusieurs liens sources sur des colonnes clés spécifiées par le développeur.
Les principales différences sont :
- la gestion des lignes primaires avec des valeurs clés sans correspondance avec les liens secondaires
- l’utilisation de la mémoire
- les contraintes sur les données sources quelles soient dédoublonnées ou triées
Tous les liens ne sont pas égaux dans DataStage
DataStage fait en effet une distinction entre le lien primaire et les liens secondaires parfois appelés "Liens de référence"
![]()
Tableau comparatif












Pour l’utilisation de la mémoire, je nuancerais un peu se qui est dit dans le support de cours DataStage PX.
Le lookup est dit Lourd en mémoire, cependant le mode « sparse » du lookup permet de limiter l’utilisation mémoire du stage dans le cas d’un flux « master » peu volumineux.
Les stages stages Joins et Merge sont dits léger en utilisation mémoire, cependant ils nécessitent un tri préalable des données qui lui est lourd en mémoire…
Cordialement,
Simon Leroy
Bonjour Simon,
Tout d’abord, merci pour ton commentaire. Je ne pensais pas que tu allais répondre si rapidement. :)
Je suis d’accord avec toi que tout dépend du volume des données.
Avec des données volumineuses, le Stage JOIN est recommandé par rapport au LOOKUP.
En effet, le stage LOOKUP doit d’abord charger toutes les données en mémoire, et une fois seulement pourra commencer le processus de « Matching » des entrées, ce qui a pour conséquence un ralentissement du traitement.
Par contre concernant le Stage JOIN, je ne pense pas que le tri soit si pénalisant que cela au « niveau utilisation mémoire » puisque le tri se fait à priori au niveau SGBDR.
Je n’ai que rarement pu utiliser le tri du SGBD avant un join : on a bien souvent un transformer qui modifie les clés de jointure, deux joins de suite avec des clés différentes ou une source de type fichier qui nécessitent un tri explicite des données … (soit à l’aide d’un stage sort pour d’avantage de lisibilité, soit en méthode de partitionnement sur le lien d’entrée).
De plus en fonction du SGBD, de la PK et des Index de la table, on aura dans ce cas une utilisation mémoire sur le serveur de base de données…
J’insiste bien souvent sur le fait qu’il faut prendre ce tableau avec précaution.
Cordialement,
Simon Leroy