Reprise du message précédent :

 
Je suis pas forcément d'accord.
 
Dans l'absolu je trouve la syntaxe SQL propre mais là où je suis d'accord c'est que ça peut vite devenir un enfer de dimensionalité genre les codes qui font 500k lignes avec des sub-query de partout, etc.

I

W

H

La centième

Le FreeCodeCamp https://www.freecodecamp.org/
On trouve sur ce site une partie data science et calcul scientifique avec python (D3) et l'introduction au python de Charles Severance vaut le coup je trouve mais s'adresse vraiment aux newbies

Dataquest si comme moi tu peux pas piffrer les vidéos a tout bout de champs

Vous gérez comment vos données ?  
 
Grossièrement notre pipeline actuelle c'est : database -> scripts -> arrays.npz avec toutes les images au bon format & méta-données. Le problème c'est que la base de données est modifiée régulièrement... donc impossible de reproduire une expérience passée et je pense que c'est un gros problème. D'ailleurs là je suis en call, ils savent pas quelles données ont été utilisées par le code actuellement en prod    
 
Là j'ai push pour une solution intermédiaire genre un S3 bucket où on dump le dataset utilisé pour X modèle, au moins si on veut reproduire les résultats du modèle bidule version 4 daté de janvier, on aura juste à télécharger le fichier dataset_modele_bidule_version_4_01_2020  
 
Mais je suis sûr qu'il y a de bien meilleures solutions    
 

T'as qu'à versioner les données dans un repo  git lfs

S'il y a des données médicales, ça peut-être compliqué, voir impossible.

Pourquoi?

T'as des règles super strict a ce niveau (GDPR, HIPAA). J'imagine qu'un repo Git est ouvert sur le reste de la boite (donc tout le monde y a accès), pire encore s'il est dans le cloud sans protection.  
 
Un truc tout con: les notebook. Tu dump tes datas, sur ton serveur sécurisés ou tu fais tes analyses en local sur ton laptop (disque encrypte) et tout, puis tu pousses ton notebook sur le repo pour sauver ton travail. Sauf que le notebook contient maintenant les données, ou une partie. C'est pour ca que des outils comme nbstripout en pre-commit sont utile.
 
Apres, il est en Asie, c'est peut-être différent au niveau législatif.

