Discussion :

[BiM]

Bonjour,

Je voudrais savoir ce que vous pensez de ce genre de solutions. J'ai l'impression d'être pionnière tellement je ne trouve pas d'infos. Je m'explique...

Nous n'avons qu'une seule source de données. C'est la base de données d'un logiciel que nous développons. Pour l'application, nous avons mis en place Hibernate afin de mieux gérer les données. La partie extraction existe donc déjà. D'autre part, nous avons des services métiers (Java) pour transformer ces données pour l'application. Pour la transformation de nos données, nous pouvons (et même devons) réutiliser ces services et en rajouter de nouveaux. Enfin, nous avons le modèle de notre DataWarehouse.
Le but du DataWarehouse dans l'application est de donner la possibilité à l'utilisateur de manipuler des données sans risque et de façon compréhensible afin d'en faire des tableaux de bord ou des rapports.

Pour reprendre au maximum ce qui existe dans l'application et s'adapter à la spécificité du projet, nous avons pensé à ceci :

Source de données (Base de données) ===Extraction (Hibernate)===> Données extraites (Classes Java) ===Transformation (Objets métiers Java + Autres transformations)===> Données transformées (Classes Java) ===Chargement (Hibernate)===> DataWarehouse

NB : On notera qu'il n'y a qu'une seule source de données.

Les volumes de données peuvent vite être important. Mais que ça mette 2 ou 3h à faire l'alimentation n'est pas gênant. Il ne faut pas non plus qu'on y passe la journée !

Pensez-vous que ce soit adapté ? Pourquoi ? Avez-vous des conseils à apporter ?
Connaissez-vous d'autre solution pouvant répondre à ce besoin ?

[Prjprj]

A priori, ta solution peut-être viable, mais cela risque d'être une usine à gaz.

Du J2EE sera toujours moins optimisé qu'un logiciel dédié à faire des transformations dans des bases de données, que ce soit au niveau performances comme au niveau développement.

Un logiciel d'ETL, c'est un outil avec une belle interface graphique où tu fais des flèches entre tes tables (c'est la version très simplifiée, mais on est dans l'esprit), c'est donc plus facile à développer et à maintenir.

Niveau perf, c'est très simple : ta solution passe par du J2EE, puis un framework puis des développements spécifiques avant de repartir vers le DataWarehouse, vu le nombre de niveaux, c'est pas forcément bon.
Un ETL, c'est un logiciel qui se met entre 2 bases de données, cela t'épargne pas mal d'étapes intermédiaires.

Pour rester dans l'esprit Java et pas/peu cher, Talend est un outil assez convivial, et plutôt bien fait pour faire ce genre de choses.

En espérant avoir répondu à tes questions.

[BiM]

Le truc c'est qu'on ne doit pas extraire de la base de données directement, c'est trop complexe. On préfère passer par des mappings Hibernate déjà existants et des données déjà chargées plutôt que de refaire un truc à part.

En plus de ça, les services métiers qui permettent de faire la plus grosse partie de la transformation ont besoin d'objets Java (qui sont ceux créés par Hibernate). Il n'est pas question de refaire ces services d'une autre manière car ils sont complexes et je ne veux pas répliquer du code déjà pas facile à corriger et susceptible de comporter des bugs.

En fait, tout ce qui est déjà existant ne sera pas refait c'est à dire l'extraction et une partie de la transformation. Il reste la fin de la transformation et le chargement à faire.

Donc pour la première solution, l'avantage était justement la maintenance (la partie ETL n'est de toute façon pas destinée à un utilisateur final mais uniquement aux développeurs) et l'évolution. Pour l'utilisateur, il appuie sur un bouton, l'alimentation se fait voir c'est automatique et donc complètement transparent.

