G-FRIDO JUGO4715

1

Tutoriel DataStage PX/EE Lien internet : http://www.exl-infosfr.com/tutoriels/tutoriel-datastage-pxee/

Introduction

Choses promises choses dues. Voici donc un tutoriel entièrement dédié à DataStage PX et en

Français s’il vous plait !

Ce tutoriel est construit dans la perspective où vous connaissez déjà DataStage server … si ce n’est pas le cas je vous suggère de commencer par le tutoriel DataStage Server.

Note pour les développeurs DataStage Server

Développer avec DataStage PX n’a rien à voir avec le développement sous DataStage Server … et ce malgré les

troublantes ressemblances des deux moteurs ! en fait j’ai envie de dire que mis à part les environnements (clients lourds) de

développement et bien les similitudes s’arrêtent là. Ok le designer est le même, la façon de développer est la même (approche Top-Down, etc.), on retrouve le Director, l’Administrator la console

d’administration … mais voilà ça s’arrête là … ou presque !

Croire qu’un développeur Server deviendra un bon développeur PX suite à une simple formation reste une hérésie car

même si les moteurs Server et PX sont bien cachés derrière les applications clientes identiques, ils n’en restent pas moins

fondamentalement différents.

Aborder DataStage PX nécessite donc:

l’appréhension de nouvelles notions vitales comme le parallélisme, le partitionnement,

la prise en compte prépondérante des ressources machine (nombre de serveur, processeur, RAM, I/O, etc.)

La découverte d’un autre moteur écrit en C/C++ (si vous faites vous même

l’installation vous décrouvrirez alors qu’il vous faut un compilateur C/C++) La découverte d’une palette de nombreux stages supplémentaires, l’abandon d’autres

stages (server) et puis surtout la différence de comportement de certains stages entre Server et PX : je veux bien sur parler du Transformer !

et donc par corollaire, une façon de développer différente, vous verrez le nombre de

stages dans le canevas va augmenter considérablement par rapport à DataStage Server

G-FRIDO JUGO4715

2

Bref, si vous êtes un développeur DataStage Server ? et bien vous allez devoir apprendre à

développer avec un autre ETL : DataStage PX … et vous allez vite vous rendre compte que c’est bien différent !

Néanmoins et malgré ces différences il est possible d’utiliser des objets communs aux deux :

par exemple on pourra utiliser des job sequence pour lancer des jobs server et/ou parallel. Maintenant le lien entre les deux serveurs s’arrête ici, ne comptez pas par exemple réutilis er

des fichiers Hash dans vos jobs Parallel/PX ou vos Datasets dans vos jobs server car malheureusement au sein des jobs Server ou PX … la frontière est étanche !

Table des matières

Le parallélisme La palette des jobs Parallel Aïe pas de debug ! comment faire ?

Un premier job facile Un second job plus complexe

G-FRIDO JUGO4715

3

Le parallélisme avec DataStage PX

Outre le fonctionnement en mode pipelining (traitement d’un flux d’intégration de données au fil de l’eau) DataStage PX est extrêmement

performant grâce à sa gestion du partitionnement des données (au travers du

framework Orchestrate).

Pourquoi partitionner, et puis d’abord qu’entend-on par partitionnement ?

Et bien l’idée du partitionnement est toute simple : décomposer les données pour les traiter en

parallèle et en simultané par plusieurs unités de traitements. Concrètement, si on prend l’exemple

d’un dictionnaire et de 4 unités de traitements (Cf. image à gauche) … l’idée va être de créer 4 jeux de données à partir du jeu complet et de déléguer à

quatre unités de traitements qui pourront être des serveurs distincts ou des processeurs les

transformations.

Ainsi les Quatre sous traitements pourront être effectués en parallèle, améliorant ainsi considérablement les performances et optimisant

l’utilisation des ressources machine.

Une idée séduisante … mais si la théorie parait simpliste : la réalité est tout autre. Car décomposer les données c’est bien mais cela nous amène à nous poser d’autres questions comme :

Comment vais-je décomposer mes données ?

Ma décomposition conviendra-t-elle pour tout mon flux ? si non comment vais-je dé-partitionner et repartitionner ?

