Mise en production des projets de data science

Romain Avouac, Lino Galiana

Introduction

Disclaimer

Contexte

  • Qui sommes-nous ?
    • des data scientists de l’Insee
    • frustrés par l’approche souvent purement technique de la data science
    • convaincus que les bonnes pratiques valent à être enseignées
  • ,

La notion de mise en production

  • Mettre en production : faire vivre une application dans l’espace de ses utilisateurs
    • Notion simple mais mise en oeuvre compliquée !
  • Dépasser le stade de l’expérimentation
    • Bonnes pratiques de développement
    • Techniques informatiques d’industrialisation
  • Enjeu : pouvoir jouer le rôle d’interface entre métier et équipes techniques

La notion de bonnes pratiques

  • Origine : communauté des développeurs logiciels

  • Constats :

    • le “code est plus souvent lu qu’écrit” (Guido Van Rossum)
    • la maintenance d’un code est très coûteuse

  • Conséquence : un ensemble de règles informelles, conventionnellement acceptées comme produisant des logiciels fiables, évolutifs et maintenables

Pourquoi s’intéresser aux bonnes pratiques ?


L’activité du datascientist tend à se rapprocher de celle du développeur :

  • projets intenses en code

  • projets collaboratifs et de grande envergure

  • complexification des données et des infrastructures

  • déploiement d’applications pour valoriser les analyses

Contenu du cours

  • Voir le code comme un outil de communication

    • Contrôle de version avec Git
    • Qualité du code
    • Structure des projets

  • Travail collaboratif avec Git et GitHub

  • Maximiser la portabilité

  • Déployer et valoriser un projet de data science

Modalités pédagogiques

  • Apprentissage par la pratique
  • Langage : Python
    • Langage dominant dans le monde de la donnée
    • Les principes présentés sont agnostiques au langage
  • Environnement d’exécution : SSP Cloud
    • Environnement de développement normalisé
    • Véritable environnement de production
    • Acquisition des bonnes pratiques

Git : rappels

Pourquoi utiliser Git ?

Source

Concepts essentiels

Source

Bonnes pratiques

Que versionne-t-on ?

  • Essentiellement du code source
  • Pas d’outputs (fichiers .html, .pdf, modèles…)
  • Pas de données, d’informations locales ou sensibles

Note

Pour définir des règles qui évitent de committer tel ou tel fichier, on utilise un fichier nommé .gitignore.

Si on mélange du code et des éléments annexes (output, données…) dans un même dossier, il faut consacrer du temps à ce fichier.

Le site gitignore.io peut vous fournir des modèles.

N’hésitez pas à y ajouter des règles conservatrices (par exemple *.csv), comme cela est expliqué dans la documentation utilitR.

Bonnes pratiques

Format des commits

  • Fréquence
    • Aussi souvent que possible
    • Le lot de modifications doit “faire sens”
  • Messages
    • Courts et informatifs (comme un titre de mail)
    • Décrire le pourquoi plutôt que le comment dans le texte

En pratique

Application : initialisation du projet

Qualité du code

Enjeux

  • D’une vision utilitariste du code à une vision du code comme outil de communication

  • Favoriser la lisibilité et la maintenabilité

  • Faciliter la réutilisation

Principes généraux

  • Adopter les standards communautaires

  • Utiliser des fonctions

  • Auto-documenter son code

1️⃣ Standards communautaires

  • Python : PEP8, PEP 257

  • La cohérence intra-projet doit toujours primer

1️⃣ Standards communautaires - Outils

  • Linters : diagnostic de qualité du code
  • Formatters : application automatique des standards

Astuce

  • Exemples d’erreurs repérées par un linter :
    • lignes de code trop longues ou mal indentées, parenthèses non équilibrées, noms de fonctions mal construits…
  • Exemples d’erreurs non repérées par un linter :
    • fonctions mal utilisées, arguments mal spécifiés, structure du code incohérente, code insuffisamment documenté…

2️⃣ Utiliser des fonctions

Règle d’or

