- ProblèmePipeline ML Spark reproductible (ingest → features → train → eval → exports) avec parité local ↔ GCP.
- RôleDémo data + platform engineering
- DuréePrototype
- StackPython • PySpark • Spark MLlib • GCS
- FocusSpark • PySpark • MLlib
- RésultatsUn pipeline analytics ML reproductible qui garde les features, modèles et dashboards cohérents entre local et cloud.
Problème
Les pipelines analytics dérivent entre laptop et cloud : chemins, configs et features deviennent incohérents. Résultat : dashboards peu fiables, itérations lentes, et décisions difficiles à auditer.
Pourquoi c’est critique : sorties cohérentes, reruns rapides et décisions modèles traçables.
- Pipeline Spark config-driven : ingestion → features → entraînement/évaluation → exports dashboard
- Parité local ↔ Dataproc Serverless via Makefile + config.yaml / config.gcp.yaml
- Artifacts déterministes dans reports/ (metrics, figures, agrégats parquet)
- Dataset externalisé (GCS public ou BYO) pour garder le repo léger et reproductible
Contexte
Architecture en bref — CSV clickstream → parquet (schéma + partitionnement), features de sessions, modèle logistique baseline, métriques + agrégats exportés pour Streamlit.
Lecture de l’architecture — Ingestion produit des partitions parquet immuables, les features agrègent l’intention par session, l’entraînement consomme des features versionnées, l’évaluation écrit métriques/figures, et le dashboard lit uniquement les agrégats exportés (pas de Spark live).
Contexte réel — analytics produit : funnel de conversion et propensity scoring. La sessionization capte l’intention, le parquet rend les runs reproductibles, le filtrage leakage protège les métriques, et le split temporel reflète la dérive.
Migration cloud — Même pipeline en local ou sur Dataproc Serverless via la config : chemins locaux → GCS, master Spark → serverless, et helpers storage sans changement de code.
Dataset externalisé (GCS public ou BYO) pour exécutions propres en local et dans le cloud.
- Quickstart (local)
make setup ./scripts/download_data.sh make rerun_all_force make dashboard - Exécution Dataproc Serverless
bash scripts/gcp_run_all.sh # ou un job unique bash scripts/gcp_submit.sh
Architecture
- Flux pipeline (ingest → modèle → dashboard)
- Ingestion : parquet partitionné avec schéma appliqué.
- Features : agrégations de sessions + labels sans fuite.
- Modèle : logistic regression MLlib + split temporel si possible (fallback aléatoire).
- Exports : metrics, figures et agrégats pour Streamlit.
- Carte d’architecture (mouvements de données)
- Raw → processed : CSV normalisés en parquet partitionné.
- Processed → features : agrégations/joins pour la table modèle.
- Features → modèle : artifacts du modèle dans models/.
- Modèle → reports : metrics.json/csv + figures pour QA.
- Reports → dashboard : Streamlit lit reports/dashboard.
- Reproductibilité & parité d’environnement
- Le Makefile orchestre les mêmes étapes localement et sur Dataproc.
- config.yaml / config.gcp.yaml gardent chemins et settings explicites.
- Utilitaires de storage pour basculer local ↔ GCS sans changer le code.
- Migration cloud (local → Dataproc Serverless)
- Changement de config : chemins locaux → gs://, master Spark → serverless batch.
- Packaging unique du code, soumission batch par étape.
- Artifacts dans GCS (reports/models) ; dashboard lisible depuis GCS.
- Artifacts dashboard
- Le dashboard lit des agrégats exportés, décorrélés du training.
- reports/ contient metrics et figures pour QA rapide.
- Outputs et interprétation
- reports/ingestion_summary.json : volumes + plage temporelle.
- reports/features_summary.json : nb de lignes + taux positif.
- reports/metrics.json : AUC et métriques au seuil choisi.
- reports/figures/metrics.png : vérification visuelle rapide.
Sécurité / Modèle de menace
- Chemins de stockage explicites pour garantir la reproductibilité local/GCS.
- Aucun secret commité ; l’auth GCP passe par gcloud/gsutil.
- Dataset public externalisé, évitant d’embarquer des données lourdes dans le repo.
- Le dashboard lit des agrégats pré‑calculés (exposition et coûts réduits).
Compromis & retours d’expérience
Décisions clés — Spark plutôt que pandas, Makefile unique, portabilité par config.
Compromis — serverless réduit l’ops mais ajoute du cold start ; dashboard pré‑calculé sacrifie le temps réel.
Limites — modèle baseline uniquement ; pas de registry ni tracking avancé.
Next steps — MLflow, validation CI des outputs, runs Dataproc planifiés, data quality checks.
Résultats
Un pipeline analytics ML reproductible qui garde les features, modèles et dashboards cohérents entre local et cloud.