Reprise du message précédent :

Souvent, en effet...
 
D'ailleurs, j'ai vu passer récemment les slides de la stratégie data 2024 d'un grand groupe bancaire et c'est drôle de retrouver à peu près les mêmes sujets qu'il y a 3 ou 4 ans. Sur le volet data science, on parle toujours des "difficultés d'industrialisation" de la data science, ce qui laisse entendre qu'il y a toujours aussi peu de projets data science qui ont atteint le stade industriel. En 2016, quand j'avais moi-même rejoint un groupe bancaire, la problématique était EXACTEMENT la même.
 
Je reste convaincu qu'il y a derrière tout cela avant tout un problème d'outil.

 
Salut, est-ce que tu pourrais étayer un peu? Je suis moi même dans un grand groupe qui y est confronté...

Autant d'outils que de process et d'organisation et même d'épistémologie. Tant que tu fais de la data science tu restes dans le poc. Par définition la science n'a pas pour but d'industrialiser.
Ensuite ils y a aussi un gros problème de compréhension du sujet par les décideur, d'accès aux données réel et de formation.

Déjà quand on a pour objectif de lancer des PoC on est mal barrés, il y a peu de chance qu’un jour on arrive à industrialiser avec un ROI, pas forcément que financier d’ailleurs. Il faut dès le départ du projet se poser la question du passage en prod futur, avec tout ce que ça implique sur le SI, sur les processus métier, la maintenance et l’évolutivité, les aspects juridiques... Si après étude c’est pas faisable ou c’est hors de prix, pas la peine de lancer un PoC, il ira pas plus loin que le PoC.

De manière globale, la problématique est relativement simple. On a d'un côté une informatique qui utilise des outils "traditionnels" : des langages tels que Java ou C# (parfois du C++), des environnements en silos dans lesquels chaque applicatif dispose de son propre système de stockage de données (souvent en BDD, parfois en mainframe dans les grands groupes). Et de l'autre, on a des data scientists/engineers qui débarquent tout feu tout flamme avec leurs outils à eux, Python et R principalement, et avec le besoin de réconcilier des sources de données en provenance de plusieurs silos. Forcément, quand il s'agit de faire collaborer tout ce beau monde, c'est complexe parce qu'il n'y a quasiment aucun terrain commun sur lequel se retrouver.

Il y a eu pendant quelques temps l'espoir que Hadoop puisse être une solution en fournissant justement ce terrain de jeu qui pourrait convenir à la fois à l'IT et à la data science. En s'appuyant sur Java et en fournissant une plateforme centralisée de stockage et de traitement de la donnée qui supprimerait les silos, on a pensé que Hadoop pourrait marcher. Je n'y ai jamais cru pour ma part. Hadoop a plusieurs gros inconvénients qui l'ont empêché de s'imposer.

• Hadoop est trop complexe et cette complexité ralentit les projets. La mise en oeuvre d'un nouveau flux de données vers Hadoop par exemple est une tâche non triviale, or c'est un prérequis à tout le reste. Le développement sur Hadoop n'est pas non plus à la portée de la majeure partie des data scientists.
• Hadoop n'est pas adapté aux usages temps réel. Or, c'est souvent dans l'industrialisation de projets ML temps réel qu'il y a un vrai ROI à chercher.

Je reste également convaincu que Python et R sont de mauvais outils pour l'industrialisation de projets ML. R est une véritable plaie, laissons-le donc de côté mais même Python n'est pas la panacée. Les frameworks ML manquent encore de maturité, ils sont trop nombreux et ils évoluent trop vite en cassant souvent la compatibilité ascendante. Python garde du coup cette image d'outil pour faire joujou dans l'esprit de beaucoup d'informaticiens. J'insiste sur le fait que je fais ce constat sur le volet ML : Python en tant que langage general-purpose est tout à fait pertinent. De manière globale, la gestion des dépendances sous Python reste néanmoins très en-deçà des standards Java et complique le déploiement des applications. En fait, le modèle Python a du sens dès qu'on l'associe à une logique de containérisation mais il faut bien avoir conscience que beaucoup d'entreprises ne sont encore qu'au tout début de leur initiative container, surtout les plus grandes. Il faudra encore du temps avant de pouvoir déployer efficacement des applications en container dans ces environnements.

