Le laboratoire de recherche LIMOS et les sociétés Agaetis et Numtech ont mené en partenariat une étude sur l’utilisation d’une base de données noSQL orientée document pour stocker des données météorologiques. L’objectif de ce travail est de trouver une solution pour Numtech de gérer toutes les données utiles à son service météorologique. Les deux problématiques majeures sont l’hétérogénéité des données et le volume à traiter.

L’étude porte essentiellement sur les performances du système, autant au niveau de la vitesse d’insertion des données que sur l’évaluation de requêtes prédéfi nies.

Gestion d’une grande masse de données hétérogènes (big data)

Le service de modélisation météorologique de Numtech a besoin des données d’observations et qui produit des données d’analyse et des données de prévision. Toutes ces données sont hétérogènes car les sources, les mesures, les schémas, les unités et la précision sont différents. Les grilles géographiques ont également des tailles, des pas et des projections différents ce qui implique des imprécisions géographiques.

Les volumes sont également importants car les données d’observation représentent environ 1 Go par jour et les données d’analyse et de prévision environ 100 Go par jour. Toutes ces données doivent être conservées sur une longue période car certaines requêtes peuvent être effectuées sur plusieurs années.

Requêtes attendues sur la masse de données

Pour cette étude, il est attendu que la solution puissent répondre à 3 types de requête:

  • (R1) une extraction de plusieurs paramètres (température, pression atmosphérique, …) en un point du globe, à une altitude et sur une période données
  • (R2) une extraction sur une zone de toutes les données stockées sur une période allant de quelques jours à plusieurs années
  • (R3) une requête d’agrégation sur des paramètres 2D ou 3D sur une zone précise, entre deux altitudes et sur une période de temps définie

Choix de mongoDB et comparaison avec MySQL

La taille des données et les contraintes de temps concernant notamment l’insertion amènent à considérer un systèeme de gestion de données favorisant le passage à l’éechelle. Deux types d’extensibilites sont à envisager :

  • l’extensibilité verticale, qui consiste à augmenter la capacité de la machine gérant les données
  • l’extensibilité horizontale qui privilégie l’ajout de nouvelles machines pour augmenter les ressources de stockage et de calcul, en facilitant le partitionnement des données entre elles. Cette dernière approche rend plus facile la gestion du coût materiel de tels systèmes.

En outre, de part le type d’accès requis (essentiellement en ajout de données pour ce qui concerne les contraintes d’efficacité), certaines propriétés des SGBD relationnels ne sont pas indispensables. Le théorème de CAP, excluant d’avoir à la fois la consistance des données, leur disponibilité, et leur partitionnement oriente l’approche vers les systèmes noSQL. En effet, les SGDBR privilégient la consistance et la disponibilité au détriment du partitionnement, favorisant l’extensibilité verticale. Les systèmes noSQL privilégient par contre l’extensibilité horizontale, dans la mesure où ils sont conçus pour faciliter le partitionnement des données. La capacité de stockage et son coût n’étant pas linéaire, ces bases de données distribuées sont plus avantageuses lors du passage à l’échelle de l’application. Les données manipulées étant hétérogènes, l’absence de schéma statique fortement structuré dans les bases noSQL permet de palier aux difficultés habituellement rencontrées en terme d’évolution de la structure des données à stocker et de leur intégration dans un système permettant des requêtes homogènes.

CAP

Les tests

1er scénario : Insertion d’un jeu de données  correspondant à 7 jours d’observation en 3600 points, soit 825 000 relevés pour 6 millions de paramètres.

2 extractions (R2)  ont été exécutées, sur 2 zones géographiques différents et sur 2 périodes différentes (une période de 2 jours et une de 6 jours). Voici les temps de réponses:

MySQL MongoDB
R2 (2 jours) 10,3 s 7,45 s
R2 (10 jours) 160,61 s 82,93 s

2ème scénario : Insertion de la température issue de la prévision météorologique avec des mesures sur 104 heures dans une grille de 335 x 327 points et sur 42 niveaux d’altitudes. L’opération d’insertion exploite les capacités multi-processeurs des machines modernes afin de traiter le plus rapidement possible cette grille. Les données sont post-traitées puis distribuées sur 3 noeuds selon un clé représentant un « geohash » du point traité. Chaque noeud peut être répliqué afin d’assurer tolérance aux pannes et haute disponibilité. Le volume total de données en base est ici de l’ordre de 40 Go. Chaque heure de prévisions est représentée par un fichier distinct qu’il convient d’insérer en un maximum de 2 minutes compte-tenu des contraintes induites par une chaine opérationnelle déjà en place.

Les requêtes d’interrogation sont les suivantes:

  • R1 : 1 point, 1 paramètre, toutes altitudes, sur 6h. Cette requête retourne les 8 points les plus proches.
  • R2 : 1/10 de la grille, 1 paramètre, toutes altitudes (42), sur 6h
  • R3 : agrégation d’un paramètre sur une zone, sur 42 altitudes, pendant 3h.
MySQL
R1 9,16 s
R2 67,98 s
R3 13,12 s

Les requêtes R2 et R3 traitent les m^emes données, mais R3 exploite pleinement les capacités de calcul de la machine par le biais de l’utilisation du Map Reduce.

Conclusion

Le prototype a permis de répondre aux contraintes (volumes, temps de réponses, …) et une première version a été déployée en production.

Une deuxième étape du projet est consacrée à étudier l’apport de la technologie Hadoop pour l’analyse de données distribuées. En effet, Hadoop est plus optimisé pour le Map Reduce ce qui peut améliorer les performances des requêtes d’interrogations, notamment en cas d’agrégation.

 

Partenaires

LIMOS , Numtech

Tagged on: