- 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
Pipeline Spark ML sur GCP Dataproc Serverless avec parité locale
Le même pipeline tourne en local ou sur Dataproc Serverless via un simple changement de config.
Cela réduit la dérive et assure des résultats reproductibles.
Workflow data engineering : ingest → features → train → eval → dashboard
L’ingestion normalise les données en parquet, les features agrègent l’intention, et l’évaluation exporte metrics/figures.
Le dashboard lit des agrégats pré‑calculés pour un review rapide.
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.
Stack technique
FAQ
Pourquoi Spark plutôt que pandas ?
Spark gère des volumes plus importants et conserve le même chemin d’exécution en local et dans le cloud.
Comment garantir la parité local ↔ cloud ?
Le pipeline est piloté par config : basculer config.yaml vers config.gcp.yaml ajuste chemins et settings sans changer le code.
Quels outputs vérifier en priorité ?
Commencer par reports/metrics.json et reports/figures/metrics.png, puis le dashboard Streamlit.