Data science – DevOps Part 1

N.B Cet article ( Data Science DevOps ) sera découpé en trois parties pour faciliter la lecture. La première ( Data Science DevOps Partie 1 ) fera une introduction et une présentation du problème, une deuxième partie ( Data Science DevOps Partie 2 ) va couvrir Git et DVC et une dernière ( Data Science DevOps Partie 3 ) qui va présenter MLflow et la conclusion.

En tant que data scientist, nous travaillons constamment sur des projets de data science. hummm!! ok pas tout le temps. Notre travail consiste donc à transformer les données en or massif, voir même en diamant quand la chance nous sourit. Sauf que voilà avant d’arriver au stade où nous recevons les lauriers de nos durs labeurs, il faut fouiller, voire tourner en rond dans des mines plutôt sauvages, sombres, glissantes et vastes. Sans les instruments adéquats, y survivre est juste une mission quasi impossible. Il y a tellement de trous à creuser, de sable à tamiser, de coins et recoins à explorer et surtout à se remémorer pour ne pas réinventer la roue, mais aussi pouvoir tirer des leçons de ses erreurs passées. Tout cela nous amène à chercher des astuces pour une meilleure organisation dans nos fouilles, en prenant en compte cette fois ci non seulement le code mais aussi les données ainsi que les modèles. Après tout nous sommes des data scientist pas des “mineurs”.

Voyons d’abord ce que nous, les des data scientists manipulons à longueur de journée(Figure 1) :  

  • Les données : la pierre angulaire, la matière première, l’essence même de notre existence (vas y mollo);
  • Le code : le chariot qui porte les données, les transforme en cours de route pour atteindre la terre promise;
  • Les modèles : les fruits tant attendus de la terre promise, que les profanes considèrent comme de la magie noire ou juste comme un chiffon, après tout, ca dépend de la qualité du modèle, donc de nous.
  • La configuration  : Les petites touches subtiles qui permettent d’atteindre des sommets jusque là insoupçonnées.
Gestion de Projet Data Science
Les “quatre” composants de la data science

Fig.1 : Les “quatres” composants de la data science

La question à un million est donc la suivante : 

Comment orchestrer ces quatres composants pour avoir une symphonie digne de Beethoven, encore mieux voyager dans le temps à travers cette symphonie ?

Pour répondre à cette question il serait peut être plus judicieux de faire un petit voyage lointain dans l’histoire pour rencontrer un certain Linus Torvalds. Bon, peut être pas si lointain pour les historiens, mais lointain pour nous informaticiens. Pour ceux qui ne connaissent pas Linus, c’est Linux mais en version humaine ( et pour ceux qui ne connaissent pas Linux => Que la force soit avec vous ) . Il est aussi le créateur de Git, un outil de gestion de code source très utilisé par nos amis développeurs et par nous aussi, qui permet de voyager dans l’histoire de nos fichiers contenant les codes sources.

Assez parlé d’histoire, maintenant, on va aller dans un monde parallèle au nôtre(pas si parallèle que ça, après tout le code nous lie) pour essayer d’apprendre de leurs réussites mais aussi de leur échecs – eh oui, y a toujours des mauvaises expériences qui trainent -.
Les ingénieurs logiciels ont besoin de versionner leur travail, celui ci est composé “seulement” de code source, par conséquent ils ont seulement besoin de versionner leur code, ce qui rend quand même les choses un poil(ou deux) plus simple pour eux. Ils peuvent donc utiliser Git pour avoir une symphonie qui marche à merveille.
Devinez qui ne dispose pas de cette chance? … Allez un peu d’efforts… Haaa ok c’est nous les data scientists. Eh oui nous sommes les gardiens des trois temples(i.e donnees, code et modèles), et comme le dit l’adage “Un grand pouvoir s’accompagne de grandes responsabilités”.

Le problème

Prenons l’exemple d’une entreprise IT (Baamtu) avec une équipe de data scientists (dont je fais partie), en l’occurrence Datamation qui travaille sur des projets de data science(quel scoop!!!).

