Mon talk Paris.rb sur l'ETL avec Ruby

[Thibaut Barrère]

Hello, liste calme.

j'ai donné un talk mardi dernier sur l'intérêt du traitement de données (ETL) et comment le réaliser avec ma petite gem Kiba ETL. Le talk a reçu un bon accueil, aussi j'ai décidé de l'enregistrer (en anglais).

Le voici pour ceux que ça intéresse:

http://thibautbarrere.com/2015/11/09/video-processing-data-with-kiba-etl/

Au sommaire:

- interêt "business" du traitement de données.

- présentation de Kiba.

- session "live coding" sur un exemple très simple, qui montre bien la nature itérative du développement.

Bon visionnage :-)

-- Thibaut

[Florian Dutey]

J'ai une question inutile.

Etant donne que le HanZi veut dire "dent", est-ce le nom que tu voulais donner a ta gem? Si oui, pourquoi?

--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse rails...@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Railsfrance".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Romain DURRITCAGUE]

Très intéressant ;)

--

--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse rails...@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Railsfrance".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

--

--

Romain Durritçague
(+33) (0) 6 73 18 54 02

Owner at Studio Melipone

More details : https://organigr.am/romain_d

[Thibaut Barrère]

Hello Florian,

J'ai une question inutile.

Etant donne que le HanZi veut dire "dent", est-ce le nom que tu voulais donner a ta gem? Si oui, pourquoi?

C'est bien le nom que je voulais donner (enfin plutôt "croc" dont j'ai vu souvent que c'était la signification plus précise).

Quand je travaille sur des données, j'ai souvent l'impression qu'il faut un peu "tailler dedans", creuser, etc; voilà un peu le lien même s'il n'est pas primordial, le nom est court et facile à retenir et ça m'allait bien également :-)

-- Thibaut

[Florian Dutey]

Haha, interessant.

Je sais pas si le sens en japonais est aussi precis, mais en chinois, c'est "dent" sans plus de precision (il est employe dans "se brosser les dents" par exemple). Du coup, j'avais interprete ca en mode "macher les donnees". J'etais pas si loin.

Sympa la pres' sinon. Mais je me demande (question utile cette fois): Le code est clairement super modulaire et c'est tres appreciable (c'est le point que tu mets en avant) mais ruby en soit est pas super rapide pour ce genre d'operations.

Qu'est-ce que ca donne sur des gros volumes de donnees? As-tu des comparaisons avec d'autres solutions? Est-ce que tu es capable de donner un ratio "temps d'execution" par rapport aux "gains de productivite" et/ou "maintenabilite du code"?

[Thibaut Barrère]

Je sais pas si le sens en japonais est aussi precis, mais en chinois, c'est "dent" sans plus de precision (il est employe dans "se brosser les dents" par exemple). Du coup, j'avais interprete ca en mode "macher les donnees". J'etais pas si loin.

Oui c'est l'idée!

 

Sympa la pres' sinon.

Merci :-)

 

Mais je me demande (question utile cette fois): Le code est clairement super modulaire et c'est tres appreciable (c'est le point que tu mets en avant) mais ruby en soit est pas super rapide pour ce genre d'operations.

Qu'est-ce que ca donne sur des gros volumes de donnees? As-tu des comparaisons avec d'autres solutions? Est-ce que tu es capable de donner un ratio "temps d'execution" par rapport aux "gains de productivite" et/ou "maintenabilite du code"?

La cible est plutôt les datasets de taille moyenne (donc quelques centaines de Mo à quelques Go par "nuit", voire plus selon le type de traitement) que des gros volumes. Cela dit on peut optimiser de plusieurs façons, notamment en détectant les boucles critiques et en déléguant le traitement de certaines choses aux outils pertinents sur ces boucles (ex: utiliser le bulk load de votre database destination, utiliser freebcp pour exporter des gros volumes de données de SQLServer, appeler des outils comme "embulk" à certaines phases du traitement etc), tout en gardant le contrôle du work-flow global avec Ruby ce qui apporte beaucoup de souplesse.

On peut également paralléliser le traitement (que ça soit avec un dév custom, lancer N processes, ou encore avec le prototype Kiba Pro d'engine multi-threadé qui permet de lancer le même job en mode multi-cores, efficace même sur MRI lorsqu'on a des tâches qui sont "IO bound"), si c'est pertinent.

