Pipeline Big Data AgriTech sur AWS
Poser les fondations d'une architecture capable d'absorber une forte croissance du volume d'images, sans avoir à la réécrire dans six mois. Un projet d'ingénierie data avant tout.
Le problème
Une start-up AgriTech développe des robots cueilleurs intelligents. Première brique : une application mobile qui identifie un fruit à partir d'une photo. Les images collectées serviront à entraîner le futur moteur de classification.
Le volume d'images va augmenter très rapidement. Le vrai enjeu n'était donc pas de coder un modèle, mais de bâtir une chaîne de traitement qui tienne la montée en charge : un pipeline capable de passer de quelques milliers à plusieurs millions d'images sans être refait de zéro.
La démarche
- Concevoir l'architecture avant de coder Un choix « cloud-native », de bout en bout : les images brutes sont lues depuis Amazon S3, traitées sur un cluster AWS EMR, puis réécrites sur S3. Aucun stockage intermédiaire local, donc aucune limite de taille.
- Extraire des caractéristiques sans réentraîner un modèle Utilisation du transfer learning avec MobileNetV2 : un réseau déjà entraîné sur des millions d'images sert à transformer chaque photo en un vecteur de caractéristiques utile. On réutilise, on ne repart pas de zéro.
- Éviter le coût caché du transfert de modèle Sur un cluster, chaque nœud exécute ses tâches en parallèle. Sans précaution, chaque worker recharge le réseau de neurones, ce qui représente un gaspillage massif de mémoire et de temps. La solution : le broadcast, qui diffuse les poids du modèle une seule fois vers tous les nœuds.
- Paralléliser l'inférence image Le traitement des images est distribué via des Pandas UDF : des fonctions Python optimisées, exécutées en parallèle sur l'ensemble du cluster plutôt qu'en boucle.
- Réduire la dimension pour optimiser le stockage Les vecteurs produits par MobileNetV2 comptent 1280 dimensions. Une PCA avec PySpark ML les ramène à 100 composantes, en conservant l'essentiel de l'information, donc bien moins de données à stocker et à lire.
- Stocker au bon format Écriture en Parquet, un format colonnaire compressé : on ne lit que les colonnes nécessaires, ce qui accélère fortement les analyses en aval par rapport à du CSV.
- Intégrer les contraintes de coût et de conformité Analyse critique des coûts et des performances du cluster, avec des recommandations pour la mise en production (Auto Scaling, instances Spot, monitoring). Les serveurs S3 et EMR sont configurés en Europe pour respecter le RGPD.
Les résultats
Ce que j'en retiens
- En Spark, deux détails changent tout : le broadcast et les Pandas UDF. Sans eux, on paie le coût de transfert du modèle sur chaque nœud et on perd le bénéfice du parallélisme. Ce sont des optimisations invisibles dans le résultat, mais visibles dans la facture.
- Réduire la dimension sert aussi à maîtriser le stockage. Passer de 1280 à 100 composantes, c'est diviser par plus de dix le volume stocké et lu, un gain direct sur le coût cloud.
- Le coût et la conformité font partie de la conception. La région des serveurs, l'Auto Scaling ou les instances Spot se décident au moment de l'architecture.
Piste d'amélioration : le pipeline a été exécuté pour valider l'architecture. En production, la prochaine étape serait de l'orchestrer (Airflow ou Step Functions) et d'ajouter un monitoring de l'état du cluster et du coût par exécution.