Aurais-je besoin de toutes mes données dans un sous-traitement de mon flux ? etc.

Bref, Dire que DataStage va gérer automatiquement vos partitionnements serait une erreur de débutant … certes vous constaterez qu’il existe un mode de partitionnement Auto : mais cela

ne signifie pas qu’il faut faire confiance à ce qui va se passer derrière … ou attention aux surprises. Le partitionnement n’est pas un élément qu’il faut prendre à la légère … cela se

pense lors de la conception du flux sans quoi vous pourriez avoir de grosses surprises en terme de performances ou pire en terme d’exactitude de vos traitements. Une erreur de débutant consiste en effet à développer avec un seul nœud …

G-FRIDO JUGO4715

4

Partitionnement et repartitionnement à

la volée

Partitionner c’est bien mais cela peut ne pas convenir pour tout notre flux d’intégration. En effet imaginons que pour effectuer l’intégration de données clients nous ayons besoin de faire

des calculs basés sur le nom de famille en premier lieu, puis que des agrégats sur le code postal seront nécessaire, pour enfin calculer un encours de carte de crédit …

Les calculs réalisés sont basés sur des regroupements logique de données, or si nous avons

partitionné en amont cela signifie que nous avons regroupé : faire un regroupement par code postal sur un jeu de données qui lui même est réduit aux noms de famille n’a donc aucun sens et mon résultat sera faux ! Voici donc une problématique classique du partitionnement …

Heureusement DataStage y répond automatiquement grâce au repartitionnement à la volée :

Dans le schéma ci-dessus on voit bien comment entre chaque sous-traitement DataStage PX va casser le partitionnement effectué et repartitionner avec la nouvelle clé de partitionnement les données. Attention néanmoins à ne pas abuser de cette fonctionnalité et

ainsi de grouper logiquement vos sous-traitement pour éviter les opérations de tris sous-jacente et donc coûteuses en performance.

Les fichiers de configuration

DataStage PX (ou EE) utilise un fichier de configuration afin de gérer les traitements parallèles et ainsi de répartir sur différentes partitions logiques et physiques ses traite ments. Ce dernier est totalement indépendant des développements et est utilisé directement par le

moteur afin de traiter les phases de partitionnement, collecte et repartitionnement sur plusieurs nœuds.

Ce fichier peut être changé/utilisé au niveau du projet DataStage global ou changé lors du

traitement d’un job en particulier via la variable d’environnement $APT_CONFIG_FILE.

G-FRIDO JUGO4715

5

Ce fichier décrit la configuration utilisée sur le serveur pour le traitement des processus

générés par les jobs.

Exemple:

{

node « node1» {

fastname « rdtsuat »

pools « »

resource disk « /DataStage/data/PXTEMPDATA1/DNT2/DS » {pools « »}

resource scratchdisk « /DataStage/data/PXTEMPDATA2/DNT2/SCRATCH » {pools « »}

}

}

node « node2»{

fastname « rdtsuat »

pools « »

resource disk « /DataStage/data/PXTEMPDATA2/DNT2/DS » {pools « »}

resource scratchdisk « /DataStage/data/PXTEMPDATA1/DNT2/SCRATCH » {pools « »}

}

}

Dans cet exemple, les processus seront parallélisés sur 2 nœuds («node1», et «node2»).

Chaque nœud dispose d’un répertoire disque pour le stockage :

des DataSets (resource disk)

Et pour le swapping (resource scratchdisk).

Ces paramètres sont très importants, surtout en phase de tuning !

Le nom de chaque machine est spécifié après la mention : fastname

Il est aussi possible d’utiliser des pools (noeud/resource). Un pool se définit par un groupe de nœud (ou de ressource), cette notion pouvant être réutilisée lors du design des jobs DataStage (il est alors possible que l’exécution de tel traitement se fera au travers d’un pool particulier

par exemple) : cela permet par exemple le cloisonnement de certains traitements particuliers.

G-FRIDO JUGO4715

6

Quelques Trucs

