Mission Freelance Data Scientist Expert Vertex Et Gcp

MISSION

Objectif : Développer et livrer la "Plateforme MLOps" en juin, utilisant des services de GCP et IT SFR.

Technologies utilisées :
* GCP Workstations (environnement de développement)
* GCP Bigquery
* GCP GCS
* GCP Vertex, 1. Recetter la plateforme MLOps mainstream GCP.
2. Réapprendre un modèle existant dans le process MLOps mainstream GCP.
3. Développer un use-case de data science type, intégrant les best practices des services utilisés.

Fonctionnement actuel :
* Administration de trois serveurs physiques on-prem pour les projets de data science.
* Utilisation de technologies pour chaque étape du workflow de ML (installation de packages, connexion à Bigquery, entraînement et analyse de modèles, sauvegarde des modèles, préparation des scripts d'inférence, versioning sur Gitlab).

Modifications en mode MLOps GCP :
* Entraînement des modèles délégué aux services Vertex.
* Environnement de développement sur GCP Workstations.
* Utilisation de containers GCP Workstations pour concevoir scripts, images docker, et pipelines Kubeflow.
* Versioning des codes et build des images docker via Gitlab.
* Inférence des modèles déployée en mode endpoint par Vertex.
* Monitoring des modèles supervisé par Vertex Monitoring et une application shiny conteneurisée sur Cloud Run.

Définition de la prestation :
* Recetter la plateforme MLOps mainstream GCP.
* Réapprendre un modèle existant dans le process MLOps mainstream GCP.
* Développer un use-case de data science type.

Points de recette :
* Recette de la workstation (configuration, containers, IDE fonctionnel, connexion à divers services).
* Recette des templates de CI Gitlab (build des images docker, appels aux services Vertex, création/modification des dags Airflow).
* Recette du fonctionnement d'Harbor (connexion et push des images).
* Recette du fonctionnement de Nexus (proxy des repos publics).
* Recette du fonctionnement d'Airflow (environnement de run)., recetter la plateforme dans son volet MLOps mainstream GCP (fonctionnalistés détaillées ci-dessous)
- réapprendre l'un des modèles existants dans le process MLOps mainstream GCP. Ceci inclut les étapes :
- d'analyse
- d'entraînement/test/validation des modèles
- de mise en production
- et de monitoring des modèles
- développer un use-case de data science type rassemblant l'ensemble des best practices des services utilisés, qui servira de socle aux futurs projets

L'objectif de recette peut être mené conjointement aux deux autres, l'application du workflow de ML représentant une opportunité de recette en soi.

La recette inclut notamment les points suivants :
- recette de la workstation :
- de ses configurations et containers préparamétrés, qui doivent notamment :
- proposer :
- un ide fonctionnel : Rstudio server, jupyterlab ou code-oss au choix du datascientist
- tout le socle permettant l'utilisation des binaires métiers (Python, R, Java, git) ainsi que l'installation / compilation des packages requis par le projet
- être démarrés avec :
- un montage fuse d'un ou plusieurs buckets GCS en guise de stockage persistant non rattaché à la VM sous-jacente
- une authentification GCP héritée de la connexion aux workstations via la console GCP
- être connectés à :
- Bigquery
- GCS
- Vertex
- Cloud Run
- Gitlab
- Harbor
- Nexus
- de la possibilité de proposer des merge requests sur le repo Gitlab des images docker accessibles par la workstation
- ainsi que sur le repo des configuration des clusters de workstations (terraforms)
- recette des templates de ci Gitlab de la plateforme, qui doivent notamment permettre de :
- builder les images docker d'inférence et de monitoring
- déclencher des appels aux services Vertex, dans les environnements de lab et de run
- créer / modifier les dags exécutés par le serveur Airflow
- recette du fonctionnement d'Harbor (container registry) :
- check que GCP workstations et Cloud Run se connectent bien à Harbor
- check que Gitlab peut pusher les images qu'il a buildées sur notre repo Harbor
- recette du fonctionnement de Nexus (package manager) :
- check du bon fonctionnement en tant que proxy des principaux repos publics (conda, pypi, cran, posit package manager, huggingface notammment), tant en lab qu'en run
- recette du fonctionnement de Airflow (sur l'environnement de run) :
- check de la bonne exécution des dags
- check de la bonne récupération des logs de tâches GCP dans l'UI Airflow

Environnement de travail

Présentation du fonctionnement actuel
A date, l'équipe administre trois serveurs physiques on-prem et y fait tourner l'ensemble de ses projets de data science. Les technos utilisées pour chaque étape du workflow de ML sont détaillées ci-dessous :
- Analyse exploratoire / entraînement de modèles :
- Le data scientist démarre un container docker sur l'un des serveurs linux.
- Ce container expose un Rstudio server (équivalent notebook) auquel le data scientist se connecte.
- A partir de cet environnement de travail, le data scientist peut :
- installer de manière persistante les packages R/Python dont il a besoin pour son projet
- se connecter à notre DWH Bigquery pour requêter, récupérer ou y remonter des données
- exploiter de manière non capée les cpus et la ram de la machine hôte
- entraîner des modèles
- analyser leur performance
- sauvegarder sur disque persistant le ou les modèles retenus ainsi que la base d'apprentissage et les fichiers de QOD associés (distributions des variables de la base d'apprentissage)
- préparer le ou les scripts d'inférence du modèle, qui, au sein d'un container similaire, loaderont le modèle sauvegardé, réaliseront l'inférence en batch, et remonteront les outputs du modèle (probas et métriques de QOD des variables d'entrée notamment) sur Bigquery et/ou sur fichiers locaux
- pusher son code sur un serveur Gitlab on-prem pour partage et versioning
- Inférence du modèle :
- Un container identique au container d'apprentissage mais dépourvu de Rstudio server est démarré de manière automatique par un worker Airflow afin de réaliser un batch d'inférence. Les dossiers contenant les packages, les scripts et les artefacts nécessaires à l'inférence sont montés au run dans le container.
- Le container exporte ses résultats (probas et métriques de QOD des variables d'entrée notamment) sur BigQuery et/ou sur disque.
- Monitoring :
- Une application R shiny portée par un shiny-server accède aux fichiers locaux et/ou aux données remontées sur Bigquery par les jobs d'inférence et affiche :
- le suivi des distributions des inputs du modèle
- l'évolution des performances à froid du modèle (dans le cas des modèles supervisés et une fois que l'on dispose de suffisamment de recul temporel)