Discussion :

[challenger84]

Dans ma BDD source j'ai une table qui contient tous les lignes de mouvements des débits et des crédits de l'entreprise.
Pour calculer le fait "résultat" il faut faire un agrégat sur toutes ces lignes.

Mon problème est que cette table de mouvements contient actuellement près de 5 millions de lignes !!! Ce qui fait que faire le calcul sur tout cet ensemble prend énormément de temps à l'ETL.

Comment optimiser le chargement de ma table de fait qui contient le fait "résultat"?

J'avais pensé procéder comme suit: calculer à une date t1 le montant M1 du résultat .

Puis à un instant t2 (t1<t2), prendre les lignes de mouvements créés entre t1 et t2, calculer le montant M' du résultat correspondant à l'agrégation des lignes de mouvements obtenus.
Puis, mettre à jour le montant M2 du résultat à la date t2 avec:
M2 = M1 + M'

Ce qui fait qu'à l'instant t1 l'ETL mettra du temps à faire l'agrégat sur les 5 millions de lignes mais par la suite, le calcul sera plus léger à chaque fois qu'on lancera l'ETL. Qu'en pensez-vous?

[DevNico]

Salut Challenger,

Si j'ai bien compris ta problématique, cela dépend des fonctions d'agrégation que tu réalises pour calculer ton résultat.