J'ajoute à cela le fait que beaucoup de data scientists/engineers se servent de Python comme ETL (pour réconcilier des sources de données ou faire du "feature engineering" ) mais Python est intrinsèquement un très mauvais choix pour cet usage : c'est lent, les types de données sont pauvres et la gestion des métadonnées est totalement absente. Il existe de vrais outils pour faire de l'ETL, typiquement utilisés par des informaticiens mais qui ne sont pas nécessairement très complexes pour autant. Dans ce domaine, la responsabilité de l'échec est à mon avis du côté des data scientists qui ont souvent une approche dogmatique de l'outillage et ne jurent que par leur framework de prédilection, alors qu'ils pourraient faire de l'ETL proprement au prix d'un petit effort et cantonner Python ou R au strict volet modélisation.

A ce stade, tu me demanderas probablement quelle est la bonne approche. A mon avis, elle consiste à s'appuyer sur :

• un ETL digne de ce nom pour la création des modèles de données et l'alimentation des entrepôts de données associés (qu'ils soient ou non sur Hadoop)
• Python ou R pour la modélisation
• des modèles en container si l'environnement technique de l'entreprise le permet ou un framework tiers pour rendre les modèles opérationnels (via des exports PMML pour les modèles ML ou ONNX pour les modèles DL).

