Discussion :

[hittony]

Bonjour,

Qui connait un produit dont le nom commence par "sam"? Il semble qu'il est développé par des anciens développeurs de Sunopsis.

Merci d'avance et bonne fin de journée

[hittony]

Je l'ai trouvé. C'est Stambia.

http://www.stambia.com/

Quelqu'un connait ce produit?

[sofiane_bfm007]

Bonjour,
C'est un E-LT et pas un ETL !!!

[boubsy]

salut,

L'architecture de base à l'air solide.
On sent l'empreinte Sunopsis en plus abouti (architecture).

En tout cas c'est courageux de lancer un nouvel outil sur un marché déjà bien saturé.

Par contre en terme de maturité, il va falloir attendre. Dommage qu'ils n'aient pas choisi la voie de l'open-source, cela aurai raccourci drastiquement la période de maturité.

boubsy

[doc malkovich]

Bonjour,
C'est un E-LT et pas un ETL !!!

Un ELT est aussi un ETL !!!
D'ailleurs il est typé en ETL sur la page d'accueil, en bas ...

Sinon non, je ne connais pas le produit, je n'en avais jamais entendu parler avant.
Comme boubsy je ne vois pas l'intérêt d'une nouvelle solution payante alors que seules les solutions opensource ont un espoir de percer.

[sofiane_bfm007]

Un ELT est aussi un ETL !!!

Bonjour,

Oui c'est bien un ETL mais particulier !!!!!

Un Extract Load Transform (ELT ou E-LT ou ET-LT) est un outil d’ETL (intégration de données) particulier.

Mais un ETL n'a pas le même fonctionnement qu'un ELT.

UN ETL est un moteur de transformation qui extrait les données depuis les SGBD ou autres sources , qui établi des transformations, et charger ces données dans des entrepots. Les ETL sont indépendants des SGBD.

Par contre, un ELT n'a pas de moteur d'exécution mais utilise les capacités de traitement des bases de données et a l'avantage d'être très performants sur des gros volumes de données.

Réf :

http://fr.wikipedia.org/wiki/Extract_Load_Transform

L’ELT tire parti des technologies existantes dans les systèmes d’information pour effectuer les transformations sur les données. A l’inverse de l’ETL qui utilise un moteur propriétaire (ou un code généré et compilé) pour effectuer la transformation des données, l’ELT utilise les bases de données sources ou cibles, ou bien les autres systèmes capable de faire de la transformation.

Je ne vois pas trop l'avenir de cette solution "Stambia" car actuellement Oracle Data Integrator le fait très bien

[hittony]

Je trouve que l'interface est un peu trop technique. La prise en main n'est pas facile pour un débutant.

Je pense que la seule solution pour concurrencer ODI est de vendre moins cher le produit, mais avec un support payant.

Y-a-t-il un comparatif de ODI avec Stambia ou un autre outil ETL?

Bon WE les gars

[pascal7459]

Bonjour

Nous utilisons Sunopsis ODI depuis 10ans
Je suis actuellement entraint de tester Stambia en vue de remplacer ODI

L'outil est plus parametrable que ODI et la gestion des XML et Web service est bien meilleur.
Pour la fiabilité, je n'ai pas rencontré de probleme pour le moment et une grande réactivité du support incomparable avec la lourdeur du support d'oracle.

Je vais faire tourner des interfaces de production pour tester la fiabilité de l'outils.

[Claudio75]

Les ETL peuvent en théorie être perçus comme des EL-T mais la distinction est importante.

La plupart des ETL proposent des extensions pour déclencher des requêtes Sql sur les données chargées en base, mais dénaturent le fonctionnement d'origine du produit.

En effet, le fonctionnement standard est d'utiliser le Designer graphique dont le fonctionnement est câblé avec le moteur de traitement des données. Ainsi la promesse de réaliser des traitements graphiquement sans code est maintenue.

Souvent, lorsque le traitement est trop complexe ou que les temps de réponse dérivent, il est nécessaire de développer des extensions en Sql pour s'en sortir.

Le principe est de charger les données le plus directement possible dans la base avec la fonction standard « EtL » où le « T » est réduit à sa plus simple expression (peu de transformation), puis le gros du travail « T » (l’essentiel des transformations) est fait en Sql ou en procédures stockées.

Donc, la plupart des ETL qui se prétendent des EL-T sont en réalité des EtL-Sql.

C’est pour cela qu’il faut distinguer les ETL des ELT.

Les ELT respectent les phases « EL » correspondant à la création d’un container de données dans la base d’exécution puis la phase « T » ensemble de requêtes de transformation utilisant le moteur de la base d’accueil.

Je connais personnellement 3 ELT réellement pensés et mis en œuvre en tant que tel. Ce sont les suivants :

- Oracle Data Integrator (ex Sunopsis), bien connu,
- Stambia (www.stambia.com) un produit dérivé de Sunopsis avant le rachat par Oracle et
- DataStudio (www.data.fr), un petit éditeur mais dont les références sont notables.

Actuellement, beaucoup de DSI cherchent une alternative à ODI (augmentation forte du prix du support, dégradation de la qualité des versions, voire menace de disparition du produit en tant ETL pour une orientation vers un frame work de développement pour Oracle).
Le problème c’est de reprendre l’existant et de conserver une approche organisée des développements des interfaces pour ne pas faire un recul de 20 ans et revenir aux développements spécifiques anarchiques et ingérables.

C’est pour cela que pour augmenter les chances de réussite de la reprise, il vaut mieux s’orienter vers EL-T lorsqu’on dispose d’un capital important de réalisations en déjà EL-T.
C’est mon opinion.

[Jester]

BO DI peut facilement servir de EtLT. Il n'est pas mauvais pour transformer les boites graphiques en query pur SQL. Talend a des boites ELT mais ce n'est pas générique.

Pour ma part je préfère encore écrire le SQL du T et utiliser l'ETL comme outil pour le mouvement inter-base et l'orchestration. Le SQL permet de faire le dev et la recette hors de l'outil ETL, d'être portable si l'ETL change ou si besoin dans l'opérationnel. Ca en plus d'être souvent plus efficace et d'éviter de se compliqué la vie à faire 50 boites pour un truc simple en SQL. Par exemple, les fonctions de fenêtrages ou analytiques en boite ETL je suis pas sur que ce soit simple.

[Claudio75]

Salut Jester,
Je suis entièrement d'accord avec tes deux arguments : 1/ il est en général plus efficace d'écrire du Sql 2/ Il faut à tout moment pouvoir sortir son code pour changer d'ETL éventuellement.
Concernant le périmètre d'utilisation de l'ETL, au delà de l'orchestration des traitements, tu peux aussi demander à l'ETL de gérer le travail à plusieurs avec des rôles, de versionner les projets, de faciliter le déploiement dev/recette/prod, de fournir un monitoring parfait des traitements, voire de te permettre de mettre au point tes traitements en sql directement dans le produit (entre autres, xml, web services...).