Résumé
Cette présentation porte sur le déploiement d'un modèle de classification de fruits et légumes dans le cloud en utilisant AWS et PySpark. Le projet vise à gérer un afflux important de données et à effectuer des calculs distribués.
- Rappel de la problématique de classification de fruits et légumes à grande échelle.
- Description de l'environnement Big Data mis en place avec AWS et Spark.
- Présentation des traitements effectués dans le cloud, incluant le chargement des images, la vectorisation et la réduction de dimension.
- Démonstration de l'utilisation de PySpark dans le cloud.
Sommaire [0:00]
La présentation aborde le déploiement d'un modèle dans le cloud, en commençant par un rappel de la problématique, suivi de la description de l'environnement Big Data mis en place. Ensuite, elle présentera les traitements effectués dans le cloud, une démonstration en PySpark, et enfin, une synthèse et conclusion.
Problématique [1:39]
L'entreprise Fruitite souhaite classifier des fruits et légumes à partir de leurs images. Bien que simple à petite échelle, cela devient complexe avec un grand volume de données et nécessite des outils cloud, du Big Data et du calcul distribué. Le dataset comprend 131 types de fruits et légumes avec plus de 90 000 images en format 100x100 pixels, divisées en ensembles d'entraînement et de test. Pour la preuve de concept, seules deux catégories (abricots et avocats) avec 10 images chacune sont utilisées.
Environnement Big Data [2:58]
Pour faire face à un afflux important de données, l'environnement s'appuie sur AWS (Amazon Web Services) et le framework Spark pour le calcul distribué. PySpark est utilisé comme interface Python pour Spark. AWS comprend plusieurs services, mais seuls trois sont utilisés : Amazon S3 pour héberger les fichiers et récupérer les résultats, Amazon EMR (Elastic MapReduce) pour le calcul distribué, et IAM (Identity and Access Management) pour gérer les accès et les droits des utilisateurs.
Amazon S3 est utilisé pour stocker les fichiers d'entrée (images) et les résultats de la réduction de dimension. Deux buckets sont présents : un pour les logs et un autre (ypv_p8_data) créé via l'interface en ligne de commande AWS CLI. Ce dernier contient des fichiers bootstrap (bootstrap_emr.sh) pour installer les librairies nécessaires, un dossier Jupiter avec des notebooks, un dossier test avec les images d'abricots et d'avocats, et les résultats de la réduction de dimension en formats Parquet et CSV.
Amazon EMR est utilisé pour le calcul distribué. Plusieurs clusters ont été créés, les derniers étant des clones des précédents avec des modifications. Le cluster utilisé est en état d'attente et exécute la version 6.30 de l'EMR. Différentes applications sont installées, telles que Jupiter, Spark et TensorFlow. Un tunnel SSH est configuré pour l'accès. Le fichier bootstrap est utilisé pour installer des librairies comme Pandas. Les instances utilisent des processeurs avec 4 cœurs et 16 Go de mémoire vive.
IAM (Identity and Access Management) permet de définir les utilisateurs et leurs droits d'accès. Un utilisateur "évaluateur" est créé avec une politique S3 "évaluateur lecteur seul", lui permettant un accès complet en lecture et en listing des fichiers et dossiers sur S3, mais sans droits de modification ou d'écriture.
Traitement dans le cloud [12:23]
Les images hébergées sur S3 sont chargées de manière distribuée au format binaire. Le chemin d'accès des images est utilisé pour récupérer le nom de la catégorie (label). Un modèle pré-entraîné MobileNetV2 (créé par Google) est utilisé, mais seule la partie allant jusqu'à l'avant-dernière couche est conservée pour obtenir un vecteur de dimension 1280. Les poids calculés de ce modèle sont réimplantés sur le nouveau modèle sans la dernière couche.
Les images, initialement en 100x100 pixels, sont redimensionnées en 224x224 pixels pour être compatibles avec le modèle. Les images sont ensuite vectorisées avec le modèle, ce qui produit un array qui est transformé en vecteur pour la réduction de dimension. La différence entre l'array et le vecteur réside dans la séparation des features (virgule espace pour l'array, simple virgule pour le vecteur).
Avant la réduction de dimension, une standardisation des données est effectuée avec l'outil StandardScaler. La réduction de dimension est réalisée avec une PCA (Principal Component Analysis) via PySpark. Pour la preuve de concept, l'objectif est de réduire à deux composantes. En local, une analyse est effectuée pour déterminer le nombre de composantes nécessaires pour récupérer une variance acceptable. Avec moins de 20 composantes, il est possible de récupérer quasi 100% de la variance.
PySpark [17:06]
Une démonstration de l'utilisation de PySpark dans le cloud est tentée, mais des problèmes de connexion au notebook Jupiter sont rencontrés. Après résolution des problèmes de tunnel SSH et de port, l'accès au notebook est rétabli. L'exécution complète du notebook est lancée pour vérifier le bon fonctionnement du script.
Synthèse et conclusion [20:31]
Le projet a été développé en deux phases : une phase locale pour valider le script PySpark et une phase dans le cloud pour exploiter les architectures Big Data. La difficulté initiale résidait dans l'environnement Windows, mais l'utilisation de Google Colab a facilité le travail en local. Le passage au cloud avec AWS et le service EMR a simplifié l'installation des packages et des librairies grâce aux fichiers bootstrap. Le service S3 est simple d'utilisation et économique.
La démonstration de l'utilisation des outils Big Data et des briques AWS a été réalisée avec succès. Pour une mise en production, il sera possible de redimensionner l'infrastructure de manière horizontale (en augmentant le nombre d'instances) ou verticale (en augmentant la puissance des clusters) pour faire face à une montée en charge et à un afflux de données plus important.