J'ai remarqué par ailleurs qu'il est fréquent de surestimer le volume à traiter dans nos données (j'avais mentionné ça à Rulu en 2012 dans un autre talk), donc on a parfois de bonnes surprises quant au débit obtenu :-)

Pour les cas où le débit brut est absolument essentiel (centaines de Go par jour, To etc), il est préférable d'utiliser d'autres solutions (et je travaille aussi avec d'autres outils que Ruby pour ça, creusant actuellement le big data etc etc).

En conclusion, on peut travailler sur des volumes de données de taille raisonnable (notamment dans mon cas, je travaille souvent avec des startups SaaS en B2B, où le ratio "valeur de la data / coût du traitement" est plus important qu'en B2C, et ou les sources de données sont souvent du http où ruby n'est plus le bottleneck), tout en gardant un fort niveau de qualité.

J'espère que ça répond correctement à ta question!

Thibaut

--

http://thibautbarrere.com/

[Florian Dutey]

Ca repond carrement. Merci beaucoup :)

[Guirec Corbel]

Salut,

Juste pour savoir, au niveau de la rapidité, as tu pensé à utiliser Crystal : http://crystal-lang.org/. À priori, ça me semble un bon outil pour la rapidité tout en gardant l'élégance de Ruby. Par contre, ce n'est pas encore très stable.

Bye,

Guirec.

[Thibaut Barrère]

Salut Guirec,

Juste pour savoir, au niveau de la rapidité, as tu pensé à utiliser Crystal : http://crystal-lang.org/. À priori, ça me semble un bon outil pour la rapidité tout en gardant l'élégance de Ruby. Par contre, ce n'est pas encore très stable.

J'ai regardé il y a quelques temps mais effectivement pour l'instant je préfère conserver des choses assez stables.

A titre d'information je commence à expérimenter des traitements de données avec Elixir (et également dans le passé JRuby et un peu de Java, ce qui va assez vite et permet de disposer de tout l'écosystème JVM).

Voilà :-)

-- Thibaut

[Guirec Corbel]

J'ai une question : As-tu déjà eu à extraire des données venant de SAP Ecc pour les mettres ailleurs ? J'ai travaillé pendant un ans ou deux avec SAP BW qui fait, grosso-modo, la même chose que toi mais pour SAP. La plus part du temps, c'est compliqué pour rien. Ça marche pour des trucs simple mais ça devient vite compliqué. Il y a un ans, j'aurai été content d'avoir un outil comme le tien pour SAP.

[Thibaut Barrère]

Bonsoir,

 

J'ai une question : As-tu déjà eu à extraire des données venant de SAP Ecc pour les mettres ailleurs ? J'ai travaillé pendant un ans ou deux avec SAP BW qui fait, grosso-modo, la même chose que toi mais pour SAP. La plus part du temps, c'est compliqué pour rien. Ça marche pour des trucs simple mais ça devient vite compliqué. Il y a un ans, j'aurai été content d'avoir un outil comme le tien pour SAP.

J'ai fait quelque chose de similaire, non pas avec SAP mais avec un système analogue d'un autre (très gros) éditeur: BMC/ARS Remedy (http://www.bmc.com/it-solutions/remedy-itsm.html).

J'ai créé des extracteurs ARS Remedy pour activewarehouse-etl (avant de créer kiba), capables d'extraire la donnée en "change data capture" (donc extraire tout, ou bien extraire uniquement ce qui a changé depuis la dernière extraction), sur des volumes importants.

J'ai également écrit un pont JRuby qui sait parler aux API Java d'ARS, pour être capable de créer, modifier, effacer des records avec une syntaxe proche d'ActiveRecord (on passe un Hash ruby etc).

A partir de ces éléments techniques j'ai pu créer de nombreuses micro-applications d'extensions de ce CRM, dont:

- une extension Ruby permettant d'injecter des validations métier lors de l'édition du CRM, via un appel de process externe (ex: valider un compte bancaire IBAN, dans le CRM qui ne le permettait pas simplement)

- générer des documents PDF avec Prawn et les attacher au CRM

- extraire des données du CRM pour les placer sur une carte exposée sur internet (gestion de réseau de partenaires etc)

- un datawarehouse complet pour générer des rapports et KPI

Et encore pas mal d'autres choses :-)

Donc oui, je vois tout à fait le parallèle avec SAP, Ruby peut tout à fait être utilisé en entreprise pour développer des extensions à haute valeur ajoutée sur des systèmes plus "rigides" si j'ose dire, avec succès.

Si quelqu'un a un intérêt fort à utiliser Ruby avec SAP pour des échanges de données, qu'il me contacte pour qu'on étudie une collaboration :-)

-- Thibaut

[Guirec Corbel]

Au niveau de SAP, le princpale problème est la structure de la base de donnée. C'est plus de 10 000 tables avec noms comme TKWD1 et des nom de colonnes comment AWSP sans cohérence. Le principe de BW c'est surtout de rendre plus humain les représentations de données. De plus, il n'y a pas de documentation sur la structure des tables et la logique est souvent tordu. Je pense que 90% de la tâche serait de comprendre les données et de savoir ce qu'il faut extraire. Par exemple, si tu veux accéder à la liste des ordres internes, il faut passer pas des tables comment BDSW,  PTKP et VJBK lié par les colonnes, VFDP et VHFL, ça ne s'invente pas, faut juste fouiller.

Bref, ton outil et très intéressant. Ta vidéo me donne envie d'en avoir besoin. Et c'est cool de voir qu'on peut s'en tirer avec un accent anglais approximatif.

[Thibaut Barrère]

Bonjour,

C'est plus de 10 000 tables avec noms comme TKWD1 et des nom de colonnes comment AWSP sans cohérence

C'est la même chose dans plusieurs CRM "customisables". Les tables physiques ne correspondent souvent pas aux tables logiques, en particulier si le CRM/ERP permet à des non-techniques de créer des tables et des forms de façon flexible!

Dans BMC/Remedy ARS j'ai eu le même souci, et j'ai donc cherché un moyen de faire sortir la data en interrogeant les tables logiques, et non les tables physiques. Cela apporte certaines contraintes (dans certains cas, les noms de colonnes seront des "labels" plutôt que des identifiants, il faut se protéger contre les changements).

J'ai trouvé deux façons de faire sortir les données - ça fait effectivement partie du travail que de trouver le bon tuyau :-)

> Bref, ton outil et très intéressant. Ta vidéo me donne envie d'en avoir besoin. Et c'est cool de voir qu'on peut s'en tirer avec un accent anglais approximatif.

Content que ça te plaise :-) Et oui sur l'anglais, il ne faut pas se formaliser trop sur l'esthétique de l'accent (même chez Google, ils ont des gens avec des accents!). Les français s'en inquiètent souvent, mais les boites américaines et anglaises avec lesquelles je travaille actuellement trouvent mon anglais largement suffisant pour travailler sans problème ensemble.