Il faut utiliser une fonction dès qu’on utilise une même portion de code plus de deux fois (don’t repeat yourself (DRY))

  • Limite les risques d’erreurs liés aux copier/coller
  • Rend le code plus lisible et plus compact
  • Un seul endroit du code à modifier lorsqu’on souhaite modifier le traitement
  • Facilite la réutilisation et la documentation du code !

Règles pour écrire des fonctions pertinentes

  • Une tâche = une fonction
  • Une tâche complexe = un enchaînement de fonctions réalisant chacune une tâche simple
  • Limiter l’utilisation de variables globales.

3️⃣ Documenter son code

  • Documenter le pourquoi plutôt que le comment

  • Privilégier l’auto-documentation via des nommages pertinents

Comment bien documenter un script ?

  • Minimum 🚦 : décrire ce que le code fait au début du script
  • Bien 👍 : commenter les parties “délicates” du code
  • Idéal 💪 : documenter ses fonctions avec des docstrings

Application : qualité du code

Structure des projets

Enjeux

  • Favoriser la lisibilité et la maintenabilité

  • Enjeux spécifiques à la data science

    • Expérimentation
    • Non-linéarité
    • Reproductibilité

Principes généraux

  • Notebooks : pour l’exploration et la communication

  • Pour l’industrialisation : adopter une structure modulaire

  • Adopter les standards communautaires

  • Documenter son projet

1️⃣ Notebooks

  • Avantages
    • Interactivité : idéal pour l’expérimentation
    • Communication : diffusion de résultats sous forme exécutable
  • Inconvénients
    • Reproductibilité limitée
    • Pas adaptés pour l’automatisation
    • Mal gérés par le contrôle de version

2️⃣ Favoriser une structure modulaire

  • Principe de séparation des données, du code et de la configuration

  • Adopter une structure de package

    • Contient des fonctions rangées dans des modules
    • Contient également de la documentation, des tests, des (méta-)données…

3️⃣ Adopter les standards communautaires

4️⃣ Documenter son projet

  • Favoriser l’auto-documentation via des nommages pertinents

  • Inclure un fichier README.md à la racine du projet

    • Carte d’identité et vitrine du projet
    • Présente le contexte et le fonctionnement du projet

Application : structure du projet

Portabilité

“It works… on my machine”

  • On a construit un projet lisible, structuré et versionné

  • Peut-on partager notre projet ?

    • En théorie, oui !
    • En pratique, c’est toujours plus compliqué…

L’enjeu de la portabilité

  • Un code ne vit jamais dans une bulle isolée, il contient en général de nombreuses adhérences

    • Des dépendances
    • Des librairies système

  • Un code est portable s’il peut être exécuté dans un environnement différent que celui du développement

  • Besoin de nouveaux outils

    • Les environnements virtuels
    • Les conteneurs

Environnements virtuels : introduction

  • Workflow classique du data scientist qui commencerait ses premiers projets
    • Installer une distribution de Python sur son poste
    • Développer un projet en installant les packages nécessaires
    • Passer au projet suivant et ainsi de suite
  • Quels problème peuvent se poser ?

Environnements virtuels : enjeux

  • Conflits de version : différents projets peuvent recquérir des versions différentes d’un même package

  • Version de Python fixe, celle de l’installation système

  • Reproductibilité limitée : difficile de dire quel projet nécessite quel package

  • Portabilité limitée : difficile de fixer dans un fichier les dépendances spécifiques à un projet

Environnements virtuels : fonctionnement

  • Dossier auto-suffisant qui contient :
    • Une installation de Python pour une version donnée ;
    • Des packages additionnels et qui est isolé des autres environnements existants
  • Développer dans un environnement virtuel vierge est une bonne pratique pour la reproductibilité

Environnements virtuels : implémentations

  • Différentes implémentations en Python
    • L’implémentation standard est venv
    • L’implémentation la plus populaire en data science est conda
  • conda est à la fois
    • Un package manager (comme pip)
    • Un gestionnaire d’environnements virtuels

