Retour sur le meetup 'Big Data from space'
Le 11e meet-up du groupe Toulouse Data Science s'est déroulé le mercredi 18 mars à 18h 30 à la Cantine de Toulouse. Le sujet était Big Data from Space : un retour d'expérience du CNES sur les problématiques Big Data en lien avec le programme européen Copernicus.
La présentation était scindée en deux parties. Dans la masse des images satellites produites par Copernicus :
- comment pouvoir trouver facilement celles qui nous intéressent ?
- Et une fois qu'on les a, comment pouvoir en faire quelque chose d'utile sans les télécharger ?
La première partie, par Jérôme Gasperi, et dont les diapos sont disponibles sur slideshare, introduisait donc la problématique de l'indexation d'un gros volume d'images satellites. Jérôme commence par rappeler que les métadonnées fournies nativement avec une image satellite sont plus ou moins les mêmes qu'avec un appareil photo : date et heure de la prise, capteur, etc. On y trouve aussi les coordonnées de l'emprise au sol de l'image (bounding box). Ces métadonnées permettent de chercher des images sur une zone donnée dans une période donnée mais sont très insuffisantes pour répondre à des requêtes du genre « je veux les images qui contiennent une ville et une forêt ».
Pour ce genre de requêtes, la méthode traditionnelle consiste à effectuer une classification supervisée de l'image avec des algorithmes d'apprentissage automatique (meilleures résultats obtenus avec SVM) : j'indique à la machine sur un jeu d'entraînement ce que sont une forêt et une ville, et elle est alors capable de segmenter l'image en zones et de classer chaque zone dans une des catégories indiquées. Le problème est que cette méthode est longue : jusqu'à 15 minutes sur des images a très haute résolution et donc inadaptée pour le volume de données produites par Copernicus (jusqu'à 1 To par jour).
Une autre option est le deep learning. Jérôme pense que ce n'est pas non plus adapté aux images satellites, mais il a été contredit par plusieurs personnes dans la salle qui ont parlé de travaux montrant que c'était possible. Par exemple : https://www.cs.toronto.edu/~hinton/absps/road_detection.pdf.
La solution présentée utilise le croisement avec des données exogènes : au lieu de se contenter des pixels de l'image, pourquoi ne pas utiliser des informations accessibles par ailleurs ? Par exemple avec l'emprise et des données d'occupation du sol on peut dire si l'image intersecte une forêt et une ville. Avec des données administratives, on peut dire quels pays sont concernés par l'image. Avec la date et des données météorologiques, on peut dire le temps qu'il faisait au moment de la prise de vue. Jérôme a donc développé iTag (est-il Apple addict ?) qui permet de croiser ce genre d'informations et d'ajouter des tags aux métadonnées d'une image. Cela prend quelques milli-secondes: contre plusieurs minutes pour une classification, le gain est énorme.
Un dernier point : il a aussi montré sur son démonstrateur (non accessible pour l'heure) comment il présentait les résultats d'une recherche sous la forme d'une carte de chaleur. En effet, contrairement à une recherche Google où les résultats sont triés par pertinence, ici le moteur ne sait pas faire ce tri. Les résultats sont donc présentés sur une carte du monde et des points de couleurs viennent montrer la densité des résultats : bleu s'il y a pas ou peu d'images qui correspondent aux critères sur cette zone ; rouge s'il y en a beaucoup.
La seconde partie, par Pierre-Marie Brunet, peut se résumer en une phrase : il vaut mieux rapprocher le calcul de la donnée que l'inverse.
Partant du constat que les données aujourd'hui sont de plus en plus gratuites, et que la véritable valeur se situe dans les algorithmes de traitement sur ces données, l'enjeu est d'éviter que tout un chacun vienne moissonner les images Copernicus, les télécharge chez lui pour en faire ce que bon lui semble : vu les volumes à télécharger, cela mettrait le réseau à genou.
J'ajoute ce commentaire personnel : le documentaire « Internet, la pollution cachée » diffusé sur France 5 en 2014, bien que discutable dans ses calculs et dans ses partis pris, permet de se rendre compte de ce que coûte l'envoi d'un simple mail.
Il s'agit donc de permettre aux usagers de demander à la plate-forme d'effectuer elle-même les traitements dont ils ont besoin, grâce par exemple au protocole WPS de l'OGC, et de télécharger plutôt le résultat de ces traitements.
Vu le nombre d'utilisateurs possibles, cela demande de mettre en place une infrastructure de calcul conséquente. Le rapprochement du HPC et du Big Data : le Big Processing.
Avec cette expérience accumulée, l'architecture cible pour Copernicus sera donc fondée pour la partie logicielle sur Hadoop, Spark, Elasticsearch et Kibana. Mais le plus intéressant est la vision haut-niveau : un ordonnanceur, dont j'ai oublié le nom, aura une information en temps réel sur l'état des nœuds de calcul, sur la répartition des données et sur la vitesse de transfert entre les données et les nœuds. Mieux, chaque nœud sera capable de faire tourner des conteneurs Docker, et il y aura un registre d'images Docker, local et distribué lui aussi. Par conséquent, pour un calcul demandé par un usager :
- ce calcul correspond par exemple à une image Docker compute et concerne des données facilement accessibles par le nœud A ;
- l'ordonnanceur va donc demander au nœud A d'exécuter l'image compute sur les données concernées ;
On retrouve bien le principe : les calculs sont rapprochés des données (même si on ne s'interdit pas de déplacer les données).
L'utilisation de Docker a d'autres avantages :
- les usagers pourront proposer leur propres images pour réaliser des calculs dont ils ont besoin et qui ne seraient pas encore proposés ;
- les centres de calcul étant répartis dans les différents pays européens pour Copernicus, chaque centre a ses spécificités (distribution GNU/Linux différente d'un centre à l'autre par exemple). Comme il n'est pas question d'imposer un choix (à part Docker), Docker permet de faire tourner des calculs dans tous les centres quelles qu'en soient les spécificités.
Tout ceci ressemble beaucoup à ce que nous avons fait pour Simulagora.