-- Thibaut

[Florian Dutey]

"approximatif" n'est clairement pas le mot que j'aurais utilise pour qualifier l'anglais de Thibaut.

"identifiable comme francais", c'est evident. Mais c'est consistant et reconnaissable, ce qui est a mon sens le plus important. La consistance permet de "s'habituer" a l'accent, encore faut-il que ce soit reconnaissable.

Je pense Guirec, que tu n'as aucune idee de ce qu'est l'accent francais "brut de forme"... C'est affreux! Wizz pour with, ze pour the, tree pour "three", des ajouts de "h" partout la ou il n'y en a pas (transformant "eat" en "hit" ou "heat", puisqu'il n'y a aucune difference entre "i" et "ea" pour eux)... 

Hors du domaine de l'accent, l'utilisation detournee d'adverbes qu'on peut qualifier de criminelle: "eventually" pour dire "maybe", "actually" pour dire "right now", "hopefully" pour dire "luckily"...

Pour vivre en asie depuis quelques annees et cotoyer beaucoup de nationalites differentes, je te dirais que l'accent espagnol est vraiment penible , l'accent japonais et coreen est tres approximatif (et tres incomprehensible). Et meme chez les natifs, c'est chaud. Les australiens sont vraiment bizarres et les irlandais sont une blague. Je te parlerai bien de l'accent italien en chinois mais rien que cette idee me tue de rire, m'interdisant d'utiliser mon clavier.

Les francais plutot fluent comme Thibaut n'ont absolument aucun probleme a etre compris, ce qui est le plus important. Et en plus, selon les natifs, cela confere un charme certain dont on peut certainement tirer parti :D. A la limite, si tu veux vraiment lui faire un reproche sur son anglais, je pense que le rythme est plus attaquable que l'accent, mais franchement pas de quoi se scandaliser non plus.

Enfin, la reference est faite par rapport a quel accent? Parce qu'entre le texas, new york, welsh et london, y'a une sacree difference. Du point de vue de Gordon Ramsay (best accent ever!), un saggy bottom texan doit sembler tres "approximatif" aussi. Et toi qui est canadien (sauf erreur de ma part) et donc constamment attaque par les americains a propos de choses comme "abot" (au lieu de "about"), tu devrais savoir ;)

[Guirec Corbel]

Bonjour,

Je ne voulais pas lancer une polémique sur la langue. Je disais approximatif parce-que je trouve ça drôle. Je suis français vivant au Québec (Ne dites pas à un Québécois qu'il est Canadien). J'ai un accent horrible mais je pense que l'important c'est surtout d'oser parler de passer par dessus ça. On peut continuer la discussion sur le slack de parisrb : https://parisrb.slack.com/ si vous voulez.

 Bref, ça a l'air bien tout ça. Beau travail Thibaut.

[Thibaut Barrère]

Je ne voulais pas lancer une polémique sur la langue. Je disais approximatif parce-que je trouve ça drôle. Je suis français vivant au Québec (Ne dites pas à un Québécois qu'il est Canadien). J'ai un accent horrible mais je pense que l'important c'est surtout d'oser parler de passer par dessus ça.

Pas de souci, il n'y a pas de polémique :-)

 

On peut continuer la discussion sur le slack de parisrb : https://parisrb.slack.com/ si vous voulez.

Je n'étais pas inscrit, c'est corrigé.

 

 Bref, ça a l'air bien tout ça. Beau travail Thibaut.

Merci!

-- Thibaut