switch dynamique de schema [Résolu]

[prince418]

Bonjour à tous,

Etant débutant sous Talend (tos), j'aurais besoin de vos lumières quant
au problème suivant:

Je reçois des fichiers au format CSV que je dois parser pour mettre à jour les tables d'un serveur pgsql.

le format a cette tête là:

Code :

1
2
3
4
5
 
table1;INSERT;champs1;champs2;champs3;champs4
table1;DELETE;champs1;champs2;champs3;champs4
table2;INSERT;champs1;champs2;champs3;champs4;champs5;champs6
table3;INSERT;champs1;champs2;champs3;

donc comme vous pouvez le remarquer, les 2 premiers champs indiquent la table ainsi que l'action à réaliser.
vous remarquerez aussi que ces champs sont suivis d'une multitude d'autre, correspondant au données des champs de la table cible et au nombre variable.

Je sais que le nombre max de champs est de 40 et cest ainsi que j'ai définis le schema du tFileInputDelimited avec 40 colonnes.

Mes questions seront les suivantes:

peut-on charger dynamiquement, dans un tPostgresqlOutput par ex, le schema de la table cible?

s'il faut développer du code utilisateur, auriez vous des idées?

la volumétrie des données à traiter étant assez conséquente comment vous y prendriez vous?
j'ai vu qu'il y avait un tPostgresqlOutputBulk j'imagine que c'est cet objet qu'il faudrait utilser ?

Merci d'avance.

[rdubois]

Dans Talend Integration Suite, il existe la fonctionnalité des schémas dynamiques. Elle permettrait de faire exactement ce que vous souhaitez.

Autrement, il vous faudra re-développer ce que Talend a fait pour arriver à vos fins.

Rémy.

[jnbarthas]

Bonjour,

pas de schéma dynamique avec TOS, seulement avec TIS.
Par contre, vous pouvez utiliser les tables systèmes pour préparer des requêtes dynamiques (custom code). C'est pertinent pour un grand nombre de table. Sinon mieux vaut utiliser les schémas statiques du référentiel et orienter les flux selon des critères d'identification des tables cibles.
Mode BULK adapté au traitement massif.

Pour plus d'info, vous pouvez regarder le livre publié ce mois aux editions ENI
http://www.editions-eni.fr/Livres/Ta...b421c950f.html

Envoyé par prince418

Bonjour à tous,

Etant débutant sous Talend (tos), j'aurais besoin de vos lumières quant
au problème suivant:

Je reçois des fichiers au format CSV que je dois parser pour mettre à jour les tables d'un serveur pgsql.

le format a cette tête là:

Code :

donc comme vous pouvez le remarquer, les 2 premiers champs indiquent la table ainsi que l'action à réaliser.
vous remarquerez aussi que ces champs sont suivis d'une multitude d'autre, correspondant au données des champs de la table cible et au nombre variable.

Je sais que le nombre max de champs est de 40 et cest ainsi que j'ai définis le schema du tFileInputDelimited avec 40 colonnes.

Mes questions seront les suivantes:

peut-on charger dynamiquement, dans un tPostgresqlOutput par ex, le schema de la table cible?

s'il faut développer du code utilisateur, auriez vous des idées?

la volumétrie des données à traiter étant assez conséquente comment vous y prendriez vous?
j'ai vu qu'il y avait un tPostgresqlOutputBulk j'imagine que c'est cet objet qu'il faudrait utilser ?

Merci d'avance.

[prince418]

Hum ok d'accord, merci pour vos réponses!

n'ayant que TOS, je suis coincé
Ah, j'ai vu que votre livre était dispo à la FNAC, j'irai y jeter un oeil et je pense qu'il va bien me servir


donc vous me dites qu'il est préférable de dupliquer le process pour chaque table? sachant que je dois en avoir qu'une vingtaine ça doit pouvoir se faire mais ça me parait quand même lourd.

Concernant tPostgresqlOutputBulk pourriez vous m'éclairer sur le sujet?

Si j'ai bien compris, ce mode permet de stocker les requete avant de les commit c'est ca?
J'ai vu qu'il était utilisé en complément de tPostgresqlOutputBulk_exec; j'imagine que c'est le trigger qui va récupérer les query dans le bulk pour les commit.

donc si je dois appliquer ceci à mon cas - ayant un vingtaine de tables et 2 types d'action à effectuer (insert et delete) - j'aurais au final 40 tPostgresqlOutputBulk et a chacun 1 tPostgresqlOutputBulk_exec associé soit 40 tPostgresqlOutputBulk _exec ?

[jnbarthas]

Le mode BULK ne répond qu'au besoin de performance pour un traitement massif.
Le mode ETL par défaut de Talend peut être suffisant pour tourner en mode batch la nuit sur des volumes importants.
Le mode BULK n'est pas idéal pour débuter avec TOS, autant utiliser les composants tPost..Input/Output pour se faire la main avec l'outil et surtout utiliser les schémas des tables définis dans le référentiel.

Bonne continuation

[prince418]

ah oui je vois d'accord.

Et donc, une derniere question: je peux me contenter des composant classiques même pour le traitement de millions d'entrée?

[jnbarthas]

pour une insertion simple dans une base
t...outputBulkExec travaille 5 à 10 fois plus vite que le composant de base ...Output pour 1 million de ligne (mais c'est le même schéma qui est utilisé).
Entre 40 s ou 3 minutes, à vous de fixer vos priorités.
Le mode classique permet d'isoler les lignes (trace debug, ...)

Essai facile à reproduire avec un tRowGenerator

[prince418]

ok donc je vais avoir besoin de passer en mode bulk car j'aurais des table dépassant les 150 millions d'entrées.

Et concernant votre Livre - je n'ai pas encore eu le temps d'y jeter un oeil - est-ce qu'il traite de ce genre de problématique?


Autre chose (je sais, j'ai beaucoup de question):

J'ai des flux sortant d'un tMap apres lequel je déclenche des job fils.
J'ai vu que le schema du trunjob se synchronisait avec l'input.
Comment procède-t-on, du côté du job fils, pour récupérer les donnée envoyée par le père?

[jnbarthas]

Vous trouverez un bref exemple sur l'utilisation du mode Bulk.

Regardez la Table Des Matières (http://www.editions-eni.fr/_Download...atieres%29.pdf) pour vous faire une idée plus précise selon vos interrogations.
L'aspect "passage de paramètres" est largement développé.

[prince418]

hum je ne sais pas si ma question a été comprise.
j'ai compris comment fonctionnais le passage de contexte mais je voudrais récupérer le row (main) du job pere dans le fils.
Je ne vois pas comment m'y prendre et du coup, je perds le schema du row et je ne peux plus continuer le traitement.

[jnbarthas]

Bonjour,

ce mécanisme n'est pas prévu. Il faut penser à un découpage adapté des traitements (Jobs Père et enfants).
Vous pouvez par contre faire suivre le curseur d'accès à une BdD pour conserver le mode transactionnel d'un job à l'autre.