Modélisation NoSQL des entrepôts de données multidimensionnelles massives

Modélisation NoSQL des entrepôts de données
multidimensionnelles massives

LES ENTREPOTS DE DONNEES AVEC LE SYSTEME HDFS

Environnement Hadoop

Hadoop est un framework open source développé en java, faisant partie des projets de la fondation Apache depuis 2009. Il a été conçu pour : – Stocker des volumes de données très importants ; – Supporter des données de formats variés, structurées, semi- structurées ou non structurées. Hadoop est basé sur un ensemble de machines formant un cluster Hadoop. Chaque machine est appelée nœud. C’est l’addition des capacités de stockage et traitement de ses nœuds qui lui assure un important système de stockage et une puissance de calcul. Le système de stockage est appelé HDFS (Hadoop Distributed File System) [Borthakur 2008]. La puissance de calcul repose sur le paradigme de programmation parallèle MapReduce [Dean and Ghemawat 2010].

Présentation de HDFS

HDFS est le composant chargé de stocker les données dans un cluster Hadoop. Basé sur une architecture « maître-esclave », le système HDFS repose dans son fonctionnement sur deux types de nœuds : – Le namenode : le nœud maître est l’orchestrateur du système HDFS, au moyen de métadonnées. Il maintient l’arborescence de tous les fichiers du système et gère l’espace de nommage, autrement dit, il gère la correspondance entre un fichier et les blocs qui le constitue. Il prend en charge également la localisation des blocs des données dans le cluster. Il n’y a qu’un namenode par cluster HDFS. Le secondary namenode : il sert à effectuer à intervalle réguliers des sauvegardes du namenode. Il est utilisé pour prendre la relève en cas de panne du namenode. – Les datanode : ils servent d’espace de stockage et de calcul des blocs de données. Dans un cluster hadoop il y a donc une machine jouant le rôle de namenode, une autre machine sert de secondary namenode tandis que le reste des machines sont utilisées comme des datanodes.

Le paradigme MapReduce

Introduit en 2004 par Google, le paradigme MapReduce est un modèle de programmation parallèle développé spécifiquement pour lire, traiter et écrire des volumes de données très importants dans un environnement distribué. Google l’utilise pour gérer les gigantesques tâches portant sur des téraoctet- ou pétaoctet de données [O’Malley 2008].Son principe de fonctionnent est très simple : il s’agit de décomposer une tâche en tâches plus petites, autrement dit, découper une tâche portant sur de très gros volumes de données en tâches identiques portant sur des sous-ensembles de ces données. La décomposition consiste à découper le volume de données initial en N volumes plus petits, qui seront manipulés séparément. Le programme MapReduce est réalisé à partir de deux fonctions, Map et Reduce. La fonction Map découpe la tâche en un ensemble de petites tâches et les repartit sur l’ensemble des nœuds de sorte à ce que chaque petite tâche s’exécute sur le nœud qui héberge les données concernées. La fonction Reduce rassemble et agrège les résultats issus des fonctions Map parallélisées.

Exécution d’un traitement MapReduce avec Hadoop

Pour qu’un traitement MapReduce soit exécuté, Hadoop dispose d’un composant du coté namenode appelé jobtracker, chargé de superviser l’exécution complète du traitement sur les différents datanodes. Sur chaque datanodes autre composant appelé tasktracker supervise l’exécution de la tâche qui lui a été confiée. Au démarrage le jobtracker reçoit une requête cliente Map, consulte le namenode pour avoir la liste des nœuds stockant les données répondant au traitement. Une fois la réponse reçue, le jobtracker assigne la fonction Map aux différents tasktracker. Les tasktracker cherchent les données correspondantes au traitement sur leur datanode. Une fois que les fonctions Map terminées, les résultats de celles-ci sont stockés au niveau de chaque datanode. Les résultats des Map sont agrégés par la fonction Reduce prise en charge par un ou plusieurs datanodes. Le résultat final est renvoyé au datanode.

Entrepôts de données sous HADOOP

