Dans le cadre de ses activités pour les acteurs du domaine Spatial et de l’Observation de la Terre, Geomatys a structuré ses activités selon trois axes :
Cet article présente un retour d’expérience sur la mise en place de traitements à la volée sur un DataLake pour les besoins d’une agence spatiale.
Que l’on soit en charge de la production et la collecte de données où en charge d’un DataLake et de l’analyse ultérieure de ces mêmes données, force est de constater que la quantité d’information produite ne cesse d’augmenter. Les segments sols et centres de mission scientifiques, n’échappent pas à cette tendance, en raison notamment des nouveaux instruments scientifiques avec de très hautes résolutions, entraînant des volumes de données à produire, stocker et transmettre toujours plus conséquents.
Cependant, combien de données seront réellement utilisées au regard du volume de données brutes acquises ? Si l’on prend le cas du satellite optique Sentinel 2, une recherche sur la plateforme SciHub sur l’année 2020, indique que, tous types de produits confondus, un peu moins de 11 Millions de produits ont été générés cette année là et qu’ environ 1,7 millions possèdent une couverture nuageuse supérieure à 95 % soit la quasi totalité de l’image. Il est donc probable que plus de 15% des données acquises en 2020 ne soient jamais utilisées. Ce pourcentage peut varier en fonction du capteur à l’origine de la mesure (radar, optique…) mais le constat reste valable pour tous, un nombre non négligeable de données brutes ne sera pas utilisé pour produire des analyses. A ce pourcentage de données “non utilisables” s’ajoutent les données pour lesquelles la mesure est exploitable mais qui ne seront simplement pas utilisées par manque d’utilisateurs pour la zone ou la période.
Pour le producteur (et le gestionnaire de DataLake) cela représente une quantité de données non négligeable (environ 1,7 PetaOctet de données par an. dans le cas de Sentinel 2). Dans le cas de chaînes de production complexes telles que les segments sols de satellite ce nombre peut être multiplié par le nombre de post-traitements que subit la donnée depuis la mesure brute (L0 ou L1) jusqu’à devenir un produit prêt à l’utilisation (L2 à L4). Toujours dans le cas Sentinel 2, trois post-traitements sont appliqués (niveau L1A, L1B et L1C) à la donnée avant d’obtenir une donnée de niveau L2, produite systématiquement. Finalement, ce sont donc plusieurs dizaines de Po de données qui ont été traitées et stockées et qui ne serviront pas. Outre que cela ne s’inscrit pas vraiment dans une démarche “GreenIT”, cela impacte également le coût de l’infrastructure matérielle. Passer d’un traitement systématique à une donnée prête à l’emploi (dans la mouvance de la démarche Analysis Ready Data) et produite à la demande, permettrait d’éviter cette sur-production inutile (note pour l’aspect GreenIT : nous laissons au futur résultat d’une étude ACV le soin de déterminer le point d’équilibre entre traiter deux fois une même image ou mettre le résultat en cache après la première demande, l’un consommant plus d’énergie ou l’autre nécessitant plus de disque dur).
Aujourd’hui, cette approche “à la demande” est de plus en plus mise en œuvre pour des traitements à partir des données post-traités (production à la demande d’occupation des sols, de taux d’humidité comme pour le projet européen Phidias sur lequel Geomatrys est impliqué au côté de nombreux partenaires dont le CNES le CINES et l’IRD …), évitant ainsi tout ou partie de la production systématique. Cependant, la plupart des segments sols (du niveau L0 au niveau L2 dans le cas de Sentinel 2) reste sur une approche systématique malgré les quantités de données inutiles. Pourquoi ? Une raison possible, sans doute pas la seule, est qu’un des post-traitements essentiels consiste à projeter sur une grille régulière les mesures dérivées du signal capté par le satellite.
La projection des données consiste à associer des valeurs du signal (le signal pour chaque pixels) de manière directe ou indirecte à des coordonnées géospatiales distribuées selon une grille régulière. Cela rend les données beaucoup plus faciles à exploiter que des valeurs distribuées de manière irrégulière. Or, l’algorithme de re-échantillonage à partir de ces simples valeurs est complexe et peut s’avérer coûteux en termes de performances. Depuis 2018, RESTEC (Remote Sensing Technology Center of Japan) société affiliée à l’Agence Spatiale Japonaise (JAXA), travaille avec Geomatys sur l’application de cette projection à la volée pour les données issues des satellites GCOM-C et W.
Dans l’exemple du GCOM-W, la donnée brute à laquelle est appliquée la projection à la volée correspond à une partie conséquente de l’orbite du satellite. La position de chaque pixel est exprimée en latitude et longitude pour chaque pixel, ainsi de l’équateur au pôle existe t’il une très grande variabilité dans la taille des pixels.
L’objectif est donc de fournir à l’utilisateur un accès à la volée à des données prêtes à l’emploi (approche Analysis Ready Data), moins dépendant de la structure initiale des produits et, dans le cas de GCOM-W, de l’orbite du satellite.
Pour cela, l’ensemble des données est indexé comme une couche spatio-temporelle unique (ou cube de données). Ainsi l’utilisateur peut télécharger l’emprise spatio-temporelle des données qu’il souhaite via des services standards (WCS ici) indépendamment de la structure des données acquises par le satellite.
Proposer un tel service à la volée nécessite de disposer d’une opération de projection efficace. C’est sur cet aspect que nous avons concentré le gros de nos travaux durant 2 ans.
Il est assez facile de déterminer les coordonnées géographiques (latitude et longitude) de chaque pixel lorsque ces coordonnées sont déclarées dans le fichier. Il est beaucoup plus difficile d’effectuer le cheminement inverse, c’est-à-dire de trouver le pixel auquel correspond des coordonnées géographiques, lorsque ces pixels ne sont pas distribués sur une grille régulière. L’approche brute (inapplicable pour les grandes images) consisterait à itérer sur chaque pixel jusqu’à trouver le plus proche. L’approche présentée ci-dessous, et mise en œuvre par Geomatys permet de résoudre la problématique à la volée avec une précision et des performances maîtrisées.
Les tests de performances réalisés par RESTEC sur l’infrastructure de la JAXA ont permis de qualifier et valider la viabilité de l’outil et de l’approche, qui entrera en production en 2021. Bien conscient que la problématique lié au satellite GCOM est applicable à d’autre sources de données, Geomatys s’est employé au cours des deux dernières années à mettre en place un process générique via le logiciel Examind DataCube qui capitalisent cette expérience et permettront d’accélérer les prochaines mises en oeuvre de la solution.
D’un point de vue technique, la démarche est la suivante :
Les tests de performances réalisés par RESTEC sur l’infrastructure de la JAXA ont permis de qualifier et valider la viabilité de l’outil et de l’approche, qui entrera en production en 2021. Bien conscient que la problématique lié au satellite GCOM est applicable à d’autre sources de données, Geomatys s’est employé au cours des deux dernières années à mettre en place un process générique via le logiciel Examind DataCube qui capitalisent cette expérience et permettront d’accélérer les prochaines mises en oeuvre de la solution.