Tout d’abord on peut se poser la question du nombre de nœuds à spécifier dans le fichier APT_CONFIG_FILE. Ce nombre dépend de pas mal de paramètres dont certains ne peuvent êtres définis comme une règles générique (par exemple selon le type de traitement

effectué dans le job lui même, l’utilisation des ressources, etc.). On peut néanmoins partir avec 1 nœud par demi-CPU disponible. Ce nombre sera ensuite ajusté selon les besoins.

Si possible, évitez d’utilisez les disques dans lesquels vous stockez les sources de données !

N’utilisez pas (ou du moins évitez) des ressources NFS pour les ressources scratchdisk.

Attention si vous utilisez une SAN :

Vous devez alors absolument comprendre la configuration de la baie (pour éviter tout

conflit matériel) Si possible placez le scratchdisk sur un disque local (ou plusieurs)

Ne faites pas confiance aux utilitaires de monitoring

Pour Ce Tutoriel

Gardez le fichier APT_CONFIG_FILE par défaut … bref ne touchez à rien

La palette des jobs Parallel (PX)

Pour les développeurs DataStage Server

Si vous étiez développeur DataStage Server, vous constaterez assez vite la différence entre la palette des jobs server et celle des jobs Parallel (job PX). Partez donc directement du principe que les stages PX sont totalement différents de ceux de serveur ça sera plus simple :

croire par exemple que le transformer va être la même boite à outil que dans server est une erreur, vous allez d’ailleurs vite vous en rendre vite compte.

En fait avec DataStage PX chaque typologie de transformation possède son stage (ou ses stages) associé … fini donc de tout mettre dans un gros transformer avec plein de code Basic

pour traiter une logique de transformation ! Avec DataStage PX vous allez devoir décomposer votre logique de flux via beaucoup plus de stages : Ca sera plus lisible du coup mais la

contrepartie est que les jobs vont grossir et se complexifier ! on ne peut pas tout avoir…

La manière de développer reste cependant la même, on prend des stages que l’on pose dans le canevas et la logique de flux suit les flèches … attention il y aura bien sur quelques

subtilités à ne pas négliger comme les partitionnements/repartitionnements (vous verrez d’ailleurs à ce propos de nouveaux logos sur les liens même) … mais la logique reste la même ! d’ailleurs la similitude s’arrête là !

G-FRIDO JUGO4715

7

Pour les autres

La logique de développement avec DataStage est décrite dans le tutoriel DataStage Server. http://www.exl- infosfr.com/tutoriels/tutoriel-datastage-server/

Présentation des stages Parallel (PX)

C’est à partir de là que la différence avec DataStage Server se fait sentir … en effet la palette de stages est très différente voire complètement. Et comme je le disais juste avant méfiez-vous des apparences car elles sont trompeuses. Je vais vous présenter au travers de cette page

les principaux stages parallel.

Les stages de transformation dits « Processing »

Ce sont les stages dédiés aux transformations de données proprement dit :

Aggregator : ce stage permet (comme son nom l’indique) d’effectuer des opérations de

regroupement et agrégats (somme, max, min, moyenne, etc.) sur un jeu

de données. Change Capture & Change Apply :

stages utilisés pour effectuer de la

détection de changement sur un jeu de données

Copy: Stage très utile qui permet de dupliquer en n flux un flux entrant (avec possibilité d’y enlever des

colonnes) Filter : Stage effectuant un filtre sur

un flux Funnel : Stage permettant de

fusionner des plux de même structure

(comme le ferait un UNION) Join & Merge : Jointures entre des

flux Lookup : opération de Lookup Remove Duplicates: retire les

doublons d’un flux Transformer : permet d’effectuer

des transformations sur un flux de données (jointures interdites)

Modify : Permet la manipulation des

métadonnées du flux entrant Sort : tri

Etc.

G-FRIDO JUGO4715

8

Les stages de deboggage dits « Debug »

Ces stages servent à débogger et/ou manipuler des jeu de tests :

Column Export: permet de

fusionner des colonnes Column Import : permet d’éclater

une colonne en plusieurs Etc.

Les stages de fichier dits « File »

Ces stages servent à manipuler les fichiers :

Column Generator: permet

d’ajouter des colonnes dans un flux

Row Generator: permet de générer un jeu de ligne

Peek : pose une trace dans un

