Répétition avant soutenance de thèse
Les travaux de cette thèse s’inscrivent dans le cadre du projet Petasky[1]. Ce projet est financé par le CNRS dans le cadre du défi Mastodons (http://www.cnrs.fr/mi/spip.php?article53). L’objectif est de proposer des outils permettant de gérer des dizaines de Peta-octets de données issues d’observations astronomiques. Les données considérées sont collectées dans le cadre de deux projets LSST et Gaia. Nos travaux se focalisent essentiellement sur la conception des nouveaux systèmes permettant de garantir le passage à l’échelle. Dans cette thèse, nos contributions concernent trois aspects : Bechmarking des systèmes existants, conception d’un nouveau système et optimisation du système.
Nous avons commencé par analyser la capacité des systèmes fondés sur le modèle MapReduce et supportant SQL à gérer (stockage, chargement, …) les données LSST et leurs capacités d’optimisation (c.-à-d., l’indexation, la compression, l’utilisation de cache et partitionnement) de certains types de requêtes. Nous avons considéré différentes configurations pour analyser des différents paramètres: matériel, données, requêtes, indexation et sélectivité. Nous avons également motivé la nécessité de nouvelles techniques pour l'optimisation des requêtes pour les systèmes émergents. Comme nous avons pu le constater après notre campagne d’évaluation, il n’y a pas de technique « magique » pour partitionner, stocker et indexer les données mais l’efficacité des techniques dédiées dépend essentiellement du type de requêtes et de la typologie des données considérées.
Suite à notre travail de Benchmarking, nous avons retenu quelques techniques qui doivent être intégrées dans un système de gestion de données à large échelle. Nous avons conçu un nouveau système de façon à garantir la capacité dudit système à supporter plusieurs mécanismes de partitionnement et plusieurs opérateurs d’évaluation. Nous avons utilisé BSP[2] (Bulk Synchronous Parallel) comme modèle de calcul. En effet, contrairement au modèle MapReduce, nous n’envoyons les résultats intermédiaires qu’aux nœuds permettant de continuer le traitement. Les données sont représentées logiquement par des graphes et physiquement par des B+-Tree. L’évaluation des requêtes est donc faite en explorant le graphe de données en utilisant les arcs entrants et les arcs sortants.
Nous proposons un partitionnement semi-automatique. Néanmoins, on laisse à l’administrateur du système le choix de la manière de partitionner les données en utilisant le schéma de la base de données et les connaissances métiers du domaine. Nous proposons de réaliser ce partitionnement avec des jobs MapReduce.
En analysant le fonctionnement de notre système, deux problèmes d’optimisation ont été identifiés : 1) à partir d’une requête, comment trouver le meilleur plan d’exécution physique ? Et, 2) à partir d’une affectation initiale des partitions et un historique de transferts entre partitions, comment trouver une autre affectation des partitions permettant de minimiser les coûts de transferts entre les machines ?