Environnements virtuels : installation

  • conda est généralement installé dans le cadre de distributions
    • Miniconda
    • Anaconda
  • conda est un outil en ligne de commandes (CLI)

Environnements virtuels : limites

  • Les librairies système ne sont pas gérées

  • Difficile de gérer des projets multi-langages

  • Lourdeur de la phase d’installation à chaque changement d’environnement

  • Peu adaptés à un environnement de production

Application : environnements virtuels

Conteneurs : introduction

  • Idée : au lieu de distribuer la recette pour recréer la bonne machine, peut-on distribuer directement la bonne machine ?

  • On ne peut pas distribuer des machines physiques

  • Les machines virtuelles sont coûteuses et complexes à redistribuer

  • Les conteneurs offrent un bon compromis

Conteneurs vs. machines virtuelles

Source : docker.com

Conteneurs : implémentations

  • Plusieurs implémentations des conteneurs

  • Docker est largement prédominant

Docker : installation

  • Instructions selon le système d’exploitation

  • Environnement “bac à sable” : Play with Docker

  • Docker est un outil en ligne de commandes (CLI)

Docker : fonctionnement

Source : k21academy.com

Application : conteneurisation avec Docker

Vers la mise en production

Motivation

  • La massification et la diversification des données apportent de nombreux changements

    • Le Data Lake
    • Le Data Lab
    • De nouveaux profils : Data Scientist, Data Engineer, Data Architect

  • La majorité des projets de data science ne sont pas déployés

  • Besoin d’industrialisation qui nécessite de nouveaux outils

L’approche DevOps

  • Idée : unifier le développement (dev) et l’administration système (ops)

  • But : raccourcir le temps de développement en déployant en continu tout en maintenant la qualité

DevOps, DataOps, MLOps ?

  • Le DevOps n’intègre pas les spécificités liées à la data science

  • DataOps : déploiement et maintenance de pipelines de données

  • MLOps : déploiement et maintenance de modèles de Machine Learning

  • Les bonnes pratiques favorisent la collaboration et facilitent les déploiements

La mise en production

  • On a construit un projet de data science reproductible et conforme aux standards des bonnes pratiques

  • Pour valoriser le projet, il faut le déployer dans un environnement en lien avec les utilisateurs

    • Quel est le format adapté pour le valoriser ?
    • Quelle infrastructure de production ?
    • Comment automatiser le processus de déploiement ?

Format de valorisation

  • Critères à prendre en compte :
    • Quels sont les utilisateurs potentiels ?
    • Seulement de la mise à disposition, ou besoin d’interactivité ?
    • Spécificités ML : entraînement en batch ou online ?
    • Besoin de scalabilité ?
  • Formats usuels : API, application web, dashboard, site internet, rapport automatisé…

Exposer un modèle via une API REST

  • API : interface entre l’utilisateur (client) et le modèle entraîné

  • API REST : permet de requêter le modèle avec une syntaxe simple (HTTP) et de manière scalable

Environnement de production

  • Dépend essentiellement de l’infrastructure à disposition

  • Un orchestrateur de conteneurs répond à plusieurs besoins :

    • Adapter les ressources (scaler) selon les besoins
    • Monitoring de l’état de santé des applications
    • Déploiements reproductibles et automatisés

Fonctionnement de Kubernetes

L’approche CI/CD : principes

  • Intégration continue (CI) : à chaque modification du code source, l’application est automatiquement tested, built and released

  • Déploiement continu (CD) : les nouvelles releases sont automatiquement déployées

  • GitOps : le processus est décrit sous formes de manifestes, stockés sur un dépôt Git

L’approche CI/CD : exemple

Pipeline complet

  • Les données d’entrée ne sont pas fixes, il faut les intégrer dans un pipeline complet de données

  • La représentation est faite sous forme de graphes acycliques dirigés (DAG)

Conclusion

  • On a construit un pipeline reproductible, automatisé et scalable

Bonnes pratiques pour la mise en production des projets de data science