flux qui pourra être visualisée dans le Director

Etc.

Les stages de restructuration dits « Restructure »

Ces stages servent à restructurer les flux de données :

Complex Flat File : permet de

manipuler des fichiers à structure complexe (comme des CopyBook COBOL par exemple)

DataSet: Fichier intrinsèque à DataStage PX (sorte d’équivalent

du fichier Hash dans Server). Ce fichier conserve le partitionnement !

Sequential File : Connecteur Fichier plat

Etc.

G-FRIDO JUGO4715

9

Aïe pas de debug ! Comment faire ?

Autant DataStage Server était fournit avec un Debugger intégré … Autant DataStage PX ne l’est pas ! c’est donc sans qu’il va falloir développer

ses jobs. Heureusement la palette de stages nous fournit quelques outils qui nous serons utiles dans notre tâche.

Utilisation du Peek

Le Peek c’est un peu le mouchard de DataStage PX, grâce à lui vous saurez à postériori quel était l’état des données à un endroit précis de votre job.

Celà a un inconvénient majeur : pour debugger votre job vous allez devoir

modifier le design (afin d’y ajouter le Peek). C’est ici que lestage Copy prend son importance dans la conception du job car grâce à ce dernier vous pourrez

dupliquer des flux (vers des Peek) sans influer sur la logique générale de votre job.

Voici un exemple concret :

Ce job ne fonctionne pas comme je le voudrais, afin de mieux comprendre j’aurais besoin de connaitre l’état de mon flux entre lestage Modify_3 et le stage Remove_Duplicates_4 … Comment faire ?

En bien commencons par ajouter 2 stages dans le flux :

Un Copy Stage Un Peek

G-FRIDO JUGO4715

10

NB: Dans le copy Stage effectuons un mapping complet sur les deux sorties

(Peek_11 et Remove_Duplicates_4)

Voilà, une fois lancé le job tracera les données du flux dans le Peek, résultat qu’il sera possible de consulter dans le Director. Attention de ne pas charger trop

de données sans quoi les traces seraient trop importantes, travaillez sur des échantillons représentatifs.

Une fois mon flux validé, il faudra retirer le Peek … Le Copy Stage étant un

stage qui ne consomme quasiment rien il n’est pas nécessaire de le supprimer à part pour des raisons de lisibilités bien sur. On aura donc le job final suivant :

G-FRIDO JUGO4715

11

Utilisation du Row Generator

Le row Generator est un stage très utile car il permet de générer très simplement des jeux de données simples (algorithme cycliques, hasard, etc.). N’hésitez donc

pas à utiliser ce stage et en abuser …

La méthodologie

Pour faire simple, soyons clair les outils de debug sont limités (IBM promet de

founir un debugger dans ses prochaines versions … j’ai espéré pour le 8.5 mais non, on verra plus tard) … en attendant soyez méthodique dans votre façon de développer vos jobs et par exemple évitez de placer toute votre logique – cad

tous les stages – dans le canevas pour ensuite tester votre job. A la place je vous recommanderai de construire et tester votre job de manière progressive et

itérative : un premier morceau … on le teste, on le corrige, on y rajouter le second morceau, etc.

Un premier job facile

Nous y voilà, notre premier job … pour ce premier exercice je vous propose de développer le

même job que dans le TutorielDataStage Server. Cela nous permettra de commencer à voir

les différences entre ces deux serveurs. Rappelons nous l’idée est de lire un fichier séquentiel (plat) et d’y mettre le contenu dans un fichier Hash ! Aïe … ça n’existe pas dans PX/EE … à

la place nous utiliserons un DataSet bien sur. N’oublions pas non plus la petite transformation qui doit être faite lors de ce transfert de données, à savoir la concaténation du nom & prénom.

Les métadonnées

Tout d’abord récupérez le fichier de données (c’est le même que celui du tutoriel DataStage Server pour ceux qui l’ont déjà) :

ID|NOM|PRENOM|SALAIRE|SERVICE

1|KALA|BENOIT|90400|MARK

2|LEBRANCHU|PAUL|75900|FIN

3|TORGIL|JEAN|45000|FIN

