Retour sur PyData Paris 2016

Article co-écrit  avec Pauline Olivier.

Not so big data

Ce fut l’une des questions récurrentes de la conférence : si mon jeu de données ne tient pas sur une machine, si mon algorithme consomme trop de CPU, que faire ? Comment distribuer des calculs avec Scikit-learn ? Bref, comment faire du big data ? Et en a-t-on vraiment besoin ?

Il a d’abord été souligné que la plupart des jeux de données tiennent sur une seule machine, et qu’une installation locale de Scikit-learn pourra emmener le datascientist assez loin.

Mais certaines situations (algorithmes gourmand en CPU, recherche d’hyperparamètres) peuvent rendre les choses compliquées en local, d’où la nécessité de distribuer son traitement.

Olivier Grisel, figure du monde Python, a présenté dans son excellente keynote plusieurs pistes à creuser en fonction du problème :

• Tout d’abord, une démo de dask/distributed pour réaliser une recherche d’hyperparamètres sur Google Cloud Engine : un même algorithme va être exécuté avec n jeux de paramètres différents, sur plusieurs machines distantes, pour ne sélectionner que le meilleur résultat, et comparer l’importance de certains paramètres dans le modèle. Extrêmement intéressant, même si Dask semble encore un peu jeune.

• Ensuite, seront mentionnés quelques frameworks encore un peu confidentiels comme Blaze ou Ibis.
• PySpark, l’implémentation Python de Spark, est bien évidemment à considérer : même si PySpark est plus lent et plus complexe à debugger que ses équivalents Java / Scala, il fournit un ensemble complet d’algorithmes facilement distribuables. Cela nécessite bien sûr l’installation d’un cluster Spark, et donc un surcroît de travail, mais cela semble à mon sens la piste la plus pertinente pour des pythonistes voulant travailler sur de gros volumes de données.

Les principaux point à garder en mémoire sont :

• un environnement de datascience doit être le plus simple possible : installer un cluster Spark n’est pas à la portée de tous.
• l’environnement doit permettre une certaine rapidité d’exécution, afin que le datascientist puisse interagir de la manière la plus fluide possible avec les données.
• la disponibilité de quantités de RAM de plus en plus importantes sur les machines de développement (ou dans le cloud) doit permettre dans un grand nombre de cas au datascientist de travailler en local.

La keynote, dans sa version berlinoise, est visible ci-dessous.

Visualisation des données

Voilà un domaine où le pythoniste a (un peu trop) le choix. Si Matplotlib vient par défaut avec tout notebook, les résultats obtenus sont parfois un peu ternes, et il suffit d’un pip install pour accéder à des librairies tout aussi puissantes, et aux résultats plus convaincants.

Seaborn est probablement la solution la plus simple pour pimper ses visualisations facilement : basé sur Matplotlib, il partage la même base de rendu graphique, donc le même vocabulaire, mais propose des rendus graphiques plus léchés. C’est à mon sens la première alternative à tester.

Si l’on veut sortir du monde des représentations statiques, on pourra basculer sur un des nombreux frameworks interactifs, au premier rang desquels on trouve Bokeh.

Réservés aux navigateurs récents, Bokeh permet à l’utilisateur, sur une page web ou un notebook, de filtrer les données,  zoomer, ou sélectionner des plages de valeurs. Très puissant sur des pages web, on lui préferera néanmoins Seaborn pour de la production de documentation ou de rapports.

Aux cotés de ces frameworks polyvalents qui vont bien au-delà du triptyque camembert / histogramme / line chart (voir leurs galeries respectives : galerie Seaborn et galerie Bokeh), on trouvera aussi des petites librairies spécialisées dans une tâche particulière :

• Networkx va permettre de manipuler, parcourir et représenter des graphs.
• Ete3 se concentre sur différents types d’arborescence.
• Folium va embarquer dans des notebooks des cartes interactives basées sur Leaflet.
• Missingno offre des représentations compactes des dataframes pandas pour évaluer leurs données manquantes champ par champ, et en bonus analyse les corrélations entre l’absence de certains champs. On saluera au passage l’étymologie derrière le nom du projet.

