Soutenance mémoire
LES SYSTEMES D’AIDE A LA DECISION
Généralement, un système d’aide à la décision est constitué de données entreposées. Les architectures classiques reposent sur deux catégories d’espaces de stockage :
− L’entrepôt de données qui héberge les données de manière centralisée et uniforme. Il constitue un premier niveau de stockage favorisant la collecte et la gestion historisée (conservation de l’évolution des données collectées) des données.
− Les magasins de données constituent un second niveau du stockage utilisé à des fins d’analyse. Généralement, un magasin de données est dédié à un domaine métier ou une catégorie d’analyses. Les données sont organisées selon une modélisation multidimensionnelle [Kimball and Ross 2011] afin de supporter efficacement les processus d’analyses en ligne (on-line analytic processing, OLAP).
Entrepôts et magasins de données
La notion d’entrepôts de données a été introduite pour la première fois par Bill Inmon [Inmon 1995] [Inmon 2005]. Il constitue une base de données intégrées, contenant des informations historisées, non volatiles et destinées à la prise de décision.
Définition : Un entrepôt de données est une collection de données intégrées, variant selon le temps et non volatiles, qui sert de support au processus de prise de décision.
Les informations d’un entrepôt de données sont :
− Intégrées : les différentes données concernant les métiers et les services de l’entreprise sont centralisées et uniformisées de manière cohérente.
− Variant dans le temps (ou historisées). Les informations contenues dans un entrepôt de données sont identifiées par des périodes temporelles. Les évolutions de ces données peuvent être conservées au cours du temps.
− Non volatiles. Un état de stabilité est obligatoire pour permettre une traçabilité des décisions prises. Les données matérialisées dans un entrepôt ne sont généralement ni modifiées, ni supprimées.
Les données d’un entrepôt de données sont structurées en fonction des besoins analytiques ; par exemple les besoins d’analyse du service financier ne concernent que les données liées à ce dernier, d’où l’utilisation de magasins de données orientés sujets. Un magasin de données est un sous-ensemble de l’entrepôt de données.
Définition. Un magasin de données est un extrait orienté sujet de l’entrepôt, organisé selon un modelé adapté (multidimensionnel) aux outils d’analyse et d’interrogation décisionnelle.
Niveaux d’abstraction
Concevoir un système décisionnel nécessite une phase de modélisation des données multidimensionnelles. Plusieurs approches ont été proposées selon trois niveaux d’abstraction :
– Conceptuel. Ce niveau d’abstraction consiste à représenter l’espace de données multidimensionnelles indépendamment des techniques informatiques.
– Logique. Ce niveau d’abstraction désigne une technique de modélisation (relationnel, objet, NoSQL, etc).
− Physique. Ce niveau d’abstraction correspond à un logiciel particulier choisi dans la technologie logique adoptée (Oracle, PostgresSQL, MongoDB, HBase…).
Nous détaillons les deux niveaux d’abstraction conceptuel et logique sur lesquels nos travaux de thèse sont focalisés.
Niveau conceptuel
Différents concepts sont définis pour représenter les données multidimensionnelles. Les sujets d’analyse (appelés faits), regroupent un ensemble d’indicateurs (appelés mesures). Les valeurs de ces indicateurs sont observables selon des axes d’analyse (appelés dimensions). Ces dimensions sont constituées de différents niveaux de détail, eux-mêmes organisés en hiérarchies ; par exemple, nous pourrions analyser le fait ventes au travers d’une mesure montant, ces montants pouvant être observés en fonction d’une dimension temps constituée de trois niveaux de détails (jour, mois, année) organisés au sein d’une hiérarchie définissant le jour comme un niveau de détail inférieur au mois, lui-même inférieur à l’année. Ces différents concepts permettent de concevoir des schémas multidimensionnels, appelés constellation. Les dimensions peuvent ainsi être partagées entre les faits. Un cas particulier consiste à ramener la constellation à un seul fait, on parle alors de schéma en étoile (star schema) [Kimball and Ross 2011].
Niveau logique
Plusieurs modèles logiques ont été proposés pour convertir les schémas en constellation.
− L’approche R-OLAP consiste à utiliser le modèle relationnel pour représenter un schéma en constellation [Vassiliadis and Sellis 1999] [Morfonios et al. 2007]. Elle est de loin l’approche la plus utilisée. Ce modèle traduit chaque fait dans une table appelée table de fait. Chaque dimension est traduite dans une table appelée table de dimension. Dans la table de fait on retrouve les attributs représentants les mesures d’activités et les attributs les clés étrangères permettant la relation avec chacune des tables de dimensions. La table de dimension est constituée des paramètres et de la clé primaire (il est possible de normaliser les tables de dimensions constituant ainsi un schéma en flocon).
− L’approche M-OLAP consiste à utiliser un système dédié où les données sont organisées sous forme de tableaux multidimensionnels formant des hypercubes de données. Chaque arrête de l’hypercube correspond à une dimension et les cellules correspondent au fait.
− L’approche H-OLAP vise à cumuler les avantages des deux approches précédentes. Les données agrégées sont stockées sous formes multidimensionnelles tandis que les données détaillées sont stockées dans des structures relationnelles.
Exemple. Nous illustrons ci-dessous un exemple basé sur l’approche la plus connue, R-OLAP. Dans cet exemple, on observe le fait Tweet décrit selon quatre dimensions (Time, Subject, Location et User).
L’OLAP ET LE NOSQL
De nos jours, l’augmentation du volume des données atteint des proportions critiques. Ces données massives remettent en cause les approches traditionnelles des entrepôts de données. En effet, les solutions actuelles de construction des entrepôts de données, reposent essentiellement sur ces Systèmes de Gestion de Bases de Données Relationnelles (SGBDR) [Codd 1970]. Ces approches s’avèrent difficilement extensibles aux mégadonnées.
Architectures distribuées
Avec l’essor des grandes plateformes Web (e.g. Google, Facebook, Twitter, Amazon), ont été développées ces dernières années des solutions de gestion des mégadonnées basées sur des approches décentralisées permettant la gestion et le stockage de gigantesques masses de données. Cette approche décentralisée repose sur le principe de la scalabilité, c’est à dire l’ajustement d’une manière progressive et continue du stockage et des traitements à la volumétrie des données collectées. Fonctionnellement, cette solution se traduit par :
− Une distribution du stockage : Une répartition des données sur un ensemble de machines appelés nœuds, l’ensemble des nœuds constituant un cluster. La distribution doit aussi assurer un mécanisme de disponibilité continue des services.
− Une distribution du traitement : Une distribution du traitement sur l’ensemble des machines de sorte à réduire le temps de réponse.
De ce fait, il est envisageable de construire des entrepôts de données massives reposant sur ce principe de scalabilité de l’espace de stockage [Cuzzocrea et al. 2013] [Bellatreche et al. 2015]. La chute du coût de stockage depuis les années 2000 (moins d’un euro le gigaoctet) en fait une solution capable d’absorber de très gros volumes de données à moindre coût. Ce type d’architecture distribuée a connu récemment le développement de systèmes de gestion de fichiers massivement distribués (le plus connu est probablement Hadoop [Anderson et al. 2010]) et de nouvelles techniques de parallélisation massive des traitements (Map/Reduce [Dewitt and Stonebraker 2008]).
Adossés à ce contexte de distribution massive différents systèmes de stockage sont apparus ces dernières années. Ces systèmes, qualifiés de systèmes not-only-SQL ou NoSQL relaxent les fondements de l’approche relationnelle pour pouvoir supporter les masses de données distribuées.
Les modèles NoSQL
Les modèles NoSQL sont de nouveaux moteurs de stockage qui emploient une architecture distribuée capable de traiter de gros volume de données. Ils présentent une nouvelle alternative à l’approche classique R-OLAP pour l’entreposage des données multidimensionnelles.
Les systèmes NoSQL peuvent être classés en quatre catégories, correspondant à différents paradigmes de modélisation [Morfonios et al. 2007a].
– Le modèle clé-valeur [Dey et al. 2013] consiste à modéliser les données de manière très déstructurée par une clé servant à identifier les données et une valeur. Les structures soujacentes de la valeur ne sont pas gérées par le système ; elles sont renvoyées à la charge de l’application cliente.
– Les trois autres modèles introduisent des éléments complémentaires pour mieux structurer la valeur, au niveau du système de gestion de données, et permettre la mise en place d’index. Le modèle orienté documents [Chodorow 2013] repose sur une structuration horizontale, par imbrication de données, appelées documents. De manière orthogonale, le modèle orienté colonnes [Cattell 2011] [Moniruzzaman and Hossain 2013] structure les données verticalement, par regroupement de colonnes en familles de colonnes. Enfin, le modèle orienté graphes [Holzschuher and Peinl 2013] est spécialisé dans la structuration de données en noeuds et relations formant un graphe.
Ces systèmes ont pour caractéristique commune le principe de. Ce principe consiste à ne plus avoir un schéma commun à un ensemble de données au sein d’une même structure [Scherzinger et al. 2013] [Störl et al. 2015].Chaque donnée à son propre schéma, indépendamment des autres. Par conséquent la notion des contraintes d’intégrité sur les structures de données n’est plus ou peu assurée par ces systèmes.
|
Table des matières
INTRODUCTION
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é documents
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
CONCLUSION