Pas nécessairement. Il y a plusieurs façons de mettre en oeuvre de la sécurité à ce niveau-là, techniquement (range d'adresses autorisées ou non à accéder au repo) et/ou par des habilitations appropriées.

edit : De manière globale, il faut bien comprendre le contenu des règlementations que tu mentionnes. Aucune d'entre elles n'interdit quoi que ce soit, elle demande en revanche à ce que les accès aux données soient tracés et qu'il existe un mécanisme de déclaration, gestion et revue des habilitations.

Ca depend. Tu peux avoir des données ou pour y avoir accès, tu dois avoir signer toi-même un document, donc seul un petit nombre d’employés de la boite y a accès.

Mais tout ca n'a rien a voir avec le backend qui est utilisé  
Ce qui compte c'est juste ou les données sont stockées et qui a accès
 
Quand je parlais de git, c'est évident que je parlais pas de ton profil github public

Non mais encore une fois, aucune loi ne dit explicitement qui a le droit ou non d'accéder à telle ou telle donnée.
 
Elles demandent en revanche qu'il existe des procédures (telles que la signature du document dont tu parles) et plus globalement une gouvernance avec des rôles et responsabilités autour de l'accès à la donnée.

 
Hésite pas si t'as des questions auxquelles mes posts précédents n'ont pas répondu

La certification HDS ça déconne pas c'est plus que ça hein

Quand tu vois les pruneaux que se prennent certaines compagnies parce qu’il a été considéré que les mesures mises en place pour protéger de la donnée personnelle étaient insuffisantes, j’imagine même pas ce qu’ils se passe si on met pas des mesures suffisantes pour de la donnée personnelle sensible.  

Ah oui bien sur. Mais ce que je voulais dire, c'est qu'il faut faire attention a ce que les données ne traînent pas n'importe et bien containériser entre les différents groupes d'utilisateurs.

Tiens un petit sondage de la data science.
 
C'est quoi votre framework pour analyser un volume de données impossible à charger dans la RAM ?  
 
Je me rends compte que je connais peu de data scientist qui traitent des gros volumes de données.

 Augmenter la ram  

 
Choisir une machine virtuelle avec plus de RAM
 
T'as un volume de combien?

C'était un vrai sondage naif pour voir les réponses, perso j'utilise Spark et je vais à une vitesse interdimensionnelle
 
@fusion_sadam: Une solution de bourrin mais qui peut marcher

Jcroyais que le big data ça avait été débunké depuis longtemps ?
 
Tu lis les données sur le disque par batch

Je trouve la question mal posée. Pourquoi t'interroger sur la capacité d'un framework à charger de gros volumes de données en RAM ? Si ton postulat de départ est que la seule façon d'obtenir des performances satisfaisantes est d'utiliser un moteur in-memory, tu fais fausse route. Les SGBD relationnels en sont un bon contre-exemple. Autre exemple, la boîte pour laquelle je bosse développe un framework qui n'est pas in-memory mais qui laisse Spark loin derrière en termes de performances.

En matière de frameworks in-memory distribués (puisque cela semble être ta question), je ne vois que Spark en open source (qui est le standard de facto) et MATLAB ou SAS Viya en propriétaire.

Sur le fond, je suis toutefois assez circonspect face au besoin réel de ce genre de framework. À une époque où l'on peut disposer facilement et à moindre coût de 64 coeurs physiques et de 1 To de mémoire vive dans une station de travail et les exploiter à partir d'un langage aussi facile d'accès que Python (qui n'est pas moins performant que Spark s'il est bien utilisé), quel intérêt y a-t-il encore à utiliser des moteurs distribués tels que Spark et consorts ? L'utilisation de solutions en cluster induit une charge de maintenance considérable, mieux vaut s'en passer s'il existe d'autres solutions techniques à mon sens. En règle générale, on fait du scale-up avant de faire du scale-out.

Cette approche s'appelle MapReduce et a prouvé son inefficacité.

Je veux bien entendre qu'elle soit valide dans des cas d'usage basiques en data science tel que le feature engineering mais de manière générale, il est désormais établi que cette démarche est la mauvaise.

J'ai dit framework mais en effet j'aurais pu demander juste quelle méthode, que cela implique ou pas un framework spécifique, comme le fait de monter la RAM.

C'était vraiment purement naif et évidemment je sais que Spark n'est pas le meilleur truc sur le marché.

Pour ta question sur pourquoi on a besoin de ce genre de framework ? Bah je dirais que malheuresement à cause des spécificités de ton entreprise. Perso je suis dans une multi nationale absolument gigantesque, y'a pas la flexibilité pour demander à Roger de l'IT que j'ai besoin d'une station avec plus de RAM ou de coeurs, et meme si par chance j'arrivais à l'avoir, y'a les questions de sécurité après, le fait de pas pouvoir avoir de données sur ton poste de travail par exemple ...

Enfin pour répondre à la maintenance en cluster, des solutions comme Azure sont excellentes et j'en ai beaucoup parlé ici mais Databricks est une petite perle dans le contexte dans lequel je suis, je dis pas que c'est le meilleur mais en 2 clics je lance n'importe quel cluster et j'peux travailler sur mes 50to de data sans soucis.

Et pour conclure, mon but dans mon sondage est pas de dire quelle est la meilleure solution ou autres, c'était à pur but informatif et avoir des feedbacks plus personnels que des posts sur des blogs de data science.

Tu ne peux avoir un Docker bien dimensionné pour avoir accès a votre cluster et vos donnes ?

 
Si c'est une grosse boîte qui n'a pas d'activités majeures dans le domaine, ça peut être une vraie galère pour mettre en place la moindre exception aux standards de l'entreprise

Je parlais de station de travail mais j'aurais aussi pu parler de serveur.
 
Si c'est facile de provisionner des clusters dans le cloud, ça l'est encore plus de provisionner une seule VM.

 
Oulalala, tu es un fou
 
Comme l'a dit trefledepique_w, les grosses boites anciennes peuvent être très immatures à ce niveau.
 
Moi perso j'ai accepté car y'a justement tout à faire et j'suis dans les échanges pour monter un vrai éco-système data donc c'est cool mais je peux comprendre qu'on puisse détester et arriver dans un environnement mature et flexible.

 
Un serveur c'est encore pire pour ces grosses boites, j'ai déjà demandé les deux, j'ai eu l'impression de traverser les 7 cercles de l'enfer.

 
Voilà, j'imagine qu'il y a quelques managers de 1ère et 2ième ligne qui ont envie de développer un quelconque système data/ML mais y a rien de prévu pour.
 
Pour ceux qui se rendent pas compte de l'ampleur: parfois c'est galère ne serait-ce que pour récupérer les droits d'admin sur son PC pour pouvoir installer un logiciel (au hasard, conda) en dehors du catalogue officiel de la boîte
 
Tu pourrais par contre voir si y a pas moyen de mettre en place un groupe de ressources ou un abo Azure. L'IT des grosses boîtes est se basent souvent sur Microsoft et souvent t'as des collègues IT qui savent bien administrer Azure et qui peuvent te mettre à disposition quelque chose d'isolé qui ne demande pas de revoir toutes les règles restrictives

Non mais oh, si vous croyez que je ne suis jamais passé par là...
 
J'ai été dans le département data nouvellement créé d'une grande banque. J'ai eu droit aux mêmes objections et je me suis farci le même genre de problématique. J'ai passé des heures en réunion avec l'IT - qui par chance m'aimait bien parce que j'avais un niveau de compréhension de ses enjeux plus élevé que la moyenne.
 
Morceaux choisis :
 

• On a débuté avec les mêmes laptops que le reste de la boîte. 2 cores, 4 Go de RAM, zéro accès à un quelconque environnement de travail.
• Au bout de 3 mois, je suis parvenu à obtenir des stations de travail HP pour l'équipe. 4 cores, 32 Go de RAM et un bon SSD de 512 Go, ça nous a changé la vie. Surtout, le second effet kiss cool est qu'on a reçu des écrans 27" avec les stations en lieu et place du traditionnel 22" pourri dont tout le monde était équipé. Tout le monde nous jalousait rien que pour l'écran
• Le délai de livraison moyen d'une VM était de 2 à 3 mois. J'ai mis un peu plus de 6 mois à faire déployer un environnement de travail et à la rendre disponible aux équipes de plusieurs BU. J'ai passé des heures à négocier avec les équipes sécurité et à tester des ouvertures de flux pour que chacun puisse accéder à l'environnement.
• On n'a jamais eu les droits admins sur nos bécanes. Par chance, j'avais accès à des serveurs pour lesquels je disposais de comptes de service. Du coup, pour récupérer MATLAB sur nos bécanes, je l'installais sur un de ces serveurs et ensuite on faisait un copier-coller du répertoire d'installation
• La plus grosse capacité mémoire dont on pouvait disposer sur un serveur était de 64 Go, à une époque où 256 Go ne coûtaient presque plus rien. Dataiku sur une VM de 64 Go, ça a été un enfer... À l'époque, Dataiku ne savait exécuter les jobs Python que localement. Du coup, le moindre "data scientist" qui faisait n'importe quoi (comme par exemple charger tout un fichier CSV dans un dataframe pandas sans optimiser les types) faisait exploser la mémoire de tout le serveur.
• Les environnements Big Data, j'en parle même pas tellement c'était la cata. On ne les a jamais utilisés au final, de toute façon c'était beaucoup trop cher. On nous facturait 16 k€ par an et par nœud, avec un minimum de 3 nœuds. Assez rapidement, on a appris à faire sans
• Tout ça à l'époque de Spark 1.6 qui était notoirement instable. Tous les 6 mois, quand l'IT mettait à jour son environnement, toutes ses applications basées sur Spark étaient en carafe

J'ai failli m'inquiéter    

T'inquiète, y avait Python et R aussi
 
Pour faire joujou 5 minutes, c'était marrant mais personne ne voulait accepter ce fait pourtant simple : l'IT avait déjà refusé à de maintes reprises et refuserait encore et toujours d'installer des softs tels que Python et R sur leurs environnements de production. Quand ils voyaient arriver dans leur boîte mail une demande pour Python 3.6 + 50 à 80 bibliothèques additionnelles, le mail partait directement dans la corbeille. À tort ou à raison, chacun se fera une religion sur le sujet, mais il fallait faire avec.
 
Depuis ce jour, j'ai compris toute la pertinence du logiciel propriétaire dans les grosses boîtes qui ont une culture techno proche de zéro. L'argent n'est pas le problème, du moins pas pour les montants dont il est question avec ce genre de logiciel. Le problème, c'est la capacité à maintenir une solution en conditions opérationnelles et ça, c'est infiniment plus simple lorsque le soft a une procédure d'installation bien documentée et un support technique sur qui on peut s'appuyer.
 
Raison pour laquelle SAS est extrêmement bien implanté dans les banques, et pourtant il s'agit pour chacune d'entre elles d'un contrat à plusieurs millions par an...

Et ne venez pas me parler de docker.
 
docker dans ces boîtes-là, c'est de la science-fiction.

Et le département comm' qui va afficher fièrement quelques semaines plus tard que "eugneuneu on fait de la big data et de l'intelligence artificielle dans le cadre de notre programme de digitalisation   "

C'est tellement ça

Pourtant ça arrive même dans les banques para étatiques

Je partage une partie de ton expérience des équipes IT de grosses boîtes (même si WTF les mini clusters Spark dédiés alors qu'en mutualisant un minimum tout le monde y gagnerait    ).

Quand j'étais en banque on se débrouillait pour avoir un contact privilégié par équipe difficile (ça se décide entre N+2 et ça redescend ensuite dans les équipes) pour gagner en réactivité. C'était pas toujours parfait mais nos demandes ne finissaient plus en "closed - unresolved" et si on serrait les fesses pendant les congés du SPOC (single point of contact   ) le reste du temps on avait la réactivité et les actions qui allaient bien.

Ça demande aussi un peu de sponsor des métiers (et donc d'être bien vu d'eux) pour évacuer les risques de bras de fer avec les équipes IT ou la remise en cause des services "premium" quand la relation est apaisée.

Chez un célèbre gazier ils avaient carrément résolu la question à coups d'agilité et de devops : une équipe IT suit les réunions projets / nouveaux besoins très en amont et du coup il peut amener les bonnes pratiques et faire les demandes de changements nécessaires bien en amont. C'était hyper efficace avec en plus un coach agile dédié pour suivre ces réunions et remettre de la méthode et de la bienveillance quand c'était nécessaire