La communauté scientifique des entrepôts de données s’est orientée vers l’utilisation de cette plateforme . La Figure 4 montre comment l’architecture des systèmes décisionnels est étendue à l’utilisation de ce système distribué. Figure 4 Nouvelle architecture des systèmes d’aide à la décision Dans cette section nous étudions les travaux ayant exploité la plateforme Hadoop pour la construction de cube de données [Cao et al. 2011] [D’Orazio and Bimonte 2010] [Song et al. 2015] [Cao et al. 2011] introduisent ES2 , une nouvelle plateforme distribuée basée sur le cloud pour supporter des analyses sur de gros volumes de données, en particulier les ENTREPÔT Hadoop transactions OLTP et les processus OLAP. Les données sont issues de sources différentes et des traitements OLAP et OLTP peuvent s’effectuer simultanément sur le même espace de stockage. L’accès aux données se fait à travers deux interfaces, une dédiée aux opérations OLAP et une autre dédiée aux opérations OLTP. Les opérations sont isolées grâce à la politique mise en place appelée « locking mechanism ». Par exemple, lorsqu’une requête est soumise, elle se voit affectée un certain temps ts d’accès aux données, durant lequel l’opération ne sera pas interrompue jusqu’à la fin de son exécution ; les autres requêtes attendront l’écoulement du temps ts. Les données sont stockées dans une base de données orientée colonnes. Le but de cette approche est de bénéficier des avantages de MapReduce en termes de distribution des traitements et de la tolérance aux pannes, mais ne s’intéresse pas à la définition processus d’implantation des schémas multidimensionnels. [D’Orazio and Bimonte 2010] proposent de stocker des mégadonnées dans un tableau multidimensionnel et d’utiliser le langage PIG [Olston et al. 2008] [Gates et al. 2009]. Dans cette approche, les données d’abord stockées dans un tableau multidimensionnel, sont traduites dans des fichiers pour une analyse via le langage PIG. La traduction est assurée par un algorithme qui produit un fichier temporaire PIG supprimé après analyse (cf. Figure 5). Le fichier PIG est en un fichier constitué de tuples dénormalisés. L’interrogation se fait aussi en utilisant le langage d’interrogation PIG qui repose sur un plan d’exécution (composé de trois instructions) permettant de bonnes performances. Par exemple pour une requête OLAP classique calculant ‘le gain par région entre 1990 et 1991’, PIG effectue une sélection sur les dimensions membres (1990-1991), une autre instruction effectue un groupement par année et par région. La dernière instruction est utilisée pour effectuer l’agrégation, la somme dans cet exemple.

Table des matières