Certaines boîtes estampillées data science ont tenté de proposer des solutions en sortant de leur domaine initial mais le résultat est souvent merdique. Je pense particulièrement à Dataiku (que j'avais poussé dans la banque pour laquelle je travaillais) qui est à mon sens une excellente plateforme d'exploration et de modélisation mais un mauvais choix pour l'industrialisation, malgré ce que leur marketing en dit. Dataiku essaie de faire son beurre sur l'illusion qu'un proto peut facilement être passé en production mais c'est une stratégie foireuse. Quel que soit le domaine, un proto ne s'est jamais transformé en produit fini à moindre coût.

Le cloud pourrait apporter un certain nombre d'avancées en simplifiant certaines de ces opérations. Le problème que j'y vois actuellement est que les fournisseurs cloud ont tendance à pousser leurs propres outils pour tout ou partie du processus (AWS Glue par exemple), ce qui fait qu'on réinvente ENCORE la roue et qu'il est impossible de capitaliser sur tout ce qui a été fait par le passé.

Vous noterez que j'ai réussi à faire un post sans placer MATLAB mais ça m'a coûté

Se pose effectivement la question de la position dans l'organigramme de la data science. C'est un peu un faux problème à mon sens... Si le management veut aller dans une direction et se donne les moyens d'y arriver, on y parvient. Il reste qu'une entreprise, c'est aussi un ensemble de personnes qui ont parfois leurs ambitions propres et prêchent pour leur paroisse, en dépit de l'intérêt général. Souvent, le sujet de la data vire au combat des chefs entre directeurs avec pour conséquence un manque de collaboration qui entraîne l'échec des projets.
 

Faut pas tout jeter non plus... Dans une phase de découverte d'un nouveau sujet, ça a du sens de faire des POC, même si on se plante à l'issue. Ça fait partie du jeu. Là où il y a un problème, c'est que cette phase doit durer maxi 2 ans. Une fois qu'on s'est forgé sa petite expérience, on doit être en mesure d'aller plus loin et clairement ce n'est pas le cas.

 
 

J'allais faire la remarque ... ça doit être l'effet confinement

Congrats ! Je lisais en diagonale jusqu'au mot clé. J'étais très surpris  

Blague à part, si on admet que le besoin fondamental s'articule autour des 3 capacités suivantes :

• ETL
• modélisation
• opérationnalisation des modèles

la raison pour laquelle je poussais MATLAB dans ma boîte précédente est que MATLAB traite plutôt bien le volet modélisation (quasiment aussi bien que R et Python) et, surtout, permet de traiter le volet opérationnalisation.
 
Ceci étant, en pratique, ça n'a jamais fonctionné... Les data scientists ont toujours adopté une attitude hyper fermée à base de "je refuse de bosser avec autre chose que R" et l'informatique a toujours été hyper dubitative à base de "la cible c'est le data lake". Il me semblait que MATLAB fournissait une alternative intéressante et pas chère, en tout cas nettement moins chère que SAS qui était l'outil en place dans la maison, dont tout le monde voulait se débarrasser pour des raisons de coût (plusieurs M€ par an) mais sans vraiment savoir comment s'y prendre. La sauce n'a jamais pris. On a finalement tenté de pousser du Python containerisé sans vraiment y croire puisque aucune infrastructure n'était en place à la prod pour héberger du container, ça a été là-encore un échec, comme prévu.
 
Au final, la boîte en question n'a toujours rien en place et le ML en prod reste une chimère...

Et de ton expérience des ETL, qu'est-ce que tu retiens de bon / moins bon ?

Je ne vais pas être objectif parce que je bosse pour un éditeur qui fait (entre autres) de l’ETL
 
Grosso modo, en-dehors de besoins spécifiques (gros volumes par exemple), je dirais que tous les ETL se valent plus ou moins. Du coup je suggèrerais d’utiliser celui qui est en place dans la maison. S’il n’y en a pas, Talend me semble être une option raisonnable. Attention néanmoins parce que contrairement à la plupart des ETL, Talend est un générateur de code (Java principalement), il y a donc peu de chances de parvenir à mettre en place un flux de données Talend en production sans le support de l’IT.
 
Il ne faut pas non plus négliger l’aspect temps réel. Globalement, c’est bien d’avoir un ETL qui puisse lire et écrire une source Kafka, puisque ça semble devenir le standard de facto.

c'est quoi un ETL ? (désolé pour la question de noob )

Quel est l'intérêt d'un export ONNX pour un modèle Deep Learning ?  
 
Ca tourne bcp plus vite pour l'inférence ? Ma boite pourrait faire ça au lieu de me casser les couilles pour 30 secondes d'inférence en plus  

 
https://fr.wikipedia.org/wiki/Extract-transform-load
 
https://www.dummies.com/programming [...] -big-data/
 

PMML et ONNX sont des formats d'échange, principalement. Ils ne permettent pas d'exécuter un modèle plus vite mais d'exporter un modèle vers une autre plateforme, ceci afin de le dissocier de l'environnement initial dans lequel il a été construit.
 
Quelques exemples d'utilisation :

• Dans la boîte pour laquelle je travaille, on génère du code source dans notre langage à partir de modèles au format PMML. Ça permet d'exécuter le modèle directement au sein du même process Linux, sans aucune indirection. Si on exécutait les modèles dans leur format d'origine via Python ou R, il faudrait instancier un nouveau process Linux à chaque fois que l'on souhaite effectuer une prédiction ou un groupe de prédictions, ce qui est extrêmement coûteux en batch et quasi impossible en temps réel.
• Chez MathWorks, le workflow suggéré est d'importer via ONNX un modèle DL entraîné dans un framework tiers (TF par exemple) et de générer du code bas niveau C/CUDA pour la cible désirée. C'est principalement utilisé pour l'embarqué (ARM, FPGA) où souvent il n'est même pas possible d'exécuter le modèle dans sa forme initiale mais ça peut aussi servir pour augmenter les performances quelle que soit l'architecture cible.

Salut,
 
Merci ppur les informations.
 

Tu as des listes d'ETL digne de ce nom ? Talend en est un si j'ai bien suivi ?

Apache Nifi, airflow, beam sont ceux que je vois le plus souvent quand ce n'est pas des solutions "propriétaires" qui sont déployées

Les plus connus sont Talend, Informatica et DataStage (IBM).

Merci.
 
Et ces ETL sont surtout utile pour du déploiement a large échelle en temps réel, genre les banques ?

Pas forcément. Dans ma boîte on a mis en place airflow qui sert de pont entre notre data brut sous pgsql et big query alors que notre db fait à peine 30go en prod. Mais pour les équipes bi et data science c'est le jour et la nuit

Non pour tous les besoins d'ETL sérieux (réguliers, besoin de transformer les données ...) même en batch.

Ce sont des outils un poil chiant à installer / mettre en œuvre mais le gain de temps, de fiabilité et de scalabilité qu'apporte ces frameworks font que c'est utile même en dehors des très grosses boîtes

À noter qu'avec le cloud le déploiement et la maintenance sont moins un sujet

Sur python pour moi les solutions sont vraiment "simple"
1) embaucher des datascientist qui savent coder
2) utiliser docker.
Ça marche vraiment.

