Contact

Computer vision • Calcul distribué • Scaling • Jupyterhub & Spark submit

img Pipeline Big Data
AWS EMR avec Spark img

img
img

  • Cadre

    Calcul full scale

  • Domaine

    Big data cloud

  • Approche

    Du prototype local au scalable

  • Objectif

    Créer et optimiser un pipeline de données

Contexte & problématique

Les pipelines de vision par ordinateur passent souvent un cap critique : ce qui fonctionne sur quelques milliers d’images en notebook devient vite un frein dès que la volumétrie augmente. Les temps de calcul explosent, l’exécution devient difficile à reproduire et la chaîne de préparation des données — pourtant centrale pour la qualité du modèle — se transforme en goulot d’étranglement, avec un impact direct sur les délais et les coûts.

Ce projet adresse ce passage à l’échelle en industrialisant un traitement distribué avec Spark sur AWS. L’objectif n’est pas seulement “d’aller plus vite”, mais de construire une pipeline relançable et dimensionnable, capable d’extraire des descripteurs d’images et de les préparer pour la suite (réduction de dimension, sauvegarde structurée), tout en comparant concrètement deux modes d’exploitation cloud : exploration via EMR JupyterHub, puis exécution batch via spark-submit, dans une logique proche d’un run de production.

img img

Approche progressive local → cloud

L'industrialisation s'est déroulée en trois phases. En local d'abord, dans un conteneur Docker avec Spark standalone, pour tester les optimisations de base (broadcast des poids, cache, partitionnement) sur un échantillon réduit. Puis sur AWS EMR avec JupyterHub pour le développement interactif et le prototypage. Enfin, via spark-submit en mode cluster, configuration cible pour un run de production automatisé et reproductible.

Préparation des données

Le notebook initial chargeait les images complètes en mémoire et réinstanciait le modèle TensorFlow à chaque partition. La version optimisée diffuse les poids une seule fois via broadcast(), instancie le modèle une fois par worker, et met en cache les DataFrames intermédiaires. Le partitionnement est ajusté dynamiquement selon le volume (de 10 partitions pour 1k images à 200 pour 100k+).

img img

Architecture AWS conforme RGPD

L'ensemble de l'infrastructure est déployé dans la région eu-west-1 (Irlande) : cluster EMR, buckets S3, instances EC2. L'accès se fait via tunneling SSH pour sécuriser les interfaces web (JupyterHub, Spark UI, YARN). Les données et traitements restent sur le territoire européen.

Cluster EMR & ressources

Configuration finale : 1 master + 8 workers sur instances m5.xlarge (4 vCPU, 16 GB RAM). Bootstrap automatique des dépendances (TensorFlow, librairies Python). Organisation S3 : /data/images, /results, /scripts, /logs, /history pour la persistance du History Server.

img img

Analyse des features - Qualité validée

Distribution très similaire entre training et test (régression linéaire : ARI = 0.96). Métriques de classification (precision, recall, F1) : 0.98. Pas de data drift, cohérence confirmée pour la suite du pipeline ML.

Réduction de dimension (PCA)

Passage de 1280 features initiales à ~150-200 composantes pour capturer 95% de la variance. Réduction significative de la dimensionnalité, facilitant les étapes de classification ultérieures tout en préservant l'information essentielle.

img img

JupyterHub → spark-submit : gain immédiat

Sur le jeu de test (34 711 images, 40 partitions, 5 workers), passage de JupyterHub à spark-submit en mode client : 12 min → 8 min (gain de 33%). Élimination de la latence Livy/Jupyter qui ajoutait 10-15 secondes d'overhead par job.

Scaling validé sur le dataset complet

Configuration finale (8 workers, 200 partitions) sur 103 993 images : extraction de features + normalisation + PCA en 21-23 minutes. Comportement linéaire jusqu'à 8 workers. Test intermédiaire (50k images, 5→8 workers) : 18 min → 7:30 (réduction de 58%).

img img

Apports du projet

• Pipeline optimisé : gain de 30-40% vs. version initiale

• Scalabilité démontrée : de 1k à 100k+ images avec comportement linéaire

• Infrastructure production-ready : mode cluster, conformité RGPD, monitoring

Compétences techniques mobilisées

• Architecture Big Data : dimensionnement, choix des ressources, passage à l'échelle

• Spark avancé : broadcast, cache, UDFs vectorielles, partitionnement dynamique

• Cloud AWS : EMR, S3, IAM, tunneling SSH, gestion des coûts

Stack & ressources

Apache Spark · PySpark · AWS EMR · TensorFlow · Docker · JupyterHub · S3 · Computer Vision · Distributed Computing · PCA

Github     Voir la présentation (slides)

← Précédent
→ Suivant