Au rythme d'une release tous les 3 mois, la 2.2.0 apporte de nombreuses enrichissements par rapport à la 2.1.x, côté studio de conception et côté génération de script Perl ou Java. Voici une liste des principales évolutions.
Nouveautés du studio : basé sur Eclipse 3.3, constructeur graphique d'expressions, glisser/déposer des metadonnées pour créer des composants préconfigurés ainsi qu'une refonte de la gestion des contextes simplifiant leur utilisation.
Nouveautés pour la génération de code Perl : performances accrues pour les jobs complexes, mesure de volume de données, recherche récursive de fichier, produit cartésien, fusion de flux, SCP, attente sur évènement fichier ou SQL, partage de connexion Oracle et PostgreSQL.
Nouveautés pour la génération de code Java : connecteur AS/400, appel aux procédures stockées, Slowly Changing Dimensions, LDAP, connecteur VTiger, export de job en tant que service web, SCP, attente sur évènement, support de Groovy, sortie dédiée aux erreurs pour les composants d'écriture en base de données.
Aller plus loin
- ETL, sur wikipedia (40 clics)
- Talend Open Studio (27 clics)
- Site communautaire (6 clics)
- Société Talend (6 clics)
- Annonce LinuxFr Talend Open Studio 2.0.0 (17 clics)
# Données géographiques
Posté par Vincent P (site web personnel) . Évalué à 7.
A noter que camptocamp sort une extension à Talend Open Studio, nommée SDI comme Spatial Data Integrator. Cela permet d'utiliser l'ETL sur les données géographiques, qu'elles proviennent de shapefiles, base postGIS ou autres. Des traitements spatiaux sont également disponibles, et d'autres fonctionnalités devraient apparaitre. Il est possible de générer du code java pour rejouer les process.
http://www.talend.com/press/oem-channel-with-camptocamp-part(...)
Une bonne nouvelle pour l'opensource, le seul ETL géographique jusqu'ici était FME, outil propriétaire.
Une question à propos de Talend Open Studio. Est ce que vous envisagez d'intégrer un générateur de code python, en plus du java et du perl ?
[^] # Re: Données géographiques
Posté par Pierrick Le Gall (site web personnel) . Évalué à 5.
En effet, CampToCamp va fortement collaborer avec Talend pour fournir des traitement spécifiques aux données géographiques.
Non, ce n'est pas dans la roadmap. Chez Talend, il n'y a pas (encore ?) de compétence Python. La question a cependant déjà été évoquée sur notre forum. Je pense que s'il y a des débouchés commerciaux et qu'on arrive à recruter des compétences, il n'y a pas de raison de ne pas le faire :-)
Pour le moment, entre Perl et Java, le moteur de génération est très proche. A mon avis, un langage comme Python nécessitera davantage de développements. Je pense qu'il serait par exemple plus simple d'ajouter Ruby que Python.
[^] # Re: Données géographiques
Posté par Farzad FARID (site web personnel) . Évalué à 5.
Excellente suggestion, je n'osais pas la faire et je suis content que ce soit un ingénieur de Talend qui la fasse :)
Je pense en effet que la production de code ETL en Ruby serait une excellente chose, le langage lui-même et surtout le framework de développement ayant le vent en poupe et servant dans de plus en plus de projets actuellement.
Je me demande si cette suggestion pourrait être prise au sérieuse et quel somme de travail demanderait cette implémentation ?
[^] # Re: générer du Ruby
Posté par Pierrick Le Gall (site web personnel) . Évalué à 3.
Je trouverais ça sympa également, ça pourrait me donner l'occasion d'apprendre Ruby. (et Python aussi d'ailleurs, j'aimerais bien apprendre)
Ensuite il faut être pragmatique : est-ce que les performances de Ruby sont suffisantes pour de gros volumes de données ? Est-ce que Ruby dispose de nombreux connecteurs ? Est-ce possible en France de recruter des développeurs Ruby ? Et surtout, est-ce qu'il y a des retombées commerciales potentielles ? (derrière Talend Open Studio, il y a une entreprise qui rémunère des salariés)
Aujourd'hui Ruby est connu grâce à et pour Ruby On Rails [1], le framework hype de développement Web. Dans Talend Open Studio, on est loin du développement Web (aucun rapport même, si j'ose dire). Donc est-ce que dans les entreprises, les personnes qui font du Ruby sont ceux à qui on va demander d'utiliser Talend Open Studio ? et hors entreprise, est-ce que le développeur Ruby est intéressé par un outil comme Talend Open Studio ?
Je n'ai pas de réponses à toutes ces questions. Je pense simplement qu'il faut qu'elles trouvent des réponses avant qu'on puisse s'engager dans cette voie.
Comme je le suggérais dans mon message précédent, je pense que le moteur de génération de code a besoin de peu de modifications. Par contre, c'est le développement des composants qui demandera un gros travail. Certains se développent en quelques minutes (tLogRow basique), d'autres en plusieurs jours/semaines (tAggregateRow, tMysqlSCD). Si on voulait être "isofonctionnel" Ruby/Perl il faudrait plusieurs mois de dev et Ruby/Java encore davantage.
[1] http://www.rubyonrails.org/
[^] # Re: générer du Ruby
Posté par doupatex . Évalué à 4.
Aujourd'hui, il existe plusieurs implémentations de Ruby : l'interpréteur C "original" (écrit par Matz, Yukihiri Matsumoto), la machine virtuelle YARV/Ruby2, JRuby, Rubinius, ...
L'interpréteur est assez lent (un petit peu plus que Perl dans les benchmarks). YARV était environ 4 fois plus rapide il y a quelques mois pour mes scripts maison, mais est encore en développement. JRuby est une implémentation complète niveau fonctionnalités, les performances sont équivalentes à l'interprèteur C, et on peut compiler en bytecode JVM (ou utiliser le JIT, voir http://www.headius.com/jrubywiki/index.php/JRuby_Compiler pour plus d'info).
Si tu parles des bibliothèques d'accès aux SGBD écrites en C, c'est assez fournit ; Oracle, PostgreSQL, SQLite, ... Avec JRuby, je suppose qu'on peut utiliser JDBC, donc pas de soucis.
Si l'on en croit http://rubyfr.org/ , ça doit exister... Il y a même une carte de France des rubyistes :-)
<publicité éhontée>Sinon ya moi :-))))</publicité éhontée>
Je manque de stats sur le sujet, mais je pense que Ruby est un très bon complément au Java (via JRuby), par exemple pour des règles métier complexes et fréquemment mises-à-jour. Ce que je veux dire, c'est que c'est une solution peu utilisée, mais qui a toutes les fonctionnalités de Perl avec une syntaxe objet plutôt agréable, et qui gagnerait à être connue (Rails est l'arbre qui cache la forêt). Les perlistes ne devraient pas avoir trop de difficultés à comprendre un script Ruby (c'était un des buts du créateur du langage).
Pour résumer, je crois que si on peut le faire en Perl, on peut aussi le faire en Ruby : les langages sont assez similaires tant au niveau de l'implémentation (vitesse d'exécution) qu'en ce qui concerne les "cibles" potentielles. Après, c'est surtout une question de goûts (je trouve le Ruby plus lisible, au cas où vous ne l'auriez pas deviné ;-) )
[^] # Re: générer du Ruby
Posté par Antoine . Évalué à 3.
Pour répondre aux mêmes questions concernant Python :
1. ça dépend de quels types de performances on parle. S'il s'agit d'algorithmes purement calculatoires sur de gros jeux de données, Python est un peu plus rapide que Perl et Ruby ( http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...) ), mais loin du C ou d'autres langages.
Ceci dit il est aisé de reprogrammer des boucles critiques, soit en C, soit dans un pseudo-Python traduit en C grâce à Pyrex ( http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ ).
De plus, il y a plein de bibliothèques performantes pour les besoins courants en Python. Il y a même du calcul scientifique avec Numpy ( http://numpy.scipy.org/ ).
Enfin il y a un optimiseur just-in-time qui permet une accélération appréciable sur certains types de code, Psyco.
2. les connecteurs sont dispos pour tous les SGBD majeurs du marché, de même que pour Perl et Ruby. Il y a aussi un ORM sophistiqué, SQLAlchemy.
3. ben oui, j'en suis la preuve vivante (que les développeurs existent, pas forcément qu'ils sont faciles à recruter :-))
4. c'est effectivement la question majeure pour vous. A mon avis, hormis le Web, Python a une communauté d'utilisateurs plus développée que Ruby (simplement parce que le langage est arrivé à un stade de maturité plus tôt, et les deux langages étant assez proches sur le plan sémantique, il n'y a pas de raison forte d'abandonner Python pour Ruby). Par ailleurs, Python et Ruby sont tous deux sur une phase ascendante, alors que Perl est manifestement en fort déclin.
Ceci dit, il est évident que Python et Ruby sont très loin de constituer le même marché potentiel que Java ou C#.
[^] # Re: générer du Ruby
Posté par Farzad FARID (site web personnel) . Évalué à 2.
Pour que mes propos ne passent pas pour du troll, je précise que j'ai utilisé et fait la promotion de Python pendant presque 13 ans. Mais je suis passé sans regret à Ruby l'année dernière car ce langage combine le meilleur de Python et de Perl, en plus de ses propres apports...
Quant la machine virtuelle YARV sera intégrée dans Ruby2, les performances du langage exploseront celles de Perl :)
Les développeurs Ruby sont encore un peu rares (ou alors bien cachés), mais la demande des entreprises est de plus en plus forte cette année ! J'ai moi-même été sollicité plusieurs fois pour des projets en Rails alors que je suis encore débutant. Je connais des développeurs expérimentés qui sont passés récemment d'Objective C (sur Mac) ou de Java/EJB à Rails. Je pense que la diffusion du langage et de Rails connaîtra une explosion dans les années à venir.
Quant aux retombées commerciales, comme tu le dis, c'est le marché qui le dictera, mais je pense que les clients voudront plus de Java d'un côté, plus de Ruby/Python de l'autre, et moins de Perl.
Le besoin d'ETL en Ruby et d'intégration en Rails existe, il n'y a qu'à voir le projet "ActiveWarehouse [1]" et son sous-projet "ETL Tools [1]"
[1] http://activewarehouse.rubyforge.org/
[2] http://activewarehouse.rubyforge.org/etl/
[^] # Re: Données géographiques
Posté par BAud (site web personnel) . Évalué à 4.
Je suppose qu'il y a des fichiers normalisés existants [1] (produits par divers systèmes intégrant un GPS... par exemple, autres ?) et qu'il s'agit de les intégrer à un système d'information géographique (genre basé sur Mapserver, autre ?) ou directement dans un base PostGIS avec les connecteurs (normalisés aussi ?) qui vont bien ?
[1] http://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27information_g%(...)
[^] # Re: Données géographiques
Posté par Larry Cow . Évalué à 1.
[^] # Re: Données géographiques
Posté par Libre (site web personnel, Mastodon) . Évalué à 2.
Dans le monde du SIG , nous avons de nombreux formats de données (au moins une 40e raster + vecteur). Premier intérêt : gérer et transformer n'importe quel format de données en un autre.
Les données sont génériques, nos besoins (en tant que client d'un fournisseur de données) ne sont pas toujours en adéquation avec les données attributaires fournit. Deuxième intérêt : filtrer les données superflux (ie virer des champs), aggréger, transformer, modifier, filtrer des données en entrés pour éviter d'avoir des données trop importante.
Les données sont souvent très importantes, et se taper à la main quelques Go à la main, c'est ... Bref .Troisième intérêt : automatiser des taches sur des données spatiales, sauver la procédure pour une utilisation lors d'une mise à jour.
Les données sont des données spatiales, on ne veut pas toute la France quand on travaille que sur l'Ile de France, on veut pouvoir faire d'autres traitement spatiaux. Il existe des logiciels pour cela, ceci-dit inclure ce genre de tache dans le processus de préparation de données tel que le propose le logiciel de Tallend est très intéressant.
En espérant avoir fournit quelques réponses aux questions.
Y. en attente de ce fabuleux joujou :)
# Licence des scripts générés
Posté par Franck Routier (Mastodon) . Évalué à 4.
Quel est ensuite le contexte d'éxécution des "scripts" : autonomes, ou nécessitent-ils un runtime (un serveur, une bibliothèque Talend) ?
Et quel est le statut de ces scripts en terme de licence ?
[^] # Re: Licence des scripts générés
Posté par Ludovic Gasc . Évalué à 5.
Pour le contexte d'execution, tu choisis ce que tu veux, mais par défaut, il te sort un zip autonome qui contient tout ce qu'il faut pour executer le script (script+librairies).
Le seul pré-requis est d'avoir la machine virtuelle java ou perl.
J'ai vu dans les scripts générés une référence à la licence LGPL.
[^] # Re: Licence des scripts générés
Posté par Pierrick Le Gall (site web personnel) . Évalué à 2.
Donc c'est bien du LGPL comme Ludovic le dit.
Je confirme également que l'intérêt du générateur de code est de créer des scripts autonomes. Pour répondre un peu plus généralement, Talend Open Studio est un client, pas un serveur.
# A quoi ça sert ?
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
On m'avais répondu que je faisais fausse route. Soit.
Alors quitte à passer pour un *** qui aurais pu RTFMé un peu quand même, et qui bien qu'aiment beaucoup java (et perl), ne parle que très moyennement le 22si (si j'ose dire), je pose la question franchement :
a quoi ça sert ? Oh, oui à quoi ?
Par ce que :
pas glop :(
[^] # Re: A quoi ça sert ?
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
[^] # Re: A quoi ça sert ?
Posté par BAud (site web personnel) . Évalué à 4.
- à relecture de tes commentaires et des miens, tu voyais l'ETL comme le stockage centralisé de plusieurs données
- alors que l'objet de l'ETL c'est d'acheminer les données, les faire circuler en adaptant les modèles de données d'une application à l'autre au besoin
Si tu veux je pousse la caricature à fond, l'ETL c'est ce qui te permet d'écrire facilement :
INSERT INTO PAIE.employé (id_employé_paie,etat_paie_employé...)
SELECT FROM RH.employé(id_employé_rh, etat_rh_employé...)
cela suppose que tu as aux deux extrémités une application de paie et une application de gestion des Ressources Humaines qui en effectuent le stockage (et les traitements afférents). L'ETL permet de "normaliser" via l'outil tous ces flux de données, par exemple quand tu changes l'un des logiciels bin tu changes au niveau de l'ETL et non pas dans tous les autres logiciels, en terme de développement c'est un des intérêts. En terme de fonctionnement ça évite d'avoir foultitude de scripts de partout qui se déclenchent on ne sait pas comment et qui ne sont même pas tous développés dans les mêmes langages... (ce qui donne un espoir de faire de la réutilisation via l'ETL des interfaces déjà développées).
Pose plutôt des questions précises si tu veux des réponses précises ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.