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.