Sur le fond on est d'accord, je dis exactement la même chose. Mais tu te places dans le cas idéal de la start-up innovante qui travaille avec des outils modernes et une dette technologique proche de zéro. Dans un grand groupe, quand tu es obligé de te coltiner un patrimoine informatique non négligeable, ce n'est pas aussi simple.

J'ai pas vue une seul solution qui fait le taf end 2 end pour du deep. Du coup tu te retrouve a devoir brancher 3 outils en parallèle ça n'a pas de sens donc tu refais tout toi même.

la conduite du changement tous ça

L'erreur est aussi de faire la différence entre dev et data. Genre les data envoie un truc degeu intégré par les dev. Ca marche pas ça. Python est un très bon language d'industrialisation mais il faut pour ça des dev python, pas des mec qui sont là pour la science et qui normalisent pas. Il faut aussi une infra interne, des pratiques normalisé etc...

Genre quand tu vois des mecs faire des jupyter notebook pour aller en prod... L'envie de meurtre

Chez nous, grosse boîte financière qui gère plusieurs centaines de milliards d'euros, moi et mon collègue on est en train de mettre un gros frein chez les Quant Front concernant l'utilisation de Python. Ils utilisent tous des bibliothèques Open Source, et aucun d'eux n'a mis le nez dans les programmes qu'ils utilisent : ils considèrent que comme c'est un langage "universel" et utilisé par "tous" cela légitime la qualité du contenu. Du coup on va très certainement les obliger à repasser sous Matlab, ou au moins il existe une personne morale responsable de la qualité du code vendu. Le risque est énorme pour nous, sachant que le régulateur peut nous tomber dessus et nous inffliger de grosses amendes pour risque de modèle  

Tous les datascientistent qui font  
 

 
en sueur

 
L'argumentaire à base de "comme tout le monde l'utilise, c'est safe" venant des scientifiques ça m'a toujours fait halluciner perso.
Pour l'anecdote, l'année dernière on a relevé une erreur assez importante dans un modèle implémenté par Bloomberg. Alors que l'outil est mainstream en finance, ça n'a pas empêché de relever des erreurs manifestes.

Python, c'est génial comme langage, mais c'est vrai que c'est loin d’être stable au niveau des bibliothèques. Des que scipy ou numpy qui changent un peu la structure, t'as d'autres qui s'effondre (Pandas, Rpy, scikit-learn, etc...).

Tu parles de BQuant? Des fonctions de pricing? MARS?

De PORT mais aussi de calculs de sensi crédit. Notamment sur les callable, convertibles et coco...

 
 
Personne ne price sérieusement en utilisant BBG.. Mais dans n'importe quelle lib de pricing y'a des bugs mais c'est parfois juste trop lourd à corriger donc les gens attendent la prochaine version..  
 
 
Je pense que le régulateur a autre chose à foutre

Ba aussi dans ce cas tu fais plus rien...t'utilise plus tf, plus aucune dépendance open source C++, java, js...même plus linux ... Tu reviens à l'assembleur, ou oui, a Matlab
Je comprend l'argument légal mais ça doit passer par des tests précis et bien spécifier, c'est complètement stupide de vouloir "maîtriser" tous ce qu'il y a dans les lib.

Pour moi le problème est pas dans l'utilisation de l'OS ça, mais dans la compétence des gars. Nous on utiliser tf et keras mais on sait creuser, on sait regarder ce qu'il y a sous le capot si besoin et on test les modules critiques...

Normalement c'est assez facile à maitriser ca. Faut juste avoir un truc de dépendance correct (pipenv, voir conda ou un simple requirement.txt). C'est ensuite souvent assez bien documenté.

tu recodes tes fonctions toi-même  de la calulatrice aux Neural Net
 
Ca être vraie science

Ou un framework a la Athena

A la différence de beaucoup de bibliothèques Python, les outils dont tu parles sont backés par de grandes sociétés et ça change tout.
 
TF --> Google
Java --> Oracle
Linux --> Red Hat et SUSE
 
Il faut aussi comprendre le niveau des enjeux... Quand il s'agit de calculer un taux d'exposition qui quantifie le risque de faillite d'un acteur dont la chute pourrait entraîner la chute de tout le secteur financier, forcément tu fais un peu plus attention à la façon dont sont calculés tes indicateurs que lorsqu'il s'agit de recommander des fringues sur Zalando