Les membres de cette équipe travaillent forcément sur les trois majeurs composants de tout projet data science. Nous manipulons donc du code, des données mais aussi des modèles, issus de la combinaison des deux premiers composants.

Par ailleurs, un nouveau projet pour la reconnaissance vocale de la langue WOLOF ( Youpi, il est temps de s’amuser et rendre nos compatriotes fiers de leur langue locale) vient juste d’être lancé, et nous avons eu la bonne idée d’utiliser Git pour versionner le projet. Après plusieurs itérations, le projet a bien avancé, notre modèle commence à pouvoir transcrire les audios wolof, mais voilà après la dernière itération, nous nous sommes rendus compte que le modèle précédent est meilleur que celui actuel, nous voulons donc naturellement revenir en arrière.

Heureusement Git est là pour nous sauver la mise… ou pas. En effet, en utilisant Git dans notre projet, nous avions choisi d’ignorer les modèles car ayant une taille trop importante pour être envoyé au dépôt distant(Git n’est pas vraiment fait pour des fichiers volumineux). 

Panique total au sein l’équipe, pas si vite les gars. Calmaté, nous disposons toujours du code qui a été utilisé pour produire l’ancien modèle, un git checkout vers cette branche et le tour est joué :).

Après un temps fou à attendre que l’apprentissage se termine, le modèle obtenu n’a pas du tout les mêmes performances que celles attendues. En effet, les données aussi avaient été modifiées en cours de route par des scripts de transformations. 

Devinez ce que nous n’avons pas non plus versionné? Les données issues des transformations intermédiaires bien sûr, et ce pour la même raison que les modèles ne l’ont pas été. La pression augmente (sueurs dans la salle), le deadline approche et on va sûrement pas déployer le nouveau modèle, qui est moins bon que l’ancien.

Comme à l’impossible nul n’est tenu(même pour les magiciens de la donnée), on va donc récupérer le jeu de donnée d’origines sans aucune transformation, passer par toutes les étapes de la création du modèle (cela suppose, bien sûr, qu’une personne dans l’équipe se souvient exactement de toutes les étapes effectuées mais aussi de leur ordre) , du nettoyage du jeu de données à construction du modèle final.

 Je vous laisse imaginer le temps de calcul qu’il a fallu pour refaire tous ces traitements et aussi bye bye le respect du deadline et de notre crédibilité au sein de l’entreprise. Tout ça parce que dans le versionning avec Git, aucune liaison n’a été faite entre les données, le code et les modèles produits.

Après une telle expérience, inutile de dire que la revivre n’est pas une option, il est alors temps de faire une pause et de voir les différentes solutions qui existent pour remédier à ce problème de versionning dans le monde de la data science.

Entre autres, on peut citer encore d’autres problèmes de versionning avec le data science tels que : 

  • le partage de données entre data scientists
  • le déploiement de modèle
  • Ne pas recréer des étapes de la création d’un modèle si le code et les données n’ont pas changés pour cette étape
  • Création statique et dynamique de pipeline 
  • Comparaison aisée des métriques issues de différentes itérations
  • …………………..

Les “SOLUTIONS”

Plusieurs outils existent dans le but d’essayer de résoudre les problèmes évoqués plus haut et nous faciliter la vie. Certains de ces outils sont open source et d’autres sont payantes, chacun apportant des solutions à différents problèmes(souvent les mêmes). 

Dans la suite, on présentera deux solutions open sources (DVC et MLflow), accompagnées de Git, qui, combinées permettent de résoudre la plupart des problèmes de versionning que nous data scientists rencontrons au quotidien.

Nous allons utiliser Git pour gérer les versions de notre code et des fichiers de configurations, DVC pour gérer les données, la gestion des pipelines et les modèles, MLflow sera utilisé pour le déploiement et la comparaison des métriques des différentes expérimentations.

10 thoughts on “Data science – DevOps Part 1

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *