Dernière mise à jour le 3 mars 2022

Article sponsorisé

Moi, un scientifique des données, et des cahiers Jupyter. Eh bien, notre relation a commencé à l’époque où j’ai commencé à apprendre Python. Les cahiers Jupyter étaient mon refuge lorsque je voulais m’assurer que mon code fonctionnait. Aujourd’hui, j’enseigne le codage et je réalise plusieurs projets de science des données et pourtant, les cahiers sont les meilleurs outils pour le codage et l’expérimentation interactifs. Malheureusement, lorsque vous essayez d’utiliser des blocs-notes dans des projets de science des données, les choses peuvent rapidement devenir incontrôlables. À la suite de l’expérimentation, des cahiers monolithiques émergent, difficiles à entretenir et à modifier. Et oui, c’est très chronophage de travailler deux fois : expérimenter puis transformer votre code en scripts Python. Sans oublier qu’il est pénible de tester un tel code et que le contrôle de version est également un problème. C’est le point où vous devez penser, il doit y avoir une meilleure façon ! Heureusement, la réponse n’est pas d’éviter mes cahiers Jupyter bien-aimés.

Suivez-moi et découvrez quelques idées géniales de Eduardo Blancas et son projet, appelé Plombier sur la façon de réaliser de meilleurs projets de science des données et sur la façon d’utiliser et de créer des blocs-notes Jupyter à bon escient, même en production.

Jupyter est un outil Web gratuit et open-source, où l’on peut écrire du code dans des cellules, qui est ensuite envoyé au “noyau” back-end et vous obtenez immédiatement les résultats. Un de mes collègues dit que c’est comme une application de messagerie à l’ancienne avec du code. La popularité du bloc-notes Jupyter a explosé au cours des dernières années, grâce à la possibilité de combiner le code logiciel, la sortie de calcul, le texte explicatif et les ressources multimédias dans un seul document. [1]. Entre autres choses, les cahiers pourraient être utilisés pour le calcul scientifique, l’exploration de données, les tutoriels et les manuels interactifs. De plus, les ordinateurs portables peuvent parler des dizaines de langues (il tire son nom de Julia, Python et R). Une analyse du site de partage de code GitHub comptait plus de 7,5 millions de notebooks Jupyter publics en janvier 2022. En tant que data scientist, j’utilise principalement les notebooks Jupyter pour le data wrangling avec Python et R, et j’enseigne également aux étudiants les bases de Python via les notebooks Jupyter.

Malgré leur popularité, de nombreux data scientists (dont moi) rencontrent des problèmes avec les notebooks Jupyter [2]. Je ne pourrais pas mieux résumer, alors je cite les paroles de Joël Grusqui a expliqué certains problèmes avec les ordinateurs portables [1].

« J’ai vu des programmeurs être frustrés lorsque les ordinateurs portables ne se comportent pas comme prévu, généralement parce qu’ils exécutent par inadvertance des cellules de code dans le désordre. Les notebooks Jupyter encouragent également les mauvaises pratiques de codage en rendant difficile l’organisation logique du code, le diviser en modules réutilisables et développer des tests pour s’assurer que le code fonctionne correctement.

Les ordinateurs portables sont difficiles à déboguer et à tester, et j’ai également passé beaucoup de temps dans ma carrière à refactoriser le code dans certains scripts, des fonctions qui peuvent être utilisées en production. Il y a aussi des problèmes avec le contrôle de version, car les notebooks sont des fichiers JSON et git génère une comparaison illisible entre les versions, ce qui rend difficile le suivi des modifications apportées. [2]. Ici vous pouvez trouver un résumé plus détaillé et des explications sur les problèmes des notebooks Jupyter.

Les problèmes énumérés ci-dessus auraient pu suffire à m’amener à trouver Pmétier à tisser, mais j’ai découvert ce projet génial grâce à ma quête de modularisation. Ce dont j’avais besoin était un outil, pour créer et exécuter facilement des tâches ou des extraits de code dans l’ordre défini sans demander de l’aide à mes collègues ingénieurs de données. Ce dont j’avais besoin s’appelle un pipeline. Avec un pipeline, on peut diviser les tâches pour des composants plus petits et les automatiser. Les pipelines peuvent prendre de nombreuses formes et tailles. On peut créer des pipelines même dans sklearn et pandas [3].

Plombier est un projet open-source initié par Eduardo Blancas pour créer des pipelines Python. J’ai trouvé que c’était un outil facile à utiliser, avec lequel je pouvais rapidement définir mes tâches avec ordre d’exécution et décomposer mon analyse en parties modulaires. Ploomer est livré avec plusieurs exemples de projets où vous pouvez trouver d’excellents exemples de l’outil. Je partage également mes expériences avec Ploomber dans ce dépôt. Ce que j’aime particulièrement chez Ploomber, c’est Blog et le communauté à bout de souffleoù je pourrais demander n’importe quoi sur ce projet.

D’accord, j’ai trouvé un excellent projet pour modulariser mes projets de science des données, mais comment cela m’a-t-il aidé dans ma lutte constante avec les ordinateurs portables ?

Eh bien, Ploomber est livré avec Jupytext, un package qui nous permet d’enregistrer des blocs-notes en tant que fichiers py, mais d’interagir avec eux en tant que blocs-notes. Le problème de contrôle de version a été résolu.

Vient ensuite le problème de la refactorisation et de la modularisation. Il n’est pas nécessaire de se débarrasser des cahiers car Ploomber peut gérer les cahiers comme des unités de pipeline. De cette façon, je n’ai plus qu’à nettoyer mes cahiers et à gagner du temps pour les convertir en une structure et une architecture de code complètement différentes. Il est également possible de mélanger des notebooks et des scripts dans les tâches du pipeline. Il y a un série d’articles de blog sur la façon de décomposer les cahiers monolithiques en parties plus petites. Ce que je dis toujours aux étudiants et qu’Eduardo suggère également, c’est d’écrire votre cahier de manière à pouvoir toujours redémarrer votre noyau et exécuter tout votre code de haut en bas. Parfois, l’exécution d’un bloc-notes avec beaucoup de données prend beaucoup de temps, puis définissez simplement un exemple de paramètre pour obtenir un sous-ensemble afin de tester l’exécution de votre code.

Outre les astuces de modularisation, un autre point très important que j’ai lu sur Le blog de Plombier et m’appliquer au travail consiste à verrouiller les dépendances du projet et à l’empaqueter pour pouvoir importer du code à partir d’autres cahiers. J’ai rencontré des problèmes de version de package dans quelques projets jusqu’à présent, je peux donc vous assurer que cela peut vous épargner quelques heures.

Un projet de plusieurs cahiers plus courts et plus propres au lieu de quelques cahiers monolithiques facilite la reproduction, la compréhension et la modification du code. En outre, il permet également de concevoir un stratégie de test pour tester les codes ML. Plusieurs articles sur les raisons pour lesquelles les projets d’apprentissage automatique échouent, mentionnent la difficulté de code de mise à jour et les problèmes de maintenance chronophages. Avec un code plus court et plus propre, des dépendances verrouillées et un contrôle de version approprié, la maintenance et la collaboration deviennent plus faciles et plus rapides.

Les idées ci-dessus ne sont que quelques réflexions principales que j’ai trouvées utiles sur le blog de Ploomber. Depuis lors, j’ai eu une boîte à outils sur la façon de diviser les cahiers en pièces modulaires et comment les utiliser et les convertir en un pipeline dans des projets plus petits. J’aime partager et enseigner des idées sur la façon de faire de meilleurs cahiers et coder, et ces pratiques de codage valent la peine d’être envisagées.

Si vous êtes intéressé par plus de détails sur Ploomber et sur la façon de travailler plus efficacement avec des ordinateurs portables, assurez-vous de consulter Eduardo Blancas parler de son projet au Conférence Renforcer l’IA ce mois de mars ! Qui pourrait nous en dire plus que le PDG et co-fondateur de Ploomber lui-même ?

Les références

[1] Jeffrey M. Perkel (2018). Pourquoi Jupyter est le cahier de calcul de choix des data scientists. Nature 563, 145-146.

[2] Eduardo Blancas (2021). Pourquoi (et comment) mettre des notebooks en production. Blog de Ploomer.io.

[3] Anouk Dutrée (2021). Pipelines de données : quoi, pourquoi et lesquels. Blog Vers la science des données.