Est-ce que Talend peut faire les parties restantes (fin de la transformation à partir d'objets Java puis chargement) ?
Côté Java, j'ai également entendu parler de Kettle, que vaut-il ?

Merci de ton aide en tout cas

[ygrim]

Salut,
Ta solution est bonne... pour ton cas et pour tout de suite. On sait tous que les besoins des entreprises évoluent, et des que cela deviendra multisources (et ça le sera surement) ta solution est mise en échec.
De plus, et comme a dit prjprj, coté performances, ce n'est pas l'idéal de faire passer les données par 3 couches avant d'arriver à destination. Ajoutons à cela le fait que tu modélise un entrepôt en étoile, et la partie chargement n'est pas une mince à faire (lookups, tris, validation, gestion des erreurs), et si tu ne fait pas passer tout cela par une seule source (un outil d'etl) l'entreprise sera soit condamné à garder la personne qui a développé l'ETL soit incapable d'integrer de nouveaux systèmes.

Je pense vraiment que les outils d'ETL font bien leur travail d'E, T et L. Il te suffit de recalquer ta logique métier dans tes ETL (séparation du décisionnel et de l'opérationnel) et tout roulera comme sur des roulettes

[BiM]

Salut,
Ta solution est bonne... pour ton cas et pour tout de suite. On sait tous que les besoins des entreprises évoluent, et des que cela deviendra multisources (et ça le sera surement) ta solution est mise en échec.

Ca ne deviendra pas multisources, ce n'est pas un DataWarehouse de stratégie d'entreprise mais bel et bien un entrepôt de données spécifique à l'application !

De plus, et comme a dit prjprj, coté performances, ce n'est pas l'idéal de faire passer les données par 3 couches avant d'arriver à destination. Ajoutons à cela le fait que tu modélise un entrepôt en étoile, et la partie chargement n'est pas une mince à faire (lookups, tris, validation, gestion des erreurs), et si tu ne fait pas passer tout cela par une seule source (un outil d'etl) l'entreprise sera soit condamné à garder la personne qui a développé l'ETL soit incapable d'integrer de nouveaux systèmes.

Côté performances, je veux bien le croire et c'est d'ailleurs pour ça que je cherche une solution adaptée et plus performante.
Pour la partie maintenance, je suis beaucoup moins d'accord. Le métier ça s'apprend, le code ça se commente. Bref, les mécanismes de transformation sont particulièrement complexes et peuvent comporter des bugs. Le fait de ne pas réutiliser le code métier qui existe déjà mais de le répliquer peut poser des problèmes lors de la maintenance justement. Puisque répliquer le code = répliquer les bugs = multiplier la maintenance.
Pour le schéma, il est lui aussi assez complexe, ce sont plusieurs flocons et quelques étoiles (Wé je m'amuse beaucoup des jours...).
En fait, il faut savoir que le DataWarehouse c'est le coeur de métier de l'application produite et vendue par notre société (éditeur de logiciel spécialisé et non SSII).

Je pense vraiment que les outils d'ETL font bien leur travail d'E, T et L. Il te suffit de recalquer ta logique métier dans tes ETL (séparation du décisionnel et de l'opérationnel) et tout roulera comme sur des roulettes

Voila, recalquer est une très mauvaise solution comme je l'ai expliqué précédemment. Ce n'est pas un outil pour mon entreprise mais un outil destiné à la vente par mon entreprise. Donc la maintenance c'est hyper important.

PS : C'est un logiciel de planification (optimisation, toussa) donc imaginez la complexité ! Je ne vais pas rentrer dans le détail mais il est hors de question de refaire les services métiers autrement. C'est pourquoi je me posais la question :
Est-ce la meilleure solution ou bien un ETL peut en faire autant (récupérer des données sous forme de classe Java, réutiliser des services métiers en Java pré-éxistants, etc.).

[ygrim]

Ta certitude en ce qui concerne le multi source `m'étonnes ! Sauf si tu n'utilises pas la définition d'un data warehouse quand tu utilises ce mot : c'est une vision centralisée des données de l'entreprise pour des fins d'historique et d'analyse décisionnel. Donc un entrepôt au coeur d'une application... Les schémas en 3eme FN le font très bien. Sauf, et je pense que c'est le cas, si j'ai mal compris ton besoin d'affaires...
En ce qui concerne les bonnes pratiques que tu as cité, c'est certain que cela minimise la dépendance, mais de la a l'enlever... Il faut savoir que c'est l'une des principale causes d'echec des projets BI et d'integration de données (le départ d'une personne clé). Mais encore une fois, si c'est pour un petit datamart, la question ne se pose plus.
Finalement, tu as l'option des WebServices qui est de plus en plus utilisée dans le transactionnel et dans le développement des ETL. Je crois que ça represente la meilleur alternative en terme de réutilisation / découplage de l'opération et de l'analyse de données. Et la plupart des ETL integrent l'utilisation de Web Services dans le CORE.

[BiM]

En fait le DataWarehouse pour cette application c'est une vision statique des données (des données précalculées et longues à obtenir) avec une actualisation quotidienne par exemple.

Pour la mauvaise nouvelle, je pars dans deux semaines de ma société mais disons que les services métiers toute l'équipe de dev les connaît. Le DataWarehouse est documenté. Donc je ne m'inquiète pas pour ça.

Merci pour tes réponses

[BiM]

Me voilà de retour, ahah !

Bon pour revenir au sérieux de la chose. Je regarde un comparatif pré-cité sur le forum (http://marcrussel.files.wordpress.co...-vs-kettle.pdf) qui compare les performances de Talend et de Pentaho/Kettle.

Mais je n'arrive toujours pas à savoir si je peux les adapter à mes besoins...
Les questions se reportent donc à ces deux outils et éventuellement d'autres (si des idées vous viennent à l'esprit).

1. Peut-on faire une extraction via Hibernate ?
2. Peut-on manipuler des objets Java lors de la transformation ?
3. Ainsi que des classes métier ?

En gros, j'ai un peu de mal à voir les possibilités réelles des outils.
J'ai d'autres questions plus générales :

1. Pour un gros volume de données, quel outil serait plus performant (à priori Talend) ?
2. Pour un volume de données correspondant au différentiel uniquement (certaines données à évolution lente particulièrement n'ont pas besoin d'être chargées à chaque fois), quel outil serait plus performant avec des transformations importantes ?

[Jester]

Je vais parler pour Talend/Java que je connais le mieux, et qui à mon avis sera le plus adéquat pour faire des choses si borderline.


1 - Je suis assez sur que non. A moins de développer un bridge sur ta couche DAO (ie faire un composant Java au début de ta chaîne de traitement qui fait l'appel).

2 - Oui, par défaut c'est des structures que tu manipules (bref des champs public) que les classes d'objets, mais il suffit de faire une méthode de conversion.

3 - Oui, mais il faut rajouter sous forme de lib. Ensuite au run time, je crois que j'ai déjà réussit à virer la lib pour que ça appelle des .class, ce qui est dans la lib étant + ou - un mock. C'est une limite de Talend de limiter un peu les liens avec du code java existant.


1 - De pas prendre hibernate je dirais. Ensuite Talend ou Kettle ça dépend.

2 - Encore une fois on s'en fout je pense, si la majorité de ton code est dans des classes métier.



Si c'est du chargement de données d'un BD puis traitement et sauvegarde dans la même BD, il peut être intéressant d'essayer de refaire le code métier en SQL.

Hibernate pour des traitements de données, c'est un peu de l'hérésie, je trouve. Je dis ça car je l'ai déjà fait et passer à du non hibernate a vraiment accéléré les choses.

[BiM]

Merci pour tes réponses

En fait, je crois que personne n'a compris le problème principal.

L'extraction Hibernate permet d'avoir des objets Java qui sont utilisés par les services métiers.

Ces services métiers sont très complexes, ce sont des choses infaisables en SQL, et il est hors de question de dupliquer ce genre de code. Donc vu que je dois (contrainte majeure) utiliser ces services métiers, je dois également utiliser les objets qui vont avec, donc Hibernate.

En fait, à vrai dire, l'extraction ne pose pas de problèmes. Si ce n'est en performances. Pour diminuer la charge (qui je suis d'accord peut vite être importante pour Hibernate), je voudrais juste faire le différentiel à chaque alimentation pour éviter les traitements inutiles.

Je voudrais à partir de mes objets Java, les transformer puis les charger dans le DataWarehouse. Pour moi, le moyen le plus simple (à première vue) est Hibernate pour faire cela (transformation des classes Java en d'autres classes adaptées au DW puis mapping Hibernate pour les charger dans le DW).

J'aimerai juste savoir s'il y a une solution plus simple pour le même résultat et si oui, les possibilités que m'offre Pentaho/Kettle ou Talend.

NB : Pourquoi avoir faire une extraction Hibernate ?

Ici, le datawarehouse est vu non pas comme un regroupement de sources de données mais une base de données statique adaptée au reporting (en terme de besoins, manipulations et temps de réponse). Ce DW est mis à jour quotidiennement à partir de la base du logiciel de base.

Donc, il y a une base unique au départ avec des données complexes traitées dans une application. Ces données sont extraites et mises en formes (avec des traitements complexes) grâce entre autre à Hibernate. Refaire tous les mécanismes pour reconstituer les données serait trop complexe et inutilisable en obligeant la réplication de code.

[Jester]

Je ne comprend pas trop la contrainte hibernate. Tu peux créer tes objets sans non? Bien sur ça demande un peu de code (mapping à la main). Si tu ne peux/veux pas faire cela (par exemple les Java de tes objet sont générés à partir du xml de hibernate et donc peuvent changer), il est évident que tu est bloqué sur hibernate.

Si hibernate est une contrainte et que le traitement est juste d'appeler une couche métier, je ne pense pas qu'utiliser un ETL soit utile.

[BiM]

Pour récupérer certaines données, il faut utiliser les services et les données de la base (récupérées via Hibernate). Ce sont donc des données calculer. Le but est de ne pas refaire ces services.

Donc pour la partie extraction, il faudrait Hibernate (le tout est déjà créé et fonctionnel).

Pour l'instant, la solution envisagée est de faire des classes Java pour la transformation. Et de refaire un mapping Hibernate pour charger les données. Mais il y a peut-être une solution plus simple

PS : Je débute dans les ETL, y'a moyen qu'il faille remettre les choses au point Faut pas hésiter

[Prjprj]

En BI, dans les "bonnes pratiques", quand on crée un DataWarehouse, il est recommandé de créer une base tampon entre tes applications sources et ton DataWarehouse, on appelle ça un ODS (Operational Data Store). L'intérêt d'un ODS est de copier temporairement les données de ton appli source dedans afin de ne pas stresser ton appli quand tu fais les transformations pour alimenter ton DataWarehouse.

Une solution pourrait consister à charger en différentiel ton ODS avec hibernate puis d'utiliser un ETL pour alimenter ton DataWarehouse, c'est pas l'idéal, mais c'est une solution qui te ferais probablement gagner en performances si tu as des données agrégées à calculer dans ton DataWarehouse.

Précision, ton ODS n'a pas besoin d'être une base physiquement séparée de ton DataWarehouse, tu peux jouer sur les conventions de nommage pour séparer logiquement tes bases

Concernant la complexité des transformations, les ETL sont très puissants, c'est pour cette raison qu'on s'en sert beaucoup. De plus, étant donné qu'on parle beaucoup de Talend, c'est un outil qui génère des programmes en Java pour faire tes traitements d'ETL, tu peux donc développer des transformations complexes en Java sans avoir à réapprendre un langage.
Je laisse aux pros de Talend le soin d'expliquer comment on fait

Je ne connais pas hibernate, donc si je raconte des bêtises plus grosses que moi (et vu mon poids, elles doivent être énormes ^^), n'hésitez pas à me reprendre

Bonne soirée

[Jester]

Je crois que tu veux dire data staging au lieu de ODS (ou que le data staging soit un ODS).

Un data staging c'est l'espace où l'on copies les flux des sources de données, on les traite puis on les envoie dans le data warehouse. C'est donc en gros un peu le bordel avec plein d'informations avec des codages hétérogènes (1 format pour chaque source de données).

Un ODS c'est (de mon point de vue), un espace de données correctement codées (format sémantique très proche à celui du data warehouse) mais dont l'objectif est de pouvoir être mis à jour. Par exemple, il peut y avoir une table qui stocke les mauvais payeurs. Celle-ci est souvent mise à jour. Un autre exemple est de stocker des données plus fines que ce qui se trouve dans le data warehouse pendant quelques heures.

Je pense que dans la problématique de ce thread, le data warehouse est un ODS (un système de cache pour l'application) et la source de données un data warehouse. Je ne pense pas que cela ait des conséquences sur le choix du système de traitement.

Si tu fais un prototype full java, ça prend combien de lignes de code? Si c'est moins de 200, je crois qu'autant faire simple.

[keevkilla]

Bonjour à tous,

Commençons par un petit lien, qui explicite la possibilité "technique" d'utiliser des classes JAVA et les DAO Hibernate dans Talend : http://www.talendforge.org/forum/viewtopic.php?id=2210

En revanche cela pose effectivement des problèmes de performances qu'un ETL est censé solutionner. Le fait de le coupler avec un Hibernate nous fait retomber dans les mêmes travers. La POO est intéressante pour la maintenabilité, l'évolutivité, la parallélisation des développements, mais ne rime clairement pas avec performance machine !

Plusieurs solutions ont été proposées ici, seules 2 d'entre elles permettant d'utiliser l'ETL, me semblent intéressantes :

• Le Web Service : en ajoutant un Web Service interrogeable de l'extérieur (donc par l'ETL) et faisant appel aux services métiers déjà développés de ton application, tu permets le découplage entre l'ETL et Hibernate. Cependant il n'est pas garanti qu'avec la quantité de données que tu es censé traiter, cette solution soit vraiment intéressante, car l'instanciation et le temps de réponse du Web Service ainsi sollicité constitueront finalement le même frein à la mise en place de cette solution.
• L'ODS : cette zone tampon permet également un découplage indispensable entre l'ETL et Hibernate. L'extraction devant être faite par Hibernate, et l'ETL ne devant servir qu'à transformer les données, la mise en place des tables de l'ODS est effectivement la solution. Reste à déterminer comment les données transformées devront être chargées dans le DataWareHouse (qui ressemble effectivement plus à un DataMart dans le cas exposé ici). Si le chargement par l'ETL en utilisant les principes natifs "mapping de champs" sans faire appel aux classes métiers, est retenu en tant que solution, alors l'ensemble de la solution "ODS" est envisageable. Sinon, il vaut mieux tout faire directement en JAVA dans Hibernate.

Nous avons eu la même problématique et nous avons finalement privilégié la solution "ETL pur" qui sera portée par Talend.