4|TUDOR|JEAN-PHILIPPE|67000|MARK

5|GEORGE|MIKAEL|89000|FIN

6|GUIDON|JEROME|30900|ACHAT

7|DECONIC|PHILIPPE|48900|FIN

Ensuite il faut importer les métadonnées de ce fichier. Cette opération est la même ce celle effectuée dans le tutoriel DataStageServer. Dans le repository, faites un clic droit, puis sélectionnez « Import Table Definition », puis « Sequential File Definition ». Un assistant apparait alors pour importer vos métadonnées basées sur le fichier que vous allez sélectionner

:

G-FRIDO JUGO4715

12

Dans cet assistant sélectionnez tout d’abord le répertoire dans lequel se trouve votre fichier,

puis le fichier lui même. Une nouvelle fenêtre apparait alors (cf. ci-dessous) détaillant la structure du fichier telle que vu par l’assistant. Cochez la case « First line is column names »

puis changer la valeur de « Other Delimiter » avec le pipe : |

Design du job

Nous allons maintenant placer dans le canevas (la zone de développement à droite en bleu par défaut) les stages constituant notre logique de flux d’intégration soit :

Un Sequential File (palette File)

Un Transformer (palette Trasnformation) Un DataSet (Palette File) :

Les trois doivent être liés de la sorte :

G-FRIDO JUGO4715

13

Jusque là, certains (les développeurs DataStage Server tout particulièrement) vont me dire

qu’à peu de choses près … PX et server c’est là même chose … et bien continuons avec le paramétrage, vous allez voir que les différences vont commencer.

Paramétrage du Sequential File

Double-cliquez sur le stage Sequential_File_0. Vous avez alors un certain nombre d’options et d’onglets bien plus important que dans DataStage Server. Commençons par le second : Properties, nous allons y préciser où se trouve notre fichier (propriété File=), changez aussi la

propriété « First Line is coluimn Name » à true :

Dans l’onglet Format, nous allons préciser comment est structuré notre fichier. A savoir notre

délimiteur de colonne (pipe), de fin de fichier, de ligne, etc. Changeons ici aussi la propriété Quote à none pour préciser que nos colonnes ne sont pas encadrées par un délimiteur.

G-FRIDO JUGO4715

14

Importons maintenant nos métadonnées fraichement importées (grâce au bouton Load…)

dans l’onglet Columns :

Voilà, c’est terminé pour le connecteur fichier plat, vous pouvez toujours vérifier votre paramétrage en utilisant le bouton View Data.

Paramétrage du Transformer

Le paramétrage du transformer est très simple, double-cliquez sur le stage Transformer_1 :

Voici les actions à réaliser pour obtenir l’écran (le mapping) ci dessus:

1. Supprimez la dérivation DSLink3.PRENOM

2. Double-cliquez sur la dérivation DSLink3.NOM pour entrer en mode modification et tapez DSLink3.NOM : » » : DSLink3.PRENOM

3. Validez

Notez ici que vous ne pourrez pas utiliser les routines server dans le transformer PX, à la

place et si le besoin s’en fait sentir vous devrez développer une routine parallel(PX) en C/C++ … mais c’est une autre histoire.

G-FRIDO JUGO4715

15

Paramétrage du DataSet

Il n’y à ici presque rien à faire sinon préciser où se trouve le dataset, pour cela double-cliquez sur le stage Dataset_3 et changez la valeur File comme ceci :

Lancement du job

Voilà notre premier job est terminé, compilez le et lancez le grâce aux deux boutons suivants :

Vous devrez alors obtenir le résultat suivant :

Allez, maintenant passons à un job un peu plus complexe …

Un second job plus complexe

Nous venons de voir comment créer un premier job très simple. Tout en ne tombant pas dans

l’extrême complexité nous allons maintenant réhausser la difficulté d’un cran. Voici l’objet de ce second job : à partir du même fichier notre job va devoir générer deux sorties :

1. Dans un fichier séquentiel : un listing contenant Nom, prénom et salaire sous le format suivant : NOM PRENOM (SALAIRE Euros)

G-FRIDO JUGO4715

16

2. Dans un dataset : le cumul par service des salaires. Attention il faut exlure le service