Le choix ne manque donc pas, mais chaque librairie vient avec ses qualités, ses contraintes, son taux d’activité sur GitHub, son adéquation à tel ou tel support, ou sa capacité à traiter de gros volumes de données : le choix d’une librairie particulière dépendra donc beaucoup du contexte.

Ces frameworks, et bien d’autres, ont été présentés par Xavier Dupré dans sa conférence “10 plotting libraries”. On pourra également lire en complément “10 Useful Python Data Visualization Libraries”.

Traitement automatique du langage

Plusieurs conférences abordaient le Natural Language Processing, essentiellement sur des problématiques de classification : prédiction du succès attendu d’un article, ou de son type de contenu. Sans surprise, c’est NLTK que l’on retrouve bien souvent pour le prétraitement des jeux de données (stemming, ngramming), combiné avec Scikit-learn coté apprentissage.

On a vu aussi apparaître Gensim, projet plus confidentiel que NLTK, mais qui porte actuellement certaines des avancées majeures du monde NLP en Python : c’est là que l’on trouvera des implémentations de word2vec ou doc2vec, les algorithmes les plus récents de topic modeling et de représentation sémantique de texte.

Et le grand absent est…

PyData étant avant tout organisé par les commiters Scikit-learn, c’est naturellement cette librairie qui fut mise en avant pendant ces deux jours (le Scikit-learn day était par ailleurs organisé en parallèle).

J’ai néanmoins été étonné par le peu de références faites au deep learning lors des présentations. On a bien vu quelques références à Tensorflow ou Keras, Scikit-learn lui-même propose depuis peu une implémentation de Multi-Layer Perceptron, mais tout cela était extrêmement marginal au regard de l’usage des algorithmes plus “traditionnels”.  Cela est d’autant plus surprenant que la plupart des librairies en pointe sur le deep learning (Theano, Caffe, Tensorflow) sont issues du monde Python.

Quelques raisons à celà :

• Le deep learning est un ensemble de méthodes encore assez jeunes, assez complexes, avec un ticket d’entrée assez élevé. Si ces méthodes sont accessibles à de grosses sociétés disposant d’un plateau de doctorants, il est beaucoup plus compliqué pour des startups ou des petits labos d’investir du temps sur le sujet.
• Le deep learning requiert un hardware très particulier, qu’on ne va pas forcément trouver sur des postes de développeur / chercheur. S’offrir un ensemble de GPU représente un investissement qui là aussi n’est pas accessible à tous.
• Entraîner un modèle pouvant être assez lent, l’usage de notebooks devient plus complexe, et les interactions entre le datascientist et son modèle se réduisent.
• Si les algorithmes de deep learning ont révolutionné la reconnaissance d’image ou de langage, des algorithmes plus classiques sont déjà très performants sur d’autres problématiques. Faire évoluer radicalement son environnement technique et ses algorithmes pour gagner 2% de précision après plusieurs semaines de travail n’est pas forcément pertinent pour tout le monde.

Tous ces points devraient fortement évoluer dans les mois / années à venir, et le ticket d’entrée vers ces technologies va bien évidemment s’abaisser : il faut s’attendre à voir Tensorflow et Keras s’inviter de manière beaucoup plus imposante dans les conférences data à venir.

Pour conclure

Ces deux jours ont été riches en enseignements sur la communauté Python, et le panel d’invités a permis par sa diversité (startupers, éditeurs, universitaires…) d’aborder un grand nombre de sujets. Ce fut l’occasion de voir à quel point la versatilité du langage permet de couvrir la totalité des aspects d’un projet data, depuis l’acquisition de données jusqu’à leur exposition via API, en passant par leur analyse.

Par ailleurs, la communauté Python veille à maintenir une documentation de qualité sur les projets phares tels que Numpy, Scipy, Pandas et Scikit-learn. Cette qualité, couplée à la simplicité de prise en main du langage, et à de nombreuses ressources telles que Kaggle ou Coursera, permet à des profils extrêmement divers de se lancer sur le langage et dans la datascience en général.

On ne peut que recommander aux organisateurs de poursuivre cette formule l’an prochain, avec peut-être une ouverture plus grande aux autres plateformes du monde Python.