S'il ne s'agit que de sommer ou de retrancher les valeurs, alors effectivement ta mise en oeuvre fonctionne.
(Si des lignes peuvent disparaître, si tu fais des moyennes, des last, des max ou des min, c'est un peu plus compliqué).


Cependant, pour ma part j'évite de mettre en oeuvre ce type d'alimentation car il complexifie l'implémentation, et on risque de se retrouver coincé s'il y a des modifications dans les règles de gestion (expérience vécue ).
De plus, l'exploitation du traitement est plus lourde (penser aux reprises de traitements), et là aussi on risque de se retrouver dans des impasses (que faire si un fichier reçu était foireux...).

Donc je te suggèrerais plutôt de travailler sur l'optimisation du temps d'exécution de ton traitement (agréger 5 millions de lignes ne devrait pas prendre des heures). Voir si l'agrégation ne peut pas être faite au niveau de la base de donnée, ou si les données peuvent être triées en entrée de l'aggregator.

Nicolas

[Jester]

En effet, le select sum(diff) from mouvement ne devrait pas prendre trop de temps. ça devait prendre une minute au plus.

Si ça doit aller plus vite, il faudra sans doute en effet faire une table d'aggrégation à cotée qui prenne par exemple le résultat du mouvement sur chaque mois. Elle devra être mise à jour via un trigger à chaque ajout/modif de mouvement.

Ensuite faire la somme sur cette table agrégée ira beaucoup plus vite.

[challenger84]

Donc je te suggèrerais plutôt de travailler sur l'optimisation du temps d'exécution de ton traitement (agréger 5 millions de lignes ne devrait pas prendre des heures)

Désolé de te contredire mais je te confirme que si!!!! LE détail que j'ai oublié de dire était peut-être le fait que la table de mouvements en question ne contient pas seulement les mouvements d'une seule entreprise mais de plusieurs entreprises de la compagnie.
Ce qui fait que j'ai une dimension entreprise et que chaque entreprise a sa propre valeur du résultat net à un instant t.
Comme il y a x entreprises, je dois parcourrir x fois les 5 millions de lignes pour y arriver et ça c'est pas évident!!!

D'un autre côté je suis tout à fait d'accord que si jamais il devait y avoir un update dans les lignes mon calcul serait faux

Et comme le dis DevNico la gestion d'une reprise de traitement risque d'être assez compliqué, une seule exception pouvant fausser tout le calcul...

Est-ce que la mise en place d'un staging area pourrait apporter des éléments de solution? Genre copier les lignes de mouvements dans cet espace avant de calculer l'agrégat mais dans ce cas là le staging area sera également composé de 5 millions de lignes...

[DevNico]

Désolé de te contredire mais je te confirme que si!!!! LE détail que j'ai oublié de dire était peut-être le fait que la table de mouvements en question ne contient pas seulement les mouvements d'une seule entreprise mais de plusieurs entreprises de la compagnie.
Ce qui fait que j'ai une dimension entreprise et que chaque entreprise a sa propre valeur du résultat net à un instant t.
Comme il y a x entreprises, je dois parcourrir x fois les 5 millions de lignes pour y arriver et ça c'est pas évident!!!

Là je ne suis pas certain de bien saisir ...
Il n'y a pas de raison de parcourir plusieurs fois les lignes de la table pour agréger sur les différents entreprises.

D'un point de vue sql, c'est un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Select Code_entreprise, sum(indic1), max(indic2)
From Table
group by Code entreprise

Donc une seule passe. Même avec un traitement powercenter.
J'ai faux ?

[challenger84]

En fait je pensai alimenter en faisant d'abord un select du contenu de ma table de dimension "Entreprise''.
Puis, faire une jointure avec la table de mouvements tout en calculant l'agrégat.

Je pensai faire ça car je trouve cette solution plus simple pour retrouver l'Id de mes entreprises, sachant que dans ma table de dimension l'id de chaque entreprise est différente de l'id utilisée dans la base de production.

En gros je fais ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
SELECT E.idEntreprise, M.Code_entreprise, sum(M.indic1), max(M.indic2)
FROM Mouvement M, ListeDimensionEntreprise E
WHERE
E.Code_entreprise = M.Code_entreprise
GROUP BY M.Code_entreprise

Dis-moi si c'est une bonne méthode où si il est préférable de calculer tous les agrégats, puis de faire un lookup des Id correspondants dans les table de dimension.

[DevNico]

Ta méthode me semble très bien d'un point de vue sql.

Peut-être que le problème vient de l'implémentation dans powercenter ?

Si j'ai bien compris, je dirais que ton traitement informatica devrait ressembler à ça :

SqTrans => ExpTrans => Aggregator => Insert

Dans le SqTrans, tu récupères les données de la table Mouvement et pourquoi pas en même temps les ID Entreprise dont tu as besoin via les jointures qui vont bien.
Dans le ExpTrans, tu fais éventuellement les transformations nécessaires à tes fonctions d'agrégation.
Dans l'Aggregator, la clé d'agrégation contient donc au moins l'ID Entreprise.

[challenger84]

J'ai pas encore travaillé avec Informatica, en fait mon ETL sur ce projet est Data Integrator de BO (anciennement ActaWorks mais racheté en 2002 par BO).

Ta description du cycle de traitement correspond à celui que j'ai envisagé.

Néanmoins ton précédent post a remis en question ma vision de l'alimentation, l'ordre des choses serait comme suit:
- faire un group by de tous les mouvements par entreprise
- pour chaque ligne agrégé, rechercher l'id de l'entreprise correspondant dans la table de dimension "Entreprise"
- insérer les lignes avec l'idEntreprise trouvée dans la table de fait

C'est une autre option mais dans tous les cas ça revient en fait à faire une alimentation non incrémentale dans la mesure où on est obligé de se taper toute la table de mouvement .

[DevNico]

J'ai pas encore travaillé avec Informatica, en fait mon ETL sur ce projet est Data Integrator de BO (anciennement ActaWorks mais racheté en 2002 par BO).

Ah désolé. J'ai extrapolé un peu vite

Ta description du cycle de traitement correspond à celui que j'ai envisagé.

Néanmoins ton précédent post a remis en question ma vision de l'alimentation, l'ordre des choses serait comme suit:
- faire un group by de tous les mouvements par entreprise
- pour chaque ligne agrégé, rechercher l'id de l'entreprise correspondant dans la table de dimension "Entreprise"
- insérer les lignes avec l'idEntreprise trouvée dans la table de fait

A mon avis, cela ne changera pas grand chose au temps d'exécution de ton traitement, les 2 mises en oeuvre se valent.
Une jointure sur une petite table de dimension avant agrégation ne prendra pas plus de temps qu'un lookup sur cette même table après agrégation. (Enfin je ne connais pas le fonctionnement de Data Integrator, donc à vérifier).
Mais c'est à toi de décider quelle mise en oeuvre convient le mieux

C'est une autre option mais dans tous les cas ça revient en fait à faire une alimentation non incrémentale dans la mesure où on est obligé de se taper toute la table de mouvement .

Tout à fait, et à mon avis c'est la meilleure solution du point de vue simplicité du traitement, donc maintenance et facilité d'exploitation.

Bon courage !
Nicolas