CHAPITRE I : Contexte et travaux
1.1 Introduction
1.2 Les systèmes d’aide à la décision
1.2.1 Entrepôts et magasins de données
1.2.2 Niveaux d’abstraction
1.2.2.1 Niveau conceptuel
1.2.2.2 Niveau logique
1.3 L’OLAP et le NoSQL
1.3.1 Architecture distribuées
1.3.2 Les modèles NoSQL
1.3.3 Problématique de la thèse
1.4 Organisation de la thèse
2. Chapitre II : Etat de l’art
2.1 Introduction
2.2 Les entrepôts de données avec le système HDFS
2.2.1 Environnement Hadoop
2.2.1.1 Présentation de HDFS
2.2.1.2 Le paradigme MapReduce
2.2.1.3 Exécution d’un traitement MapReduce avec Hadoop
2.2.2 Entrepôts de données sous HADOOP
2.3 Entrepôts de données avec les systèmes NoSQL
2.3.1 Modèles NoSQL
2.3.1.1 Modèles orienté agrégats d’information
2.3.1.2 Modèles orienté graphes
2.3.1.3 Synthèse
2.3.2 Entrepôts de données sous NoSQL
2.3.2.1 Processus de traduction indirecte
2.3.2.2 Processus de traduction direct
2.3.3 Bilan
2.4 Panorama des solutions industrielles
2.4.1 Les solutions clé-valeur
2.4.1.1 Voldemort
2.4.1.2 Riak
2.4.1.3 Redis
2.4.1.4 Memcahedb
2.4.1.5 Synthèse
2.4.2 Solutions orientées colonnes
2.4.2.1 Cassandra
2.4.2.2 HBase
2.4.2.3 Hypertable
2.4.2.4 Synthèse
2.4.3 Solutions orientées documents
2.4.3.1 MongoDB
2.4.3.2 CouchDB
2.4.3.3 SimpleDB
2.4.3.4 Terrastore
2.4.3.5 Synthèse
2.4.4 Solutions orientées graphes
2.4.5 Systèmes relationnels extensibles
2.4.5.1 MySQL Cluster
2.4.5.2 VoltDB
2.4.5.3 NuoDB
2.4.6 Synthèse des solutions industrielles
2.5 Bilan
3. CHAPITRE III : Modélisation multidimensionnelle « Not only SQL »
3.1 Introduction
3.2 Modélisation conceptuelle multidimensionnelle
3.3 Modélisation logique Not-only-SQL
3.3.1 Modélisation multidimensionnelle orientée documents
3.3.1.1 Modèle NoSQL orienté documents
3.3.1.2 Processus de traduction plate en orienté documents
3.3.1.3 Processus de traduction par imbrication en orienté documents
3.3.1.4 Processus de traduction hybride en orienté documents
3.3.1.5 Processus de traduction éclatée en orienté documents
3.3.2 Modélisation multidimensionnelle orientée colonnes
3.3.2.1 Modèle NoSQL orienté colonnes
3.3.2.2 Processus de traduction plate en orienté colonnes
3.3.2.3 Processus de traduction par imbrication en orienté colonnes
3.3.2.4 Processus de traduction hybride en orienté colonnes
3.3.2.5 Processus de traduction éclatée en orienté colonnes
3.4 Optimisation par cube olap
3.4.1 Définition d’un cube OLAP
3.4.2 Processus de traduction en orienté document
3.4.3 Processus de traduction en orienté colonnes
3.5 Bilan
4. CHAPITRE IV : Processus de Conversion Intra-modèles et Inter-modèles
4.1 Introduction
4.2 Processus de conversion intra-modèles
4.2.1 Conversions intra-modèles orientés documents
4.2.2 Conversions intra-modèles orientés colonnes
4.3 Processus de conversion inter-modèles
4.3.1 Conversions inter-modèles orientés documents et colonnes
4.3.2 Conversions inter-modèles des cubes OLAP
4.4 Bilan
5. Chapitre V : Environnement d’expérimentations
5.1 Introduction
5.2 Panorama Des bancs d’essai décisionnels
5.3 Le banc d’essai SSB
5.4 Le banc d’essai SSB+
5.5 Amélioration de l’indicateur d’échelle
5.6 La distribution des données
5.7 Le jeu de requêtes
5.8 Commandes DBGenk
5.9 DBLoad : outil de chargement de données
5.10 Expérimentations
5.11 Bilan
6. CHAPITRE VI : Expérimentations et validations »
6.1 Introduction
6.2 Protocole expérimental
6.3 Instanciation des entrepôts de données orienté documents
6.3.1 Temps de chargement et espace de stockage
6.3.2 Mise à jour des données
6.3.2.1 Exemple de mise à jour dans MongoDB
6.3.3 Interrogations
6.3.3.1 Exemple d’agrégation pipeline dans MongoDB
6.3.4 Calcul du treillis
6.3.4.1 Calcul du cuboïde classique
6.3.4.2 Calcul des cuboïdes étendus
6.3.5 Conversion intra-modèles
6.3.6 Discussion
6.4 Comparaison entre modèle relationnel et modèle orienté documents
6.4.1 Modèle orienté document : Comparaison avec le modèle relationnel
6.4.2 Construction du treillis d’agrégats
6.4.3 Discussion
6.5 Instanciation des entrepôts de données orienté Colonnes
6.5.1 Chargement des données
6.5.2 Calcul du treillis d’agrégats
6.5.3 Conversion intra-modèles
6.5.4 Discussion
6.6 Bilan
CHAPITRE VII : Conclusion
7.1 Conclusion générale
7.2 Perspectives