Accueil » DataStage

DataStage Stages Join, Lookup & Merge

Par Ethan TANG Le 25 juin 2009 – 10:19 | Lu 358 fois 3 Commentaires

Stage Join Lookup Merge

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

Tableau comparatif

 


1 Etoile2 Etoiles3 Etoiles4 Etoiles5 Etoiles (1 votes, moyenne: 5,00 sur 5)
Loading ... Loading ...

3 Commentaires »

  • Simon Leroy dit :

    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

  • Ethan dit :

    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.

  • Simon Leroy dit :

    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

Laissez un commentaire!

Ajouter votre commentaire ci-dessous, ou trackback à partir de votre site. You can also Abonnement au commentaires via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

Vous pouvez le code HTML suivant:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Ce blog est compatible avec Gravatar. Pour utiliser votre propre avatar, veuillez vous inscrire gratuitement sur Gravatar.