achat de cette liste !

Design du job

Ajouter tout d’abord un nouveau Job Parallel (comme nous l’avons fait précédemment).

Dans le canevas disposez les stages suivant comme ceci :

Note :

Le stage Filter est présent dans la palette Transformation Le stage Aggregator est présent dans la palette Transformation

Le stage Copy est présent dans la palette Transformation

Le rôle du Copy Stage est prépondérant ici car il sert à dupliquer le flux initial (provenant du sequential File) en deux, pour deux traitements différents : le reformattage dans un nouveau

fichier plat et l’aggrégat.

La partie supérieure (transformer & Sequential File) a donc pour rôle de concaténer les colonnes et de les reformatter. La granularité reste ici celle de l’employée.

La partie inférieure elle a un tout autre rôle :

Tout d’abord un filtrage du service ACHAT qui ne nous interresse pas (rôle du stage

Filter) Ensuite un regroupement par service et somme des salaires via le stage Aggregator L’écriture dans un DataSet

Paramétrage du Copy Stage

Une fois placé dans le canevas, il va falloir modifier deux choses dans le paramétrage du copy Stage :

Son mapping vers le flux supérieur :

G-FRIDO JUGO4715

17

Son mapping vers le flux inférieur

N’oubliez pas, pour les mapping, qu’ils se trouvent dans les transformer ou ailleurs, il suffit de faire des glisser-déplacer pour effectuer le lien

Paramétrage du Transformer

En ce qui concerne le transformer, c’est ici que nous allons reformatter le flux afin d’avoir un joli listing dans le fichier plat ultérieur. Il faut donc passer de 3 colonnes en une seule ! pour celà rien de plus simple. Créez une nouvelle colonne dans le lien de sortie (Insert New

Column) de type Varchar(255) et tapez la formule suivante :

Validez.

Paramétrage du Sequential File (ecriture)

Il faut maintenant précisez comment et où nous allons ecrire notre fichier. Double-cliquez sur le stage Sequential_File_26, après avoir précisé le nom du fichier dans lequel il fallait ecrire,

précisez les options suivantes de format :

G-FRIDO JUGO4715

18

A savoir : Pas de delimiteurs de colonnes & lignes.

Paramétrage du Filter

Passons maintenant à la partie inférieure de notre job. Il faut tout d’abord retirer les employés du service ACHAT, c’est là le rôle du stage Filter. Double-cliquez dessus :

Précisez la clause de filtrage (Where Clause) : SERVICE <> ‘ACHAT’ et validez.

Paramétrage de l’aggregator

Son rôle est tout d’abord d’effectuer un regroupement par SERVICE puis une somme des SALAIRE par SERVICE.

Double-cliquez sur le stage Aggregator.

Pour commencer il faut saisir (manuellement) les métadonnées de sortie (Output), onglet Columns :

G-FRIDO JUGO4715

19

Ensuite il faut préciser les regroupements et agrégats :

Résumé :

Pour la propriété Group, saisissez SERVICE Saisissez la colonne (en entrée/input) d’agrégat : SALAIRE, et la colonne calculée

(output) SALAIREAGG dans la sous-propriété Sum Output Column.

Changez ensuite le mapping (onglet output) comme suit :

N’oubliez pas de préciser pour le stage DataSet le nom de fichier.

Voilà les stages sont maintenant paramétrés, il nous reste à compiler et lancer notre job :

G-FRIDO JUGO4715

20

Le fichier (Sequential_File_26) doit avoir été créé sur le serveur :

KALA BENOIT (90400 Euros) TORGIL JEAN (45000 Euros)

GEORGE MIKAEL (89000 Euros) DECONIC PHILIPPE (48900 Euros)

LEBRANCHU PAUL (75900 Euros) TUDOR JEAN-PHILIPPE (67000 Euros) GUIDON JEROME (30900 Euros)

Voilà j’espère que ce tutoriel vus aura aidé à appréhender DataStage PX, je n’ai pas abordé les notions de partitionnementvolontairement afin de ne pas compliquer cette entrée en la matière … ça sera l’occasion d’un autre tutoriel :

Vous trouvez le fichier de ce tuto