Modèle multidimensionnel et OLAP sur architecture de grille

Transcription

1 N d'ordre 2009-ISAL-0002 Année 2009 Thèse Modèle multidimensionnel et OLAP sur architecture de grille Présentée devant L'institut National des Sciences Appliquées de Lyon Pour obtenir Le grade de docteur Spécialité Informatique École doctorale École doctorale Informatique et Information pour la Société Par Pascal Wehrle Jury MM. J. Darmont Professeur à l'université Lyon 2 H. Kosch Professeur à l'université de Passau (Rapporteur) N. Melab Professeur à l'université Lille 1 M. Miquel Maître de Conférences HDR à l'insa de Lyon (Directrice de thèse) F. Ravat Maître de Conférences HDR à l'université de Toulouse 1 (Rapporteur) A. Tchounikine Maître de Conférences à l'insa de Lyon (co-directrice de thèse) LIRIS - Laboratoire d'informatique en Image et Systèmes d'information

2

3 Remerciements : Tout d'abord je tiens à remercier sincèrement toutes les personnes qui m'ont accompagné durant la réalisation de ce long mais passionnant travail de thèse. Je souhaite remercier tous les membres du jury pour leurs l'intérêt qu'ils portent à mon travail, en particulier Prof. Harald Kosch et Dr. Franck Ravat pour leurs remarques constructives qui m'ont permis d'améliorer mon travail. Merci aussi à Jérôme Darmont et Nouredine Melab d'avoir accepté de faire partie de mon jury. Merci à mes encadrantes et co-directrices de thèse Maryvonne Miquel et Anne Tchounikine de m'avoir donné la chance d'entreprendre ce travail de thèse et de s'être investi autant pour orienter et encourager le long processus de recherche qui m'a permi d'explorer de nombreuses pistes scientifiques. Je leur suis très reconnaissant d'avoir dirigé mes efforts de façon ciblée tout en me laissant une grande autonomie jusqu'à l'aboutissement de ce projet. Merci également à Robert Laurini d'avoir été mon directeur de thèse pendant les deux premières années et d'avoir suivi et encouragé mon travail. Merci à tous les participants du projet GGM pour des moments inoubliables de travail, d'échanges fructueux et de détente tout au long du projet. Merci également à tous les membres de mon équipe et tous ceux qui m'ont entouré et accompagné au quotidien au laboratoire LIRIS et qui m'ont aidé par leur présence et leur soutien, en particulier Jean-Sébastien, Ny Haingo, Sandro, Julien, Romuald, Yonny, les stagiaires Damien et Michaël pour leur aide précieuse dans la conception du prototype, Ruggero, Karla, Enzo, Yann, Claudia, Sana, Frédéric et tous les autres. Je remercie de tout cœur ma chère Estelle d'avoir cru en moi et de m'avoir encouragé depuis le début, malgré les contraintes et à travers tous les passages difficiles jusqu'à l'aboutissement de ce grand projet pour moi. Enfin, je tiens à remercier toute ma famille pour leur soutien permanent, leurs encouragements intarissables et leur confiance en moi.

4

5 Résumé : Les entrepôts de données et les systèmes OLAP (OnLine Analytical Processing) permettent un accès rapide et synthétique à de gros volumes de données à des fins d'analyse. Afin d'améliorer encore les performances des systèmes décisionnels, une solution consiste en la mise en œuvre d'entrepôts de données sur des systèmes répartis toujours plus puissants. Les grilles de calcul en particulier offrent d'importantes ressources de stockage et de traitement. Le déploiement d'un entrepôt sur une infrastructure décentralisée de grille nécessite cependant l'adaptation du modèle multidimensionnel et des processus OLAP pour tenir compte de la répartition et de la réplication des données et de leurs agrégats. Nous introduisons un modèle d'identification des données de l'entrepôt réparti et une méthode d'indexation des données sous forme de blocs multidimensionnels. Cette structure d'index s'appuie sur des index spatiaux en X-tree et des treillis de cuboïdes, et permet la localisation des données matérialisées ainsi que des agrégats calculables sur les différents nœuds de la grille. Nous proposons une méthode de traitement de requêtes OLAP visant à construire un plan d'exécution optimisé à partir de la liste des blocs candidats contribuant au résultat de la requête. Enfin, nous définissons une architecture de services de grille GIROLAP (Grid Infrastructure for Relational OLAP), intégrée à l'intergiciel Globus, et déployée dans le cadre du projet GGM (Grille Géno-Médicales) de l'aci «Masse de Données». MOTS-CLÉS : entrepôt de données, grille de calcul, indexation multidimensionnelle, requêtage OLAP, architecture de services

6

7 Sommaire Table des matières CHAPITRE 1 INTRODUCTION Systèmes OLAP : des systèmes centralisés vers les systèmes distribués Motivations Eléments de la solution explorée Un exemple applicatif Problématiques Déployer des données multidimensionnelles sur une grille Interroger un entrepôt sur grille Exécuter une requête Définir des services de grille Contributions Structure du document... 8 CHAPITRE 2 ÉTAT DE L'ART Entrepôts de données et OLAP Fondements Le modèle multidimensionnel Dimensions et hiérarchies de dimension Faits, mesures et agrégats Représentation d'un modèle multidimensionnel Hypercube et treillis de cuboïdes Architecture fonctionnelle d'un système OLAP Architecture trois tiers Modèles de stockage Stockage des données de l'entrepôt Stockage des données de l'hypercube Les grilles de calcul Définition Infrastructure de grille Intégration de données L'approche médiation L'approche répartition et réplication Bases de données sur grille Entrepôts de données en environnement distribué Fragmentation d'un entrepôt Politiques de placement des fragments Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon ii

8 Sommaire 3.3 Entrepôts sur bases de données distribuées Entrepôts sur infrastructures de grille Discussion et conclusion...32 CHAPITRE 3 MODELISATION, IDENTIFICATION ET INDEXATION DES DONNEES MULTIDIMENSIONNELLES MATERIALISEES SUR GRILLE Cas d'utilisation Un modèle conceptuel de données multidimensionnelles réparties Schéma et instance de dimension Faits et agrégats répartis Instances locales de dimension Ordonnancement des membres de dimension Identification de données multidimensionnelles Définition et identification de «chunks» de données Construction de blocs de chunks Indexation de données multidimensionnelles Index T sur les différents niveaux d'agrégation Index X sur les blocs de chunks Opérations sur l'index TX Insertion dans l'index TX Suppression dans l'index TX Conclusion...67 CHAPITRE 4 INTEGRATION ET GESTION DES AGREGATS CALCULABLES Principes d'obtention des agrégats calculables Construction de blocs de chunks calculables Fusion géométrique de blocs de chunks Parties utiles pour l'obtention du bloc calculable Plans de calcul associés aux blocs calculables Indexation dynamique des agrégats calculables Insertion des blocs calculables dans l'index TX Suppression des blocs calculables dans l'index TX Conclusion...87 CHAPITRE 5 EXECUTION ET OPTIMISATION DE REQUETES Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon ii

9 Sommaire 1 Cas d'utilisation Présentation générale des phases de traitement de requêtes Réécriture de la requête client Localisation des données utiles pour la requête Principe général Algorithme de localisation des données Calcul de la contribution des blocs et mise à jour de la requête Mise à jour des plans de calcul Création de plan de calcul pour blocs matérialisés Mise à jour du plan de calcul des blocs calculables Plan d'exécution et optimisation de l'exécution Calcul des estimations de coûts Estimation des coûts pour les blocs matérialisés Estimation des coûts pour des blocs calculables Construction d'un plan d'exécution de requêtes optimisé Mesure de la contribution au résultat pour les blocs candidats Algorithme glouton pour la construction du plan d'exécution Exécution parallèle et distribuée de requêtes Ordonnancement des tâches de transfert et de calcul Surveillance de l'exécution et assemblage du résultat Surveillance et mise à jour du statut de l'exécution Assemblage du résultat Conclusion CHAPITRE 6 LE PROTOTYPE GIROLAP (GRID INFRASTRUCTURE FOR RELATIONAL OLAP) Présentation des services de grille GIROLAP pour l'entrepôt distribué Services d'accès aux données et de calcul fournis par le Globus Toolkit Service d'identification des données multidimensionnelles : «Dimension Manager» (DM) Fonctionnalités Interaction avec les autres services Service d'indexation locale : «Local Indexing Service» (LIS) Fonctionnalités Interaction avec les autres services Service de recherche de chunks : «Chunk Resolution Service» (CRS) Fonctionnalités Interaction avec les autres services Service de catalogue des blocs de chunks : «Chunk Localization Array Catalog» (CLAC) Fonctionnalités Interaction avec les autres services Service de surveillance de la grille : «Network Distance Service» (NDS) Fonctionnalités Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon iii

10 Sommaire Interaction avec les autres services Service de gestion de l'exécution de requêtes : «Query Execution Management Service» (QEMS) Fonctionnalités Interaction avec les autres services Interface client OLAP Fonctionnalités Interactions Déploiement des services Nœud de stockage et de calcul GIROLAP Nœuds pour services de catalogue et de surveillance Nœuds d'accès pour l'interrogation décentralisée de l'entrepôt Déroulement du traitement de requête Réécriture Recherche locale Localisation au niveau de la grille Optimisation et exécution distribuée Conclusion CHAPITRE 7 CONCLUSION ET PERSPECTIVES Bilan et contributions Modèle formel d'identification et d'indexation des données multidimensionnelles réparties Exécution et Optimisation de requêtes L'architecture de services GIROLAP (Grid Infrastructure for Relational OLAP) Limites et perspectives Gestion et maintenance des données de l'entrepôt réparti Maintenance et adaptation des structures d'index TX en fonction de l'évolution de l'entrepôt réparti Evolution et optimisation de la méthode de traitement de requêtes Réalisation et intégration des méthodes par l'architecture de services de grille GIROLAP ANNEXE A ALGORITHMES ANNEXE B EXEMPLES DETAILLES ANNEXE C SCENARIO DE TEST SUR L'ENTREPOT GGM Scénario de test sur l'entrepôt GGM Fragmentation du schéma en étoile centré patient Fragmentation et déploiement de la table de faits Matérialisation d'agrégats pré-calculés Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon iv

11 Sommaire 1.4 Répartition et indexation des blocs matérialisés Catégories de requêtes distribuées BIBLIOGRAPHIE Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon v

12 Sommaire Liste des figures Figure 1.1 : Schéma de l'architecture de services pour le projet GGM... 4 Figure 2.1 : Comparaison entre systèmes OLTP et OLAP (Kelly, 1997) Figure 2.2 : Schéma et instance de la dimension «lieu de naissance» Figure 2.3 : Schéma et instance non normalisée de la dimension «pathologie» Figure 2.4 : Schéma et instance normalisée de la dimension «pathologie» Figure 2.5 : Notation inspirée de MultiDimER pour la description des modèles multidimensionnels d'entrepôts Figure 2.6 : Hypercube à trois dimensions Figure 2.7 : Treillis de cuboïdes OLAP pour 3 dimensions hiérarchisées Figure 2.8 : Architecture d'un système OLAP Figure 2.9 : Exemples de Clients OLAP Figure 2.10 : Modèle MultiDimER d'une vue orientée «ventes» sur un entrepôt Figure 2.11 : Schéma en étoile de l'entrepôt «ventes» Figure 2.12 : Schéma en flocon de l'entrepôt «ventes» Figure 2.13 : Schéma en constellation de l'entrepôt «ventes» Figure 2.14 : Architecture de services en couches d'une grille Figure 2.15 : Architecture du service de médiation GDMS (Brezany et al., 2003) Figure 3.1 : Schéma conceptuel de l'entrepôt centré Patient Figure 3.2 : Interfaces client dans l'architecture d'entrepôt réparti sur grille Figure 3.3: Schéma et extrait de l'instance de la dimension «lieu» Figure 3.4: Schéma et extrait de l'instance de la dimension «temps» Figure 3.5: Extrait de l'instance de la dimension «pathologie» Figure 3.6 : Table de faits «patient» fragmentée pour être répartie sur 3 nœuds de la grille selon les critères des 3 groupes d'utilisateurs associés à ces nœuds 42 Figure 3.7 : Exemple d'une table d'agrégat aux niveaux {région, année, pathologie} Figure 3.8 : Table d'agrégat «patient-région-année» fragmentée pour être répartie sur les nœuds A et B de la grille Figure 3.9 : Instances locales des dimensions «lieu» et «temps» pour le nœud de grille A Figure 3.10 : Intervalles de membres représentant des données équivalentes sur différents niveaux hiérarchiques Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon vi

13 Sommaire Figure 3.11 : Instance ordonnée de la dimension «lieu» Figure 3.12 : Ordres propagés de l'instance ordonnée de la dimension «pathologie» Figure 3.13 : Lien entre un ensemble de chunks et un chunk agrégé en deux dimensions Figure 3.14 : Bloc de chunks contigus dans la table de faits «patient» Figure 3.15 : Index en treillis de blocs matérialisés Figure 3.16 : Index TX associant les sommets de l'index T en treillis et blocs de chunks dans l'espace multidimensionnel Figure 3.17 : Représentation spatiale des blocs aux niveaux {ville,date,path-0} Figure 3.18 : Structure du X-tree hébergeant les blocs indexés aux niveaux {ville,date,path-0} Figure 3.19 : Structure de l'index X spatial hébergeant les blocs au niveaux {ville,date,path-0} Figure 3.20 : Opération d'insertion sur l'index TX Figure 3.21 : Opération de suppression sur l'index T Figure 4.1 : Fusion de blocs de chunks adjacents dans la dimension «temps» 74 Figure 4.2 : Fusion de blocs de chunks dans les dimensions «temps» et «lieu» Figure 4.3 : Blocs sources fusionnés dans la dimension «temps» pour créer un bloc calculable aux niveaux {ville, mois, path-0} Figure 4.4 : Eléments sources d'un bloc calculable sur l'index X du nœud LYON Figure 4.5 : Index TX après insertion d'un bloc matérialisé avant la mise à jour des blocs calculables dans les dimensions «lieu» et «temps» Figure 4.6 : Index TX après l'insertion des blocs calculables dépendants uniquement de b Figure 4.7 : Insertion d'un bloc calculable issu de la fusion de deux blocs source dans l'index TX Figure 4.8 : Mise à jour d'un bloc calculable suite à la suppression d'un bloc matérialisé Figure 5.1 : Identifiants de blocs matérialisés sur le nœud LYON Figure 5.2 : Identifiants de blocs matérialisés sur le nœud TOULOUSE Figure 5.3 : Identifiants de blocs matérialisés sur le nœud LILLE Figure 5.4 : Intersections dans l'espace de données entre une requête et deux blocs de chunks matérialisés sur le nœud destination Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon vii

14 Sommaire Figure 5.5 : Calcul de la contribution du premier bloc à la requête et mise à jour de l'ensemble des données manquantes Figure 5.6 : Calcul de la contribution du deuxième bloc à la requête et finalisation de l'ensemble des données manquantes Figure 5.7 : Découpage d'une requête portant sur les blocs indexés du nœud LILLE Figure 5.8 : Eléments d'un plan de calcul créé pour un bloc candidat matérialisé sur le nœud LYON Figure 5.9 : Extraction partielle d'un plan de calcul d'un bloc calculable en fonction d'une requête sur le nœud LYON Figure 5.10 : Bloc candidat matérialisé sur le nœud LILLE pour une requête soumise au nœud TOULOUSE Figure 5.11 : Recouvrement de la requête b* r sur le nœud LYON Figure 5.12 : Phases de lancement des différentes tâches du plan d'exécution distribué Figure 5.13 : Plan d'exécution distribué optimisé pour la requête b* r Figure 6.1 : Déploiement exemple des services de l'architecture GIROLAP. 126 Figure 6.2 : Représentation des identifiants de blocs et de leur intersection Figure 6.3 : Visualisation en deux dimensions de la structure de l'index TX sur un nœud Figure 6.4 : Phase de localisation de chunks exécutée par le service de recherche de chunks Figure 6.5 : Client graphique Java du service NDS (Gossa et al., 2006) Figure 6.6 : Phase de localisation supervisée par le service de gestion de l'exécution de requêtes Figure 6.7 : Interface graphique JPivot avec table de pivot montrant un hypercube de l'entrepôt GGM Figure 6.8 : Types de nœuds au sein du déploiement exemple des services GIROLAP Figure 6.9 : Déroulement de la recherche locale de chunks sur un nœud Figure 6.10 : Localisation de blocs de chunks manquants sur la grille Figure 6.11 : Optimisation de la liste des blocs candidats et exécution distribuée Figure B.1 : Recherche locale sur le nœud LYON suite à une requête b* r Figure B.2 : Recherche sur le nœud TOULOUSE suite à la requête b* rm Figure B.3 : Recherche sur le nœud LILLE suite à la requête b* rm Figure C.1 : Vue centrée patient du schéma de l'entrepôt GGM Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon viii

15 Sommaire Liste des tableaux Tableau 5.1 : Paramètres d'exploitation de la grille à la base des exemples du chapitre Tableau 5.2 : Trace d'exécution de l'algorithme pour la construction de M Tableau 6.1 : Nom et fonctionnalités mises à disposition par chaque service de grille Tableau C.1 : Fragments de la table de faits «Patient» sous forme de blocs de chunks Tableau C.2 : Blocs de chunks agrégés matérialisés en plus des chunks détaillés Tableau C.3 : Requêtes portant sur les chunks matérialisés déployés sur la grille GGM Tableau C.4 : Requêtes portant sur les chunks calculables sur la grille GGM 176 Tableau C.5 : Requêtes portant sur les chunks matérialisés et calculables sur la grille GGM Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon ix

16 Liste des définitions Définition 3.1 : Schéma de dimension Définition 3.2 : Instance de dimension Définition 3.3 : Table de faits Définition 3.4 : Fragment de table de faits Définition 3.5 : Table d'agrégat Définition 3.6 : Fragment de table d'agrégats Définition 3.7 : Instance locale de dimension Définition 3.8 : Relation d'ordre propagée descendante Définition 3.9 : Relation d'ordre propagée ascendante Définition 3.10 : Instance de dimension ordonnée Définition 3.11 : Chunk de données multidimensionnelles Définition 3.12 : Bloc de chunks Définition 3.13 : Index T en treillis de niveaux d'agrégation Définition 3.14 : Index X des données multidimensionnelles Définition 4.1 : Fusion de blocs de chunks Définition 4.2 : Plan de calcul associé à un bloc de chunks calculable... 78

17 Liste des exemples Exemple 2.1 : Normalisation d'instances de dimension irrégulières Exemple 3.1 : Schémas et instances des dimensions de l'entrepôt centré Patient Exemple 3.2 : Fragmentation de la table de faits d'un entrepôt modélisé en étoile Exemple 3.3 : Fragmentation d'une table d'agrégat Exemple 3.4 : Instance locale de dimension sur un nœud de la grille Exemple 3.5 : Ordonnancement d'instances de dimension Exemple 3.6 : Identification d'un bloc de chunks Exemple 3.7 : Construction d'un index en treillis de niveaux d'agrégation Exemple 3.8 : Indexation spatiale au sein d'un sommet de l'index T Exemple 3.9 : Insertion d'un identifiant de bloc de chunks dans l'index TX Exemple 3.10 : Suppression d'un identifiant de bloc de chunks dans l'index TX Exemple 4.1 : Fusion de blocs de chunks Exemple 4.2 : Parties utiles de blocs sources associées à un bloc de chunks calculable Exemple 4.3 : Plan de calcul associé à un bloc calculable Exemple 4.4 : Mise à jour de l'index TX suite à l'insertion d'un bloc matérialisé Exemple 4.5 : Mise à jour d'un bloc calculable dans l'index TX suite à la suppression d'un bloc matérialisé Exemple 5.1 : Construction de requêtes portant sur les chunks recherchés Exemple 5.2 : Création d'un plan de calcul pour blocs candidats matérialisés sur nœuds distants Exemple 5.3 : Mise à jour du plan de calcul pour les blocs candidats calculables Exemple 5.4 : Estimation des coûts pour bloc de chunks matérialisé Exemple 5.5 : Construction progressive d'un plan d'exécution optimisé Exemple 5.6 : Ordonnancement des tâches d'un plan d'exécution distribué optimisé

18

19 Chapitre 1 Introduction L'informatique décisionnelle constitue un domaine évoluant en permanence. Depuis la définition du concept d'entrepôt de données par William H. Inmon (Inmon, 1992), le marché des solutions décisionnelles basées sur les entrepôts et outils OLAP (OnLine Analytical Processing) s'est fortement développé pour atteindre un volume de 7 milliards de dollars en 2007 (Vesset et al., 2008). Les secteurs de l'analyse en ligne OLAP et des analyses avancées de données du type fouille de données connaissent une croissance particulièrement marquée. L'informatique décisionnelle constitue une thématique majeure dans le monde de l'industrie et de la recherche. 1 Systèmes OLAP : des systèmes centralisés vers les systèmes distribués 1.1 Motivations Avec le succès des solutions décisionnelles, vient l'augmentation des exigences de service et d'usage. Ainsi, le volume de données à entreposer augmente en même temps que les temps de réponse sont contraints de diminuer. De plus, la diversification des domaines d'application exige des méthodes d'analyse de plus en plus complexes, notamment pour les applications scientifiques comme par exemple la bioinformatique. De nouveaux modèles et de nouvelles approches technologiques doivent être développés pour s'adapter aux nouvelles exigences. Il est naturel, pour des entreprises qui sont de plus en plus constituées de réseau de petites ou moyennes structures réparties géographiquement, de s'adosser à des Systèmes d'information (SI) distribués. Pour des raisons de performance et de disponibilité, les données sont généralement maintenues et gérées là où elles sont produites, puis mises à disposition des entités distantes via des réseaux étendus. La constitution d'un entrepôt de données, même dans le cas d'un SI distribué, reste cependant avant tout un processus de centralisation : les données pertinentes sont extraites des différents sites, puis homogénéisées et agrégées dans un entrepôt puis dans un hypercube mono-site. Cependant, cette solution pose d'une part des problèmes de scalabilité, en termes de volume et de complexité des traitements, et d'autre part ne respecte pas la nature locale des données, en termes de propriété, de confidentialité et de disponibilité. Enfin un entrepôt centralisé ne favorise pas la gestion de toujours plus d'utilisateurs, se connectant à distance, et ayant des besoins différents en matière de données et d'outils d'analyse. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 1

20 1 Introduction 1.2 Eléments de la solution explorée Une des approches pour répartir la charge que représente le stockage d'un entrepôt de données et les traitements associés consiste à s'appuyer sur les solutions mises en œuvre dans le domaine des bases de données distribuées. Notons que les traitements impliqués dans la chaîne décisionnelle concernent à la fois le processus d'extraction et de transformation qui alimente l'entrepôt et l'exécution de requêtes OLAP. Alors que l'alimentation survient généralement de manière invisible à l'utilisateur lors de périodes de maintenances fixes, l'interrogation de l'entrepôt par des outils OLAP demande une réactivité importante. En effet, la navigation interactive à travers l'hypercube OLAP engendre de nombreuses opérations d'agrégation sur des ensembles de données choisies arbitrairement et dynamiquement par l'utilisateur. Afin d'assurer des temps de réponse minimaux, le déploiement de l'entrepôt sur un système distribué doit optimiser la répartition des données et la parallélisation des traitements liés aux requêtes. Les travaux existants mettent en œuvre des méthodes de partitionnement déjà éprouvées dans le domaine des bases de données distribuées (Mehta et al., 1997), (Poess et al., 2005). Les données de l'entrepôt sont réparties en parties de taille égale et réparties uniformément sur les nœuds du système. Le contrôle sur les ressources de stockage et la gestion des requêtes restent centralisées. Cette solution présente des limites, en particulier liées au maintien de la gestion centralisée de l'entrepôt. Un tel système ne fait essentiellement que déléguer le stockage de l'entrepôt à une base de données distribuée, alors que les métadonnées décrivant le modèle multidimensionnel de l'entrepôt sont regroupées sur un nœud «maître». L'ensemble des nœuds «esclaves» est constitué de systèmes dédiés de capacité identique facilement accessibles et gérables. Alors que cette configuration permet une bonne maîtrise des processus de stockage et de traitements, elle limite cependant les possibilités de passage à l'échelle et de réorganisation au sein de l'entrepôt. Le traitement distribué de requêtes s'effectue selon le même principe, les nœuds «esclaves» exécutant des parties d'opérations qui sont planifiées, déclenchées et gérées par une instance unique. De plus, cette instance de contrôle centralisée constitue un goulot d'étranglement par lequel doivent passer toutes les requêtes utilisateurs. Ces limites sont de nature conceptuelle et nécessitent de nouvelles approches pour les surmonter. Une des voies les plus prometteuses dans ce contexte est l'utilisation de grilles de calcul. En effet, une grille coordonne un ensemble de ressources hétérogènes qui ne sont ni saisies ni contrôlées de manière centralisée. L'intergiciel de grille organise l'utilisation de ces ressources mises à disposition à travers un réseau étendu. Des ressources peuvent être ajoutées et supprimées à la grille de manière dynamique, ce qui permet d'adapter les capacités de stockage et de calcul en fonction des besoins et des disponibilités. Un entrepôt de données déployé sur une grille reste ainsi modifiable et donc capable de répondre à des exigences variables. De plus, la grille opère de manière entièrement décentralisée, chaque nœud gérant lui-même l'utilisation et l'accès des ressources dont il dispose. Dans un entrepôt réparti sur une grille, la répartition Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 2

21 1 Introduction des données et des calculs peut donc être adaptée à la capacité mise à disposition par chaque nœud. Il s'agit également de décentraliser la gestion des métadonnées de l'entrepôt afin d'éviter de dépendre d'une instance unique du modèle multidimensionnel. Ainsi, le traitement de requêtes OLAP peut s'effectuer depuis n'importe quel nœud, chaque nœud ayant accès à l'information et aux ressources nécessaires à la planification et à l'exécution de requêtes. Une telle configuration est plus facilement capable d'assurer un service accessible et fiable pour un grand nombre d'utilisateurs dans un environnement hautement distribué. 1.3 Un exemple applicatif Le contexte applicatif des travaux que nous présentons dans ce document est le projet de recherche «Grille Géno-Médicale» (GGM), financé par l'aci «Masse de données». Le projet GGM est une collaboration nationale incluant l'équipe «Optimisation Parallèle Coopérative» de l'inria Dolphin à Lille, l'équipe «Optimisation dynamique de requêtes réparties à grande échelle» de l'irit à Toulouse et les équipes «Systèmes d'information Spatio-Temporels et Entreposage» et «Systèmes d'information Pervasifs» du LIRIS à Lyon. Les problématiques scientifiques et l'approche retenue sont détaillées par (Pierson et al., 2005) et (Pierson et al., 2007). La motivation à l'origine du projet est le manque de solutions permettant de partager et d'exploiter efficacement les grands volumes de données produits par des méthodes d'analyse protéomiques et génétiques dans le domaine médical (Brunie et al., 2003). L'objectif est donc de proposer une architecture logicielle pour la gestion et l'analyse de données géno-médicales complexes sur grille de calcul. Les données traitées sont des données issues d'expériences mesurant l'expression de gènes sur biopuces, associées aux dossiers médicaux informatisés des patients concernés. Le concept d'entrepôt réparti sur cette grille est essentiel pour apporter des capacités de gestion de ces données génomédicales hétérogènes et dynamiques, permettant ainsi l'exécution distribuée de traitements et d'analyses complexes sur ces données. Le projet est divisé en plusieurs domaines qui traitent les problématiques associées aux différentes unités fonctionnelles de l'architecture. La figure 1.1 illustre l'architecture de services proposée dans le cadre du projet GGM. L'unité fonctionnelle que représente l'entrepôt de données réparti a une place centrale car il interagit directement avec le service de requêtes qui prend en charge l'exécution des requêtes sur les données qui sont ensuite livrées au service de fouille de données. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 3

22 1 Introduction Interface Utilisateur Monitoring Fouille de Données GGM Entrepôt de Données Réparti Exécution de Requêtes Cache collaboratif mandataire Middleware de Grille BD patients BD publiques BD génétiques Figure 1.1 : Schéma de l'architecture de services pour le projet GGM Le service de fouille de données est donc le client de l'entrepôt de données réparti. A partir de populations de patients sélectionnées dans l'entrepôt par des requêtes OLAP, une analyse approfondie par fouille de données est effectuée. Cet aspect est l'objet du travail de l'équipe «Optimisation Parallèle Coopérative» de l'inria Dolphin à Lille, présenté dans (Melab et al., 2006). Les services de monitoring et de caches collaboratifs sont situés directement en amont de l'intergiciel de grille et font partie du travail de l'équipe «Systèmes d'information Pervasifs» du LIRIS à Lyon. Le service de cache collaboratif a pour objectif d'optimiser et de gérer activement l'utilisation des ressources de stockage tout en fournissant un accès transparent aux données. Ce système est détaillé dans (Cardenas et al., 2006). Un service de monitoring capable de fournir des mesures détaillées sur l'état de la grille délivre les informations nécessaires à l'optimisation des requêtes a priori par l'entrepôt de données et au fil de l'exécution par le service de requêtes. Ce service est décrit dans (Gossa et al., 2006). Enfin, le service de requêtes présenté par (Hussein et al., 2006) gère l'exécution optimisée des requêtes faites d'opérations de sélection, projection et de jointure (SPJ). Ce sont des agents mobiles autonomes qui optimisent l'exécution en fonction des conditions de charge variables au sein d'une grille. Chaque agent dispose d'un plan d'exécution établi et optimisé avant exécution par l'entrepôt de données réparti. Ces problématiques sont l'objet du travail de l'équipe «Optimisation dynamique de requêtes réparties à grande échelle» de l'irit à Toulouse. 2 Problématiques Les problématiques associées aux solutions décisionnelles déployées sur grille concernent d'une part la répartition des données multidimensionnelles sur plusieurs nœuds autonomes, et d'autre part l'exécution de requêtes distribuées sur ces données. Alors que le déploiement d'un entrepôt sur un système Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 4

23 1 Introduction distribué maintient généralement l'aspect centralisé de la gestion de données et du traitement de requêtes, l'absence de contrôle sur les systèmes constituant une grille nécessite une approche décentralisée. Les problématiques à résoudre sont détaillées ci-après. 2.1 Déployer des données multidimensionnelles sur une grille Les ressources partagées par chaque système participant à la grille sont hétérogènes en termes de capacité, d'accès et de disponibilité. De plus, l'accès aux fonctionnalités de la grille par des applications clientes est possible depuis un grand nombre de points d'accès. Avant de pouvoir déployer l'entrepôt sur grille, celui-ci doit donc être fragmenté en fonction des besoins des utilisateurs et de l'espace de stockage mis à disposition par les nœuds de grille. Il est nécessaire d'établir une stratégie de placement qui peut prendre en compte des critères comme la pertinence des fragments d'entrepôt, leur fréquence d'accès reflétant leur usage, mais aussi la propriété et la confidentialité des données. Les données ainsi réparties peuvent être également répliquées sur plusieurs nœuds et déplacées en fonction de l'évolution de leur utilisation. Les données de l'hypercube ne sont pas des données «traditionnelles». Elles comportent différents niveaux de détail ; elles peuvent être partiellement matérialisées, et sont calculables à partir de données plus détaillées. Leur mode de stockage physique présente des particularités qui doivent être maîtrisées pour une gestion efficace : elles sont stockées sous forme d'un schéma en étoile dont la pièce centrale est une table de faits qui référence un ensemble de tables de dimension à l'aide de clés étrangères. La clé primaire de la table de fait est formée par la composition des clés étrangères, reliant ainsi chaque fait à un ensemble de membres de dimension faisant partie des métadonnées de l'entrepôt. Enfin, les tables de dimension hébergeant les métadonnées décrivant la structure hiérarchisée des dimensions de l'entrepôt sont dénormalisées. Un entrepôt de données sur grille devra : - être fragmenté sur plusieurs nœuds de la grille, - intégrer des données détaillées, agrégées, matérialisées ou calculables, - s'appuyer sur un modèle multidimensionnel, - comporter des données répliquées, - gérer le déplacement dynamique des données 2.2 Interroger un entrepôt sur grille Afin de pouvoir interroger un entrepôt fragmenté et réparti sur les nœuds d'une grille, la méthode de traitement de requêtes doit prendre en compte plusieurs aspects spécifiques au fonctionnement de la grille. Tout d'abord, les données utiles pour traiter une requête doivent être localisées parmi les nœuds de la grille et peuvent être disponibles de manières différentes et combinables. Les données recherchées peuvent être : - partiellement ou entièrement matérialisées sur le nœud interrogé, - matérialisées et répliquées sur un ou plusieurs autres nœuds de la grille, Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 5

24 1 Introduction - calculables à partir de données matérialisées sur le nœud interrogé, - calculables sur un ou plusieurs autres nœuds de la grille. Pour assurer un accès rapide à ces informations, un index des données disponibles est indispensable. Un index central serait pénalisé par le fonctionnement décentralisé de la grille et difficile à maintenir à jour dans un environnement dynamique. En effet, il ne s'agit pas d'indexer des clés simples, mais les clés multidimensionnelles utilisées par le modèle de l'entrepôt. Ce modèle impose en plus de l'indexation des données détaillées et de leurs agrégats matérialisés, l'intégration des données calculables à partir de ceux-ci. De plus l'index doit pouvoir être mis à jour en fonction des déplacements et réplications fortement dynamiques au sein de la grille. Il est donc indispensable de mettre en place l'indexation des données disponibles au niveau de chaque nœud de grille. L'information sur les données disponibles sur chaque nœud doit cependant rester consultable par les nœuds exécutants des requêtes. Pour accéder aux données pertinentes pour répondre à une requête OLAP, il faudra : - indexer les données matérialisées ou calculables sur l'ensemble des nœuds de la grille, - fournir les fonctionnalités nécessaires à la mise à jour de cet index pour tenir compte de l'évolution de la matérialisation et du placement des données sur la grille. 2.3 Exécuter une requête Afin d'obtenir le résultat d'une requête, un nœud de grille doit pouvoir localiser les parties utiles de l'entrepôt. Il est également nécessaire d'évaluer le coût des opérations de chargement, de calcul et de transfert nécessaires pour chaque partie du résultat. Au sein d'un entrepôt réparti, il existe souvent plusieurs possibilités d'obtenir les données résultat. Il s'agit dans ces cas là de trouver la solution la moins coûteuse parmi ces possibilités et de construire un plan d'exécution optimisé prenant en compte l'ensemble des méthodes pour obtenir les données depuis les sources identifiées. Une requête OLAP est une requête complexe impliquant plusieurs opérations de sélection, de jointure ainsi que des calculs d'agrégation. Les traitements sur une grille de calcul sont exécutés de manière asynchrone, chaque nœud assurant lui-même l'ordonnancement des tâches qui lui sont soumises. Afin de pouvoir bénéficier au maximum d'une parallélisation des calculs et des transferts, le mécanisme qui traite le plan d'exécution doit prendre en compte la nature des requêtes OLAP et l'autonomie des nœuds exécutants pour ordonnancer les opérations en conséquence. Le traitement d'une requête OLAP repose sur : - le recensement des données disponibles sur la grille et des différentes alternatives possibles, - l'élaboration puis l'exécution d'un plan d'exécution optimisé. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 6

25 1 Introduction 2.4 Définir des services de grille Enfin, une solution d'entrepôt réparti dans une infrastructure de grille doit fournir les fonctionnalités de gestion de l'entrepôt sous forme de services de grille. En effet, l'architecture de grille est composée de services organisés en différentes couches superposées (Foster et al., 2003). Standardisées par le «Open Grid Services Architecture» (OGSA), les couches de services assurent les fonctions d'accès, de communication, de coordination et de coopération. Une solution pour l'exploitation d'un entrepôt doit s'intégrer à l'architecture en couches établie en ajoutant des services spécifiques là où les mécanismes existants ne permettent pas de fournir les fonctionnalités requises. L'architecture logicielle d'un entrepôt sur grille devra : - s'appuyer sur un ensemble de service de gestion, - s'intégrer dans un intergiciel de grille existant, de type Globus Toolkit. 3 Contributions Les travaux présentés dans ce document apportent des solutions aux problématiques mentionnées. La base du déploiement d'un entrepôt est fournie par la méthode de fragmentation horizontale de (Bellatreche et al., 1999) qui fournit une répartition adaptée à la demande locale sur chaque nœud d'une grille de calcul. Sur cette base, nous proposons un modèle d'identification unique des données de l'entrepôt reposant sur le schéma du modèle multidimensionnel associé à un ordonnancement des membres de dimension à travers les hiérarchies. Les identifiants logiques ainsi créés permettent de localiser tous les réplicas des fragments de l'entrepôt réparties sur la grille. Chaque nœud de la grille recense l'ensemble des données matérialisées et calculables dont il dispose en construisant un index de ces données. La structure d'index appelé index TX que nous proposons utilise les identifiants des données matérialisées pour les indexer selon leur niveau d'agrégation et leur position dans l'espace de données multidimensionnel. L'index TX est constitué d'un index T qui distingue les niveaux d'agrégation par une structure de treillis et d'un index X spatial qui décrit la position des données dans l'espace multidimensionnel créé à l'aide du modèle de l'entrepôt. Les données calculables à partir des fragments d'entrepôt matérialisés sont intégrées à cet index. L'ensemble des index TX sur les nœuds de la grille fournit ainsi les informations sur les données de l'entrepôt disponibles et les met à disposition des autres nœuds. A partir du modèle et des mécanismes d'indexation introduits, nous développons une méthode d'exécution de requêtes adaptée à un d'entrepôt réparti sur grille. La procédure d'exécution localise les données répondant à une requête à l'aide des informations contenues dans les index locaux et calcule les estimations de coûts dynamiques pour obtenir les données. Ces informations sont utilisées pour sélectionner la solution de moindre coût. Les opérations du plan d'exécution optimisé sont ordonnancées et exécutées en parallèle sur les Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 7

26 1 Introduction nœuds source sélectionnés. Cette méthode permet d'assurer une exécution distribuée tirant profit des capacités de stockage et de calcul distribués mises à disposition par la grille. L'intégration du modèle et des mécanismes conçus dans l'infrastructure de grille est rendue possible par l'architecture de services de grille GIROLAP (Grid Infrastructure for Relational OLAP), basée sur l'infrastructure fournie par l'intergiciel Globus Toolkit. Nous introduisons des services dédiés pour l'indexation locale des fragments de l'entrepôt, la publication et l'échange des informations sur les données disponibles. La gestion de l'exécution de requêtes requiert également un service spécifique qui assure la réécriture et l'optimisation des requêtes client. L'ensemble de ces services assure le bon fonctionnement d'un entrepôt de données issu du projet GGM et déployé sur grille de calcul. 4 Structure du document Ce document est structuré en 7 chapitres : Le chapitre suivant cette introduction est l'état de l'art exposant les travaux existants dans les domaines des entrepôts de données et de la gestion de données distribuées sur grilles. Le chapitre 3 détaille notre modèle multidimensionnel adapté à la gestion d'entrepôts répartis sur grille ainsi que la structure d'indexation des données multidimensionnelles matérialisées. L'index TX que nous proposons est étendu aux agrégats calculables, ce qui fait l'objet du chapitre 4. Au chapitre 5, nous décrivons la méthode d'exécution de requêtes distribuée basée sur le modèle introduit précédemment. L'architecture de services GIROLAP qui réalise et intègre les modèles et méthodes proposés est exposée au chapitre 6 et la conclusion générale avec les perspectives pour de futurs travaux finalement fait l'objet du chapitre 7. En annexe A, nous présentons les algorithmes développés, l'annexe B contient certains exemples détaillés et l'annexe C expose un scénario de test basé sur un cas d'utilisation du projet GGM. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 8

27

28

29 Chapitre 2 État de l'art Les systèmes décisionnels requièrent des ressources de stockage et de traitement de plus en plus performants. Les grilles de calcul apportent de nouvelles solutions pour l'accès décentralisé à un grand nombre de ressources partagées. Nous présentons dans ce chapitre les principes de construction et de fonctionnement des entrepôts de données et des outils d'analyse associés, puis l'architecture fonctionnelle des infrastructures de grille de calcul. Nous décrivons ensuite les travaux relatifs à la répartition d'entrepôt au sein des bases de données distribuées avant de présenter les diverses approches existantes pour la mise en œuvre d'entrepôts de données distribués sur grilles. 1 Entrepôts de données et OLAP Les systèmes d'aide à la décision se fondent généralement sur l'analyse statistique des données accumulées par les systèmes d'information de production. Cependant, ces grands volumes, gérés par des SGBDs classiques, ne sont pas optimisés pour la lecture massive de données et leur modèle de stockage reste peu propice au calcul rapide d'indicateurs synthétiques représentatifs des connaissances recherchées. Les concepts d'entrepôt de données et d'analyse OLAP (OnLine Analytical Processing) sont ainsi nés de la nécessité d'isoler et de tenir à disposition les données pertinentes pour une analyse approfondie de données issues des systèmes d'information de production. 1.1 Fondements W.H. Inmon définit le concept d'entrepôt de données en 1992 comme «une collection de données intégrées, non volatiles et historisées, support de la prise de décisions» (Inmon, 1992). Un entrepôt de données doit permettre de gérer d'importants volumes de données issues de systèmes d'information en production, afin de les mettre à disposition d'outils d'aide à la décision. Cet objectif nécessite de réorganiser les données par rapport à leur organisation dans les bases de données classiques qui sont, elles, conçues pour traiter efficacement les transactions d'ajout ou de mise à jour ainsi que les consultations d'enregistrements au quotidien selon le paradigme OLTP (OnLine Transaction Processing). Le chargement des données dans l'entrepôt est effectué par un processus complexe d'extraction, de transformation et de transfert (ETL - Extract, Transform, Load) qui assure la qualité et la cohérence des données extraites tout en les intégrant au schéma de l'entrepôt. Il est généralement effectué de façon périodique et incrémentielle, c'est-à-dire que les données détaillées existantes dans l'entrepôt ne sont pas modifiées. L'analyse des données est assurée par des outils d'analyse en ligne OLAP. Comme l'illustre le tableau comparatif en figure 2.1, les caractéristiques des applications OLAP Pascal Wehrle/Thèse en informatique/2009/institut national des sciences ap pliquées de Lyon 11

30 2 Etat de l'art sont fondamentalement différentes de celles des applications OLTP. De ce fait, la modélisation des données pour les applications OLAP doit s'appuyer sur un modèle spécifique. Ce modèle est appelé modèle multidimensionnel. OLTP Stockage de données principal pour un système d'information de production Usage opérationnel pour le contrôle et l'exécution de tâches au quotidien Vue instantanée sur l'état du système d'information Requêtes sur peu d'enregistrements, mises à jour fréquentes et de petite taille Partie en exploitation de taille réduite, grands volumes uniquement dans les archives Structure en grand nombre de tables normalisées OLAP Stockage consolidé, extrait principalement des bases OLTP Usage pour la planification, l'analyse de projets et l'aide à la décision Vues historisées et adaptées selon les critères d'analyse Requêtes sur sous-ensembles importants, mises à jour rares et importantes Grands volumes regroupant les données historiques et leurs agrégats consultables par clients Structure en étoile, flocon ou constellation de tables non normalisées Figure 2.1 : Comparaison entre systèmes OLTP et OLAP (Kelly, 1997) 1.2 Le modèle multidimensionnel L'introduction de douze règles définissant les fonctionnalités des systèmes OLAP par E. F. Codd en 1993 (Codd et al., 1993) marque le début du succès des outils d'aide à la décision basés sur les entrepôts de données. Parmi les exigences mises en avant, on note en particulier l'interactivité et la liberté offerte à l'analyste pour adapter la vue sur les données sans dégradation des performances. Pour cela, un entrepôt de données est organisé selon un modèle multidimensionnel de données. Celui-ci est défini par des axes d'analyse nommés «dimensions» et par des objets d'analyse, nommés «faits» et quantifiés par des «mesures». Cette structure multidimensionnelle favorise l'interrogation par un outil OLAP et offre à l'utilisateur une navigation interactive orientée selon les dimensions définies au sein de l'entrepôt Dimensions et hiérarchies de dimension Au niveau conceptuel, une dimension désigne un axe d'analyse qui oriente les requêtes en leur donnant la possibilité d'obtenir une vue différenciée sur les données de l'entrepôt suivant les critères d'analyse fournis par la dimension. Dès la conception d'un entrepôt de données, le modèle multidimensionnel fixe ainsi les possibilités de l'analyse en ligne. Les dimensions d'un modèle multidimensionnel sont constituées de niveaux hiérarchiques distincts. Les liens entre niveaux peuvent avoir des cardinalités Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 12

31 2 Etat de l'art différentes qui caractérisent les relations entre leurs éléments, i.e. les «membres» de dimension. Ces niveaux correspondent aux différents niveaux de détail qu'il est possible d'obtenir à partir des données gérées par l'entrepôt. Cette structure hiérarchisée forme la base de la navigation OLAP dans une dimension et représente le «schéma de la dimension». L'ensemble des membres d'une dimension et des liens entre les membres forment «l'instance de dimension». L'étude des différents types de hiérarchies et de leur gestion est le sujet de nombreux travaux. Ainsi, (Pedersen et al., 1999) et (Malinowski et al., 2006) définissent la classification suivante : - Hiérarchies explicites : Ce type de hiérarchie est décrit explicitement par un schéma de niveaux hiérarchiques. - Hiérarchies multiples : Une hiérarchie multiple comporte plusieurs niveaux alternatifs qui ne sont pas reliés par des liens de filiation directs, ce qui crée plusieurs chemins au sein du schéma de la hiérarchie. - Hiérarchies couvrantes : A chaque niveau de ce type de hiérarchie, les membres couvrent l'ensemble des données de l'entrepôt. Il n'existe donc aucun lien de filiation direct qui «saute» un niveau. - Hiérarchies non-onto : Il existe dans la hiérarchie certains membres qui, sans se trouver au niveau le plus détaillé de la hiérarchie, n'ont pas de descendants. - Hiérarchies strictes : Au sein d'une hiérarchie stricte, il ne peut pas exister de relation de plusieurs à plusieurs entre les membres reliés par des liens de filiation. Cette classification des types de hiérarchies de dimension est basée aussi bien sur la définition de la hiérarchie de dimension exprimée par son schéma que sur l'instance de dimension composée des membres de cette dimension. Les classes de hiérarchies introduites ne sont donc ni exhaustives, ni mutuellement exclusives. Il s'agit de fournir des notions qui caractérisent les irrégularités présentes au sein des hiérarchies de dimension. Les hiérarchies non couvrantes, non-onto et/ou non strictes sont difficiles à gérer par les systèmes OLAP à cause de leurs structures complexes. Il existe ainsi plusieurs méthodes de «normalisation» qui permettent de transformer les hiérarchies irrégulières afin de faciliter leur traitement. Un exemple de ces méthodes décrites par (Pedersen et al., 1999) et (Malinowski et al., 2006) est présenté par l'exemple 2.1. Exemple 2.1 : Normalisation d'instances de dimension irrégulières La dimension «lieu» comporte une ville au niveau le plus détaillé, une région et un pays aux niveaux plus élevés de la hiérarchie. La figure 2.2 représente son schéma et une instance de cette dimension matérialisée par un entrepôt. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 13

32 2 Etat de l'art dimension «lieu» schéma all instance ALL pays France Italie région Rhône Alpes PACA Piémont ville Lyon Bourg-en-Bresse Grenoble St Etienne Nice Marseille Toulon Alexandrie Turin Novare Figure 2.2 : Schéma et instance de la dimension «lieu de naissance» Le schéma est défini explicitement et ne comporte qu'un seul chemin, il s'agit donc d'une hiérarchie non multiple. Au niveau de l'instance, chaque membre de dimension n'est associé qu'à un seul père situé sur le niveau hiérarchique directement supérieur. La hiérarchie est donc également stricte et comme le montre la figure 2.2, elle est aussi couvrante et «onto». La dimension «pathologie», extraite de la classification internationale des maladies (World Health Organization, 2008) nécessite quant à elle une normalisation. En effet, l'instance de cette dimension présentée en figure 2.3 est non-onto et non couvrante. schéma all instance de la dimension «pathologie» ALL pathologie ou famille de path. 3 maladies du système nerveux maladies respiratoires pathologie ou famille de path. 2 méningite sclérose en plaques épilepsie grippe BPCO maladie d'alzheimer maladie de Parkinson sclérose latérale amyot. pneumonie bronchite, emphysème et asthme pathologie ou famille de path. 1 bronchite et emphysème pathologie asthme Figure 2.3 : Schéma et instance non normalisée de la dimension «pathologie» Sur les niveaux insuffisamment remplis pour former un arbre balancé, la normalisation ajoute des membres médiateurs copies des membres des niveaux inférieurs selon les recommandations faites par (Malinowski et al., 2006). La normalisation de l'instance permet l'obtention d'une dimension onto et couvrante, illustrée par la figure 2.4. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 14

33 2 Etat de l'art dimension «pathologie» schéma all instance ALL niveau 3 maladies du système nerveux maladies respiratoires niveau 2 méningite maladie d'alzheimer sclérose en plaques maladie de Parkinson sclérose latérale amyot. épilepsie pneumonie grippe BPCO niveau 1 méningite maladie d'alzheimer sclérose en plaques maladie de Parkinson sclérose latérale amyot. épilepsie pneumonie grippe bronchite, emphysème et asthme niveau 0 méningite maladie d'alzheimer sclérose en plaques épilepsie pneumonie maladie de Parkinson sclérose latérale amyot. bronchite et emphysème grippe asthme Figure 2.4 : Schéma et instance normalisée de la dimension «pathologie» La normalisation d'une hiérarchie de dimension améliore les performances des requêtes OLAP sans pour autant modifier la table de faits du schéma en étoile Faits, mesures et agrégats Le concept de fait désigne l'objet de l'analyse en ligne. Un fait est un concept relevant du processus décisionnel, il modélise souvent un ensemble d'événements d'une organisation. Un fait est constitué d'un ensemble de valeurs associées aux différentes mesures disponibles. Les mesures sont le plus souvent numériques et on leur assigne une fonction d'agrégation. Ces fonctions permettent de calculer les mesures aux différents grains des hiérarchies de dimension à partir des données détaillées. Par exemple, un fait dans un entrepôt contenant des informations sur une chaîne de magasins peut regrouper des mesures représentant le nombre d'unités vendues et le prix d'un produit vendu dans un magasin et à une date donnée. Le nombre d'unités vendues pour une région et/ou pour une année est agrégé par la fonction «SUM» qui fournit la somme des ventes de tous les magasins de la région et/ou des mois de l'année. Le prix est agrégé par la fonction «AVG» qui fournit la moyenne des prix. Comme le précise (Blaschka et al., 1998), certaines mesures peuvent être calculées à partir des mesures existantes. Ces mesures, nommées mesures dérivées, sont définies sous forme de formules appliquées aux valeurs des mesures contenues dans la table de faits. Par exemple, le chiffre d'affaires des magasins pour un produit donné peut être calculé en multipliant le prix du produit avec le nombre d'unités vendues. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 15

34 2 Etat de l'art Représentation d'un modèle multidimensionnel Dans (Malinowski et al., 2006), les auteurs présentent une notation appelée MultiDimER, inspirée par les travaux antécédents de (Tsois et al., 2001) (Tryfona et al., 1999) et (Sapia et al., 1999), pour décrire un modèle multidimensionnel. Nous utiliserons une notation inspirée de MultiDimER pour les modèles multidimensionnels présentés dans ce document. Les principaux éléments de la notation MultiDimER sont illustrés en figure 2.5. Figure 2.5 : Notation inspirée de MultiDimER pour la description des modèles multidimensionnels d'entrepôts A l'aide de ces éléments de modélisation, il est possible de construire une représentation graphique conceptuelle des modèles multidimensionnels Hypercube et treillis de cuboïdes L'instance d'un modèle conceptuel multidimensionnel est un «hypercube». Un hypercube OLAP représente les mesures détaillées et agrégées dans un espace multidimensionnel formé par les différentes dimensions du modèle. L'hypercube de base se situe aux niveaux hiérarchiques les plus détaillés dans les hiérarchies de dimension. La combinaison de membres des dimensions sélectionnés forme un ensemble de coordonnées qui désigne une cellule de l'hypercube. Chaque cellule contient les valeurs de mesures correspondant à la combinaison de membres (figure 2.6). Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 16

35 2 Etat de l'art Produits Localisation Temps Lyon 2004 jan 04 fev 04 mar 04 Paris Upim Standa Micros GS Carebim Alc Téléphone Alc St Ordinateur Asp 321 «Combien de Alc 54 ont été vendus par Standa en Mars 2004?» «Combien de produits ont été vendus au total?» «Combien de produits ont été vendus en Février 2004?» Figure 2.6 : Hypercube à trois dimensions L'algèbre OLAP, introduite par (Codd et al., 1993), définit les opérateurs permettant la navigation à travers les cellules et entre les membres et les niveaux des différentes dimensions. Les opérateurs standards sont : - «slice», qui sélectionne un sous-ensemble de l'hypercube réduit à un ensemble de membres sur une ou plusieurs dimensions, - «dice», qui réduit l'hypercube d'une ou plusieurs dimensions, - «roll-up», qui consiste à remonter d'un niveau dans une hiérarchie de dimension vers un niveau plus agrégé, - «drill-down», qui consiste à descendre dans une hiérarchie de dimension vers un niveau plus détaillé. On appelle cuboïde une vue définie par un niveau hiérarchique pour chaque dimension. Les cuboïdes doivent être calculés et stockés à l'avance pour assurer de bonnes performances. Les cuboïdes OLAP sont organisés en treillis, présenté en figure 2.7, où ils sont représentés par des sommets reliés par des arêtes indiquant le passage d'un niveau d'agrégation à un autre sur une dimension. Introduit par (Harinarayan et al., 1996) et (Agarwal et al., 1996), le treillis d'hypercubes représente l'ensemble des agrégats qu'il est possible d'obtenir à partir d'un hypercube de base donné. (Harinarayan et al., 1996) définissent un ordre partiel sur le treillis afin d'obtenir un graphe orienté acyclique. Ainsi, si les données d'un cuboïde suffisent à répondre à une requête, alors les données de ses ancêtres dans le treillis, qui représentent des données plus détaillées, suffisent également à répondre à cette requête. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 17

36 2 Etat de l'art (famille, année, pays) (famille, année, région) (famille, mois, pays) (pathologie, année, pays) (famille, année, ville) (famille, mois, région) (famille, date, pays) (pathologie, année, région) (pathologie, mois, pays) (famille, mois, ville) (famille, date, région) (pathologie, année, ville) (pathologie, mois, région) (pathologie, date, pays) (famille, date, ville) (pathologie, mois, ville) (pathologie, date, région) (pathologie, date, ville) Figure 2.7 : Treillis de cuboïdes OLAP pour 3 dimensions hiérarchisées Un grand nombre de travaux utilise les relations et dépendances entre les agrégats représentés par le treillis des cuboïdes. En termes de stratégies de matérialisation, (Kimball, 1996) privilégie le pré-calcul complet de tous les cuboïdes. Une sélection devient cependant indispensable au-delà d'un certain volume de données entreposées. (Ullman, 1996) donne un aperçu des différentes méthodes visant à la sélection des cuboïdes à matérialiser. (Harinarayan et al., 1996) introduisent un algorithme de type glouton qui sélectionne les vues à matérialiser en tenant compte de leur bénéfice, c'est -àdire de leur potentiel à répondre aux requêtes portant sur leurs descendants dans le treillis. (Shukla et al., 1998) et (Baralis et al., 1997) reprennent le principe de la mesure de bénéfice pour développer des heuristiques basées sur la notion de chemins dans le treillis sur lesquels se trouvent les vues à matérialiser. Le problème fait toujours l'objet de nombreuses recherches, notamment en utilisant des techniques de fouille de données pour déterminer les vues à matérialiser (Aouiche et al., 2006). 1.3 Architecture fonctionnelle d'un système OLAP Les ressources matérielles et logicielles pour l'exploitation d'un entrepôt sont conçues en fonction de la structure des hypercubes, du nombre et de l'activité des applications clientes qui soumettent des requêtes OLAP à l'entrepôt. Les différents modèles pour bases de données OLAP sont décrites par (Vassiliadis et al., 1999), les solutions architecturales sont recensées par (Chaudhuri et al., 1997). L'architecture la plus répandue est une architecture trois tiers telle qu'illustrée par la figure 2.8. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 18

37 2 Etat de l'art Architecture trois tiers Les systèmes décisionnels s'appuient sur une architecture trois tiers telle qu'illustrée par la figure 2.8. Le tier présentation représente l'interface client qui assure la fonction d'entrée des requêtes client et de présentation du résultat de ces requêtes. La logique de l'application est assurée par le moteur OLAP qui gère la construction de l'hypercube et l'exécution des opérations OLAP. Figure 2.8 : Architecture d'un système OLAP Le premier tier est un SGBD. Les données pertinentes pour l'analyse sont extraites des bases de données transactionnelles, nettoyées et transformées avec les outils ETL et intégrées dans un entrepôt de données maintenu par le SGBD. Le SGBD contient aussi un ensemble de métadonnées concernant les sources de données, les mécanismes d'accès, les procédures de nettoyage et d'alimentation, les utilisateurs, etc. Le deuxième niveau de l'architecture est un serveur OLAP, tels que par exemple Mondrian, DB2 Olap Server, Oracle OLAP ou Microsoft Analysis Services. Le serveur OLAP génère et maintient l'hypercube. Il fournit une vue multidimensionnelle des données et implémente l'ensemble des opérateurs OLAP (Roll-Up, Drill-Down, etc.) permettant de les analyser. Le dernier niveau est un client OLAP, par exemple Microstrategy, Cognos, JPivot etc. Le client offre une interface utilisateur composée d'outils de reporting, d'analyse interactive, et parfois de fouille de données. Son rôle est de rendre l'information multidimensionnelle «visible» (figure 2.9), en d'autres termes, de permettre de découvrir des connaissances grâce à la seule visualisation et interaction avec les données. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 19

38 2 Etat de l'art Figure 2.9 : Exemples de Clients OLAP 1.4 Modèles de stockage Nous présentons ci-dessous les différents modes de stockage utilisés pour maintenir les données entreposées (premier tier) et les données de l'hypercube gérées et stockées par le serveur OLAP (deuxième tier) Stockage des données de l'entrepôt Nous illustrons le modèle de stockage à l'aide d'un entrepôt conçu pour analyser les ventes d'une chaîne de magasins. Le modèle conceptuel MultiDimER de la vue orientée «ventes» de l'entrepôt est illustré par la figure Pays Année Code_pays Nom_pays Région Code_région Nom_région Lieu Magasin Code_magasin Nom_magasin Adresse_magasin Année Mois Code_mois Nom_mois Type de produit Produit Code_type Nom_type Produit Code_produit Nom_produit VENTES Date Temps Jour Jour_semaine Montant : SUM Volume : SUM Figure 2.10 : Modèle MultiDimER d'une vue orientée «ventes» sur un entrepôt Le modèle de stockage d'entrepôt dit «en étoile» (star schema) a été introduit par Kimball (Kimball, 1996). Ce schéma comporte une seule relation centrale qui relie l'ensemble des dimensions avec un ensemble de mesures unique. Cette forme est considérée comme la forme de base sur laquelle sont fondées les Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 20

39 2 Etat de l'art structures de modèles plus complexes. Le modèle en étoile est constitué d'une table de faits centrale contenant les données les plus détaillées de l'entrepôt correspondant à la table de fait VENTES dans la figure Dans cette table, les mesures associées au fait VENTE apparaissent comme attributs. Les tuples de la table de faits sont liés via des clés étrangères à des tables de dimensions. Dans la figure 2.11, les tables Temps, Localisation et Produit correspondent aux trois dimensions du modèle. Contrairement aux bases de données OLTP où la 3 ème forme normale (3NF) est préconisée, les tables de dimension sont stockées sous forme dénormalisée. Figure 2.11 : Schéma en étoile de l'entrepôt «ventes» Le modèle dit «en flocon» (snowflake schema) (Kimball, 1996) est illustré par la figure 2.12 et représente une extension du schéma en étoile permettant de mieux maîtriser la taille des tables de dimension. Les tables de dimension sont normalisées et l'information devra être reconstituée par jointure. Figure 2.12 : Schéma en flocon de l'entrepôt «ventes» Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 21

40 2 Etat de l'art Le modèle dit «en constellation» (Kimball et al., 1998) est illustré en figure 2.13, et permet de regrouper plusieurs tables de fait qui partagent toutes ou une partie de leurs dimensions. Outre le fait de mutualiser les tables de dimensions de l'entrepôt de données associées à différents faits, ce modèle met également en évidence les liens entre les perspectives d'analyse existantes pour l'interrogation de l'entrepôt. Les constellations complexes, incluant notamment des hiérarchies multiples associées à plusieurs perspectives, peuvent être gérées par des modèles basés sur la définition de contraintes (Ghozzi et al., 2003). Figure 2.13 : Schéma en constellation de l'entrepôt «ventes» Stockage des données de l'hypercube Il existe trois modes de stockage pour les données de l'hypercube. Le mode de stockage le plus ancien qui a fortement influencé bon nombre de modèles conceptuels est le «Relational OLAP», ou ROLAP. Il utilise un SGBD relationnel et organise les données au sein de relations correspondant aux tables du schéma de stockage en étoile. Ce modèle de stockage nécessite de transformer les opérations sur les hypercubes vers des requêtes sur le schéma de stockage en étoile. Ces requêtes ont une structure complexe pouvant notamment inclure un grand nombre d'opérations de jointure. L'améliorer des performances de ces requêtes dépend fortement de l'indexation des relations contenant les données multidimensionnelles et des agrégats matérialisés. De nombreuses solutions existent pour la problématique de l'indexation (Gupta et al., 1997). Les index bitmap ont été utilisés dès les débuts (Chan et al., 1999), (O'Neil et al., 1997), complétés par les index multidimensionnels tels les R-tree, UB-tree et Cubetree (Kotidis et al., 1998), (Ramsak et al., 2001), (Sarawagi, 1997). Ces approches ont depuis été développées pour inclure notamment la sélection intelligente des index pertinents (Aouiche et al., 2005), (Qiu et al., 2001). Le traitement des requêtes dites «Iceberg», nécessitant l'agrégation de grandes Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 22

41 2 Etat de l'art parties de faits, a donné lieu à des travaux alliant la matérialisation d'agrégats à l'indexation (Beyer et al., 1999), (Fang et al., 1998). Afin de s'affranchir entièrement du modèle relationnel, pour le stockage des agrégats matérialisés pour obtenir de meilleurs temps d'accès, de nombreuses approches ont développé des structures de stockage multidimensionnelles. Le stockage «Multidimensional OLAP» (MOLAP) (Vassiliadis et al., 1999) matérialise les agrégats dans des structures multidimensionnelles à l'image de l'hypercube. Les solutions existantes sont basées sur des tableaux multidimensionnels hébergeant les cellules des hypercubes dans des structures spécialisés, parfois nommées SGBDs multidimensionnels (Agrawal et al., 1997). Ce type de structure, réalisée par les Cubetree (Roussopoulos et al., 1998), Dwarf (Sismanis et al., 2002), CubiST (Hammer et al., 2003) ou CUBE File (Karayannidis et al., 2004), offrent de meilleures performances grâce à une méthode de compression spécifique visant à ne stocker que les cellules non vides des cuboïdes creux («sparse cubes»). Ces approches visent également à diminuer les coûts de mise en œuvre en limitant le nombre d'agrégats matérialisés et la réorganisation de la structure en cas de mise à jour. Les méthodes de mises à jour incrémentales des hypercubes MOLAP, notamment celle présentée par (Lee et al., 2006), ont connu des progrès substantiels grâce à l'optimisation de la gestion des mises à jour sur chaque cuboïde. Le stockage «Hybride OLAP» (HOLAP) se veut une combinaison de la puissance des SGBDs relationnels avec la rapidité des structures multidimensionnelles. Selon (Moorman, 1999), il s'agit de garder les grands volumes de données détaillées dans la partie ROLAP du système, car celle-ci présente de meilleures performances pour la gestion des grands volumes et intègre plus facilement les mises à jour incrémentales de l'entrepôt. La partie MOLAP du système permet un accès plus rapide aux données fréquemment consultées et stocke donc les cuboïdes contenant les agrégats matérialisés. L'optimisation des performances HOLAP est étudiée par (Kaser et al., 2003), qui proposent une optimisation du stockage de l'hypercube OLAP spécialement adapté au stockage HOLAP et (Luk et al., 2004), qui introduisent une méthode de pré-calcul d'agrégats respectant les contraintes d'espace de stockage spécifiques au HOLAP. Le principal défi de l'entreposage de données reste de garder rapidement accessible et à jour un important volume de données détaillées ainsi que leurs agrégats. Les différentes solutions structurelles et architecturales apportées à ce problème ont permis des avancées considérables. Ces solutions font de plus en plus souvent appel aux fonctionnalités offertes par des systèmes distribués, capables de partager et de paralléliser le stockage et les divers traitements nécessaires à l'exploitation d'un entrepôt. Parmi les systèmes distribués, le concept récent des grilles de calcul est d'un intérêt particulier pour fournir des ressources de stockage et de traitement à grande échelle. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 23

42 2 Etat de l'art 2 Les grilles de calcul Le développement des systèmes distribués est motivé par le besoin croissant d'importantes capacités de traitement qui ne peuvent être obtenues par un système unique centralisé. Les supercalculateurs récemment construits sont quasiment sans exception des systèmes faits d'une multitude d'unités de calcul identiques traitant de façon autonome une partie d'applications hautement parallèles. Les unités de traitement peuvent être des PCs standard reliés à un réseau local haut débit et contrôlés par une ou plusieurs unités centrales. Ces systèmes nommés «grappes» ou «clusters» sont fréquemment employés pour tous types de calculs distribués. L'approche de la grille de calcul est de rendre accessibles les ressources de plusieurs de ces clusters, de PCs individuels ou d'autres ressources hétérogènes via un réseau étendu. 2.1 Définition Une infrastructure de grille de calcul est constituée de nœuds dispersés géographiquement et reliés par un réseau étendu. Les ressources de stockage, de transfert réseau et de capacité de calcul peuvent varier fortement d'un nœud à l'autre et dans le temps. L'objectif d'une grille de calcul est donc l'utilisation optimale des ressources disponibles au sein de réseaux informatiques hétérogènes par une exploitation coopérative et contrôlée. Dans la première édition de «The Grid: Blueprint for a New Computing Infrastructure» (Foster et al., 1998), I. Foster et C. Kesselman définissent une grille comme «[..] une infrastructure matérielle et logicielle qui fournit un accès fiable, consistant, pervasif et peu coûteux à des capacités de traitement de haut niveau». Suite à de nombreuses interprétations du terme, (Foster, 2002) ajouta une liste de points caractéristiques des «véritables» systèmes de grille. Ainsi, une grille : - coordonne des ressources qui ne sont pas contrôlées d'une manière centralisée et intègre ainsi des ressources de différentes organisations ou institutions indépendantes comme par exemple les ordinateurs personnels ou les ressources de traitement centralisées d'une entreprise, - utilise des protocoles et interfaces standardisées, ouvertes et d'usage universel, - fournit une qualité de service «non triviale» aux applications clientes, c'est-à-dire que les ressources partagées au sein d'une grille sont utilisées d'une façon coordonnée pour fournir une qualité de service supérieure en ajoutant par exemple des contraintes en terme de disponibilité et de sécurité. Ces propriétés mènent à la définition d'une architecture de services de référence pour les infrastructures de grille. 2.2 Infrastructure de grille L'infrastructure de grille est constituée de l'ensemble des ressources intégrées à la grille ainsi que la partie intergiciel rendant accessible ces ressources aux applications clientes. L'architecture caractéristique déployée sur cette Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 24

43 2 Etat de l'art infrastructure est une architecture de services regroupés en couches superposées (Foster et al., 2003), illustrée par la figure Cette architecture reflète les conventions à la base du premier effort de standardisation des infrastructures de grilles par le «Open Grid Services Architecture» (OGSA), initiée par (Foster et al., 2002). Les couches de l'infrastructure sont déterminées par les caractéristiques des protocoles utilisés pour communiquer entre services de grille. La couche de base, le «tissu» («fabric») de la grille met à disposition les ressources physiques de stockage, de puissance de calcul et de capacité de transfert. Les services de grille instaurent un accès partagé à ces ressources pour les applications. Le partage de ces ressources par leurs «propriétaires» représente le fondement qui assure le fonctionnement de la grille. Les services mis à disposition par la couche de connectivité («connectivity») ajoutent à ce fondement les fonctionnalités relatives au transport, routage et nommage communes aux architectures de réseau, mais aussi des services spécifiques d'authentification et de délégation intégrées aux solutions de sécurisation locales. Les services de cette couche rendent ainsi accessible à distance les ressources partagées de la grille depuis les autres systèmes intégrés à la grille et depuis n'importe quel système client relié au réseau. La gestion des ressources disponibles et leur surveillance est assurée par la couche «ressources», qui représente donc une vue d'ensemble sur la grille. Cette couche regroupe les services fournissant des protocoles d'information sur la structure et l'état actuel des ressources et les protocoles de gestion et de négociation d'accès. Afin de concilier les politiques de sécurité et de gestion des ressources hétérogènes au sein d'une grille, les «nœuds» de la grille sont répartis en organisations virtuelles («virtual organisation», VO), présentées par (Foster, 2001), dont la gestion est confiée aux services de la couche «collective». Les services de cette couche sont dédiés à la gestion de l'exploitation des ressources partagées de la grille en faisant abstraction de leur localisation physique et de leurs modalités de fonctionnement. Figure 2.14 : Architecture de services en couches d'une grille Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 25

44 2 Etat de l'art L'ensemble de ces services comprend les services d'annuaire, de surveillance et de diagnostic des ressources, ainsi que les fonctionnalités d'allocation de ressources et d'ordonnancement réparti. Cette couche gère également la politique de sécurité commune à la VO, au même titre que tout autre service relatif à la collaboration des composants de la VO, que ce soit la gestion de la charge ou la réplication des données. A partir de cette architecture générale, les infrastructures de grilles existantes ajoutent ou modifient des fonctionnalités afin de s'adapter aux applications visées. Nous distinguons ici deux catégories de travaux autour des grilles, les travaux orientés vers les applications et les traitements, et les travaux orientés vers la gestion des données. Les premiers travaux sur les infrastructures de grilles ont porté sur les aspects traitement. La grille de calcul est née du constat que l'exploitation des ressources mises en place dans le cadre de supercalculateurs souffrait de leur isolement au sein de réseaux soumis à des politiques de sécurité et d'accès très restrictives. L'intégration de ces grappes dans une infrastructure de grille permet de bénéficier de leur puissance cumulée via une interface standardisée. Ce type de mutualisation des ressources offre également un accès à distance et une meilleure répartition des charges. De nombreuses infrastructures ont été réalisées selon ces principes, notamment le projet national Grid5000 décrit par (Cappello et al., 2005) et le projet nord-américain Teragrid présenté par (Reed, 2003). Ces approches mettent l'accent sur les calculs distribués, en contraste avec les solutions centrées sur le stockage distribué des données. Les infrastructures de grille qui l'intéressent la gestion des données et des requêtes sont nommées «grilles de données» (data grids). Un exemple de ce type de grille a été proposé dans le cadre du projet européen European DataGrid (EU DataGrid, 2004), (Gagliardi et al., 2002), destiné à gérer les énormes volumes de données produits par les expériences de physique des particules du CERN ( Les résultats obtenus par le projet DataGrid ont été généralisés à de nouvelles applications, par exemple bioinformatiques, dans le cadre du projet «Enabling Grids for E-sciencE» (EGEE project, 2008), (Gagliardi, 2004). De nombreux travaux ont été effectués sur la gestion des données au sein du projet EU DataGrid (Cameron et al., 2004), en particulier sur la gestion des réplicas de fichiers stockés sur plusieurs nœuds de la grille. Le transfert fiable et rapide de ces données fait également l'objet de travaux approfondis, comme les mécanismes de transfert parallélisés présentés par (Allcock et al., 2002). Les problématiques de gestion de données sur grille sont également liées aux différentes façons d'intégrer des sources de données dans l'infrastructure de grille. 2.3 Intégration de données Une grille propose aux applications clientes une vue sur les ressources de calcul à un niveau d'abstraction élevé par rapport aux mécanismes d'exécution mis en place au niveau physique. La répartition des tâches de calcul soumises à la grille nécessite un accès aux données sur lesquelles s'effectuent les calculs depuis l'ensemble des nœuds impliqués. Comme les applications clientes n'utilisent qu'une partie des données accessibles sur la grille, elles doivent Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 26

45 2 Etat de l'art pouvoir localiser et sélectionner les données utiles. La façon dont les données sont mises à disposition sur la grille dépend fortement des volumes de données concernés, des ressources de stockage disponibles, du type d'accès et des contraintes en termes de mise à jour et de sécurité. En fonction de ces paramètres, deux approches différentes peuvent être appliquées : la médiation qui offre un accès transparent à des données stockées en dehors de la grille et la répartition combinée avec la réplication qui maintient une ou plusieurs copies des données hébergées par les ressources de stockage intégrées à la grille L'approche médiation La médiation consiste à introduire une couche d'abstraction au dessus de la matérialisation des données sur le médium de stockage. Il s'agit de présenter une interface indépendante du format ou de la localisation des données. Comme le montre la figure 2.15, (Brezany et al., 2003) présentent une approche qui introduit une structure de source de données virtuelle. Celle-ci est basée sur les services d'abstraction de bases de données fournis par le système OGSA-DAI (OGSA - Data Access and Integration), présentés par (Antonioletti et al., 2005). Alors que l'architecture OGSA-DAI associe à chaque source de données une instance du service «DataService», le médiateur offre l'accès à l'ensemble des données via une instance unique d'un «Grid Data Mediation Service» (GDMS). Les applications tirant profit de ce type de service sont en particulier les applications de fouille de données comme celle introduite par (Brezany et al., 2006), traitant d'importants volumes de données de diverses sources et formats stockés le plus souvent par des bases de données externes à la grille. Figure 2.15 : Architecture du service de médiation GDMS (Brezany et al., 2003) L'approche répartition et réplication La répartition combinée avec la réplication des données sur la grille n'est pas une approche opposée à la médiation. Elle est surtout utilisée dans le cadre de Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 27

46 2 Etat de l'art grilles de données puisque la grille est d'abord utilisée comme une ressource de stockage pour les données exploitées, les projets EDG et EGEE étant les exemples les plus connus. Les données sont le plus souvent stockées sous forme de fichiers qui sont transférés vers les nœuds effectuant les calculs. Afin d'améliorer la disponibilité des données, la répartition des données parmi les nœuds est adaptée par des mécanismes de réplication intégrés à l'infrastructure, comme pour le projet EDG (Cameron et al., 2004). Les méthodes de répartition des réplicas de fichiers ont été optimisées en fonction de la demande sur chaque nœud de la grille grâce notamment à des modèles économiques comme celui présenté par (Carman et al., 2002). Ce modèle intègre un mécanisme d'enchères par lequel chaque nœud obtient les données auxquelles il attribue le plus grand bénéfice. Pour le choix de réplicas lors de requêtes, (Weng et al., 2005) appliquent la notion de bénéfice en fonction des données utiles. Afin de permettre une gestion transparente des réplicas, les systèmes de cache collaboratifs tels celui introduit par (Cardenas et al., 2006) contribuent à optimiser l'utilisation des ressources de stockage tout en maintenant un accès rapide et fiable pour les applications clientes Bases de données sur grille Alors que les méthodes de médiation intègrent déjà les bases de données relationnelles ou XML en tant que sources de données, celles-ci sont rarement hébergées par la grille. Depuis de nombreuses années, les travaux comme le projet Spitfire (Bell et al., 2002) et OGSA-DAI ont réalisé l'adaptation des méthodes d'accès aux bases de données pour les rendre disponibles aux applications de grille. L'objectif de ces approches reste la mise à disposition d'un accès uniforme vers les données de bases hétérogènes. Les solutions pour l'exécution distribuée de requêtes sur ces sources de données intégrées aux grilles existent également, d'abord réalisées par les systèmes hébergeant les métadonnées pour la découverte de services sur la grille (Hoschek, 2002). La première application destinée à l'analyse de données bioinformatiques faisant appel à l'exécution distribuée de requêtes sur des bases de données objet hébergées sur une grille a été réalisée par le système Polar* (Smith et al., 2002), dont les mécanismes ont été repris et développés par les services OGSA- DQP (OGSA Distributed Query Processing), présenté par (Alpdemir et al., 2003). Ces travaux sont cependant toujours orientés vers l'inclusion d'un maximum de sources hétérogènes pour les mettre à disposition des applications sur la grille. Le déplacement ou la réplication active de ces données tel que pratiqué pour les données sous forme de fichiers n'est pas directement applicable à ces solutions. 3 Entrepôts de données en environnement distribué Traditionnellement, tous les composants de stockage et de gestion de l'entrepôt de données sont centralisés sur un serveur. Lorsque celui-ci atteint ses limites de capacité, la solution consiste le plus souvent à dupliquer et déléguer les fonctionnalités de stockage et de traitement. Cela se traduit par l'emploi de systèmes distribués qui implémentent la parallélisation des calculs et le stockage distribué des données. Nous distinguons les approches qui appliquent Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 28

47 2 Etat de l'art et développent les mécanismes établis dans les systèmes de bases de données distribuées dédiés aux entrepôts de données et les approches qui visent à construire et exploiter des entrepôts sur les infrastructures de grille partagées et décentralisées. Les sections suivantes décrivent en premier l'aspect commun aux deux approches qui est la fragmentation et la répartition d'un entrepôt sur un système distribué, pour ensuite traiter les problématiques spécifiques à chaque approche. 3.1 Fragmentation d'un entrepôt La problématique commune aux approches pour la réalisation d'entrepôts sur systèmes distribués classiques concerne la fragmentation et le placement des données de l'entrepôt. Le placement a fait l'objet de travaux (Hua et al., 1990), (Mehta et al., 1997) ayant pour objectif d'améliorer la disponibilité des données en fonction de la charge et de la demande. En amont du processus de placement, il est nécessaire de fragmenter les données de l'entrepôt pour pouvoir les répartir parmi les unités de traitement du système. Le premier objectif de la distribution du stockage d'un entrepôt de données de grand volume est de tirer profit de l'espace de stockage mis à disposition par une base de données distribuée, afin de répartir la charge imposée par le traitement des requêtes, l'analyse des requêtes et les traitements d'agrégation. Il est donc indispensable de considérer ces aspects dans le processus de fragmentation de l'entrepôt de données précédant le déploiement de l'entrepôt distribué. Le partitionnement vertical consiste à diviser une table en plusieurs partitions verticales qui regroupent chacune un ensemble d'attributs. Elle est étudiée depuis de nombreuses années sur les tables de bases relationnelles (Navathe et al., 1984). De nombreux travaux ont suivi portant sur le partitionnement pertinent (Navathe et al., 1989), en particulier pour les bases de données orientées objet (Ravat et al., 1997), (Ezeife et al., 1998) et face aux contraintes sur le nombre de partitions générés (Son et al., 2004). A notre connaissance, (Akinde et al., 2002) est la seule approche à employer ce type de partitionnement à un entrepôt distribué. L'exécution de requêtes sur un tel entrepôt engendre cependant un grand nombre d'opérations de jointure très coûteuses. Le second principe de découpage est celui du partitionnement horizontal. Cette méthode consiste à diviser une table en partitions de plusieurs tuples complets. La division est faite à partir d'un ensemble de requêtes associées à un groupe d'utilisateurs. Lorsque le partitionnement introduit de la redondance et des partitions de taille différentes, on parle plutôt de fragmentation horizontale. L'objectif de la fragmentation des tables de l'entrepôt de données est d'isoler les parties de l'entrepôt ayant des probabilités d'accès différentes. En effet, le fait de regrouper les données correspondant à un ensemble de requêtes similaires permet de limiter les temps de recherche et d'améliorer la gestion des mémoires cache en fonction de la fréquence d'accès. Les fondations des méthodes de fragmentation horizontale d'entrepôts de données sont le partitionnement Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 29

48 2 Etat de l'art appliqué aux bases de données relationnelles, proposées par (Ceri et al., 1982) et (Özsu et al., 1991). A partir de ces mécanismes, les travaux présentés par (Bellatreche et al., 1999), (Bellatreche et al., 2000) et (Noaman et al., 1999) introduisent la fragmentation des tables d'un schéma en étoile par fragmentation horizontale dérivée sur la table de faits. Chacune des méthodes de fragmentation prend en entrée un ensemble de requêtes caractéristiques sur l'entrepôt de données cible associé à un groupe d'utilisateurs. La fragmentation est déterminée à partir d'une fragmentation des tables de dimensions sur lesquelles portent les prédicats de sélection des requêtes. Pour fragmenter les tables de dimension, il est nécessaire d'extraire et de séparer les prédicats de sélection utilisés par les requêtes sur chaque dimension. L'algorithme COM_MIN présenté par (Özsu et al., 1991) limite ces prédicats à un ensemble pertinent minimal et complet. Les prédicats retenus sont ensuite transformés en mintermes dans toutes les combinaisons possibles de leurs formes positives et négatives. Ces mintermes sont ensuite réduits pour éliminer par exemple les contradictions et autres combinaisons de prédicats non pertinents. L'approche la plus élaborée et la plus complexe dans ce domaine a été développée pour les bases orientées objet par (Bellatreche et al., 2000). L'étape suivante consiste à déduire la meilleure fragmentation possible pour la table de faits. L'algorithme présenté par (Noaman et al., 1999) utilise les prédicats de l'ensemble des tables de dimensions afin de créer un nouvel ensemble de mintermes pour la fragmentation de la table de faits. L'approche choisie par (Bellatreche et al., 2002) sélectionne une seule des fragmentations opérées sur les tables de dimensions pour en déduire entièrement la fragmentation de la table de faits. Ce choix d'une fragmentation pertinente a été optimisé à l'aide d'un algorithme génétique par (Bellatreche et al., 2005). 3.2 Politiques de placement des fragments Le placement de fragments au sein de systèmes de bases de données a fait l'objet de nombreux travaux (Hua et al., 1990), (Zhou et al., 1997). L'objectif des politiques de placement proposées est de répartir équitablement la charge parmi un ensemble de nœuds identiques. La fragmentation est alors définie en fonction des valeurs d'un seul attribut, ce qui permet à l'instance de contrôle centrale de localiser facilement les données et de réorganiser leur répartition pour rééquilibrer la charge. Le placement en fonction de la demande locale sur un ensemble de nœuds non contrôlés par une instance centrale nécessite une méthode plus différenciée de fragmentation utilisant plusieurs attributs. A partir des fragments obtenus par ces méthodes, la politique de placement peut être adaptée à l'architecture du système distribué. Ainsi, P. Furtado (Furtado, 2004a) construit un «Node-Partitioned Data Warehouse» (NPDW) sur un ensemble de nœuds autonomes en utilisant la «Multidimensional hierarchical fragmentation method» (MDHF) introduite par (Stöhr et al., 2000). Sur ce NPDW, (de Carvalho Costa et al., 2006) appliquent une politique de placement visant à placer les données au plus proche des utilisateurs de façon à maximiser leur disponibilité tout en équilibrant la charge. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 30

49 2 Etat de l'art 3.3 Entrepôts sur bases de données distribuées La plupart des travaux sur les entrepôts distribués est inspirée des solutions existantes pour les bases de données distribuées. L'objectif principal de la répartition du traitement des requêtes et du stockage des données est l'amélioration des performances. Il s'agit donc dans un premier temps de systèmes de type «grappe» ou «cluster», avec un grand nombre de nœuds «esclaves» reliés par un réseau local haut débit et contrôlés par un système «maître» central. Les principales problématiques dans ce domaine concernent donc l'exécution parallèle de requêtes (Abdelguerfi et al., 1998), en particulier des opérations de jointures (DeWitt et al., 1992), (Mehta et al., 1995), (O'Neil et al., 1995). Les données de l'entrepôt sont le plus souvent réparties en parties de taille égale (Furtado, 2004b), avec une gestion entièrement centralisée de leur répartition ainsi que des requêtes. La seule démarche décentralisée se trouve dans le domaine de mémoires cache des résultats (Deshpande et al., 1998), (Kalnis et al., 2002), développées afin de limiter la charge causée par de nombreux clients en particulier sur le système de contrôle central. 3.4 Entrepôts sur infrastructures de grille Pour le déploiement d'entrepôts de données sur grilles, les quelques travaux existants se concentrent sur l'accès aux données par médiation (Fiser et al., 2004) ou par la recherche des données sur les serveurs OLAP existants connectés à la grille (Lawrence et al., 2006), (Niemi et al., 2003). Le caractère hétérogène et la dispersion géographique des nœuds de grille nécessitent également la prise en compte d'une assurance de la qualité de service (de Carvalho Costa et al., 2006) ainsi qu'une optimisation dynamique des requêtes en cours d'exécution par des agents mobiles (Hameurlain et al., 2002). Ces approches prennent bien en compte le rôle de la distribution des données dans l'efficacité de l'exécution de requêtes. Cependant elles partent du fait qu'il s'agit d'un ensemble de sources de données hétérogènes dont la somme représente l'entrepôt, à l'opposé de la démarche pratiquée lors du déploiement d'entrepôts centralisés sur des bases de données réparties. La répartition en partitions de taille égale est uniquement pratiquée par (Poess et al., 2005), dans le contexte d'un entrepôt déployé sur des nœuds de grille «esclaves», toujours contrôlés de façon centralisée. Ces systèmes favorisent généralement la centralisation de l'accès à l'entrepôt avec un contrôle global de l'exécution de requêtes. Seul les systèmes de mémoire cache de résultat côté client comme proposés par (Deshpande et al., 1998) autorisent une gestion plus autonome des données de l'entrepôt distribué. Cette approche est développée dans (Deshpande et al., 2000) par l'ajout du calcul d'agrégats à partir du contenu du cache. Kalnis et al. (Kalnis et al., 2002) introduisent un réseau pair-à-pair entre clients pour améliorer encore la réutilisation des données résultat de requêtes. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 31

50 2 Etat de l'art 4 Discussion et conclusion Nous avons introduit les principes à la base de l'entreposage de données et de l'analyse OLAP avec les problématiques associées à la matérialisation des données et de leurs agrégats par les différents modèles de stockage. Les grilles de calcul, par leur architecture de services de grille et les nombreux travaux réalisés pour l'intégration et la gestion des données, sont une plateforme propice au déploiement et à l'exploitation d'entrepôts de données répartis. Il existe peu de travaux sur l'utilisation de grilles pour l'analyse OLAP de données multidimensionnelles. Les approches existantes se limitent le plus souvent à la définition d'architectures pour ajouter des fonctionnalités OLAP sur des applications de data mining (Fiser et al., 2004) ou des applications hautement spécialisées comme l'ingénierie moléculaire faisant appel à de grands volumes de données répartis (Dubitsky et al., 2004). (Fiser et al., 2004) notamment proposent un module OLAP central qui construit un cube virtuel sur les sources de données mises à disposition par un service médiateur. Il s'agit d'une vue multidimensionnelle sur ces données hétérogènes hébergées en dehors de la grille. Les seuls travaux comportant l'extraction de données a priori sont ceux présentés par (Niemi et al., 2003), qui se limitent cependant à la construction de cubes faits de données XML. La seule proposition prenant en compte l'importance de l'optimisation de la gestion de données pour une exploitation d'un entrepôt réparti est décrite par (Lawrence et al., 2006). La solution développée inclut l'indexation et le partage des données mises en mémoire cache par les nœuds de grille, mais maintient les données source sur des serveurs OLAP extérieurs rendus accessibles depuis la grille. La meilleure possibilité d'obtenir les données pour une requête est déterminée au moment de l'exécution par une recherche de données matérialisés ou calculables au niveau des caches client et des serveurs source (Lawrence et al., 2007). Cette méthode de recherche est inspirée par les travaux introduisant les mémoires cache client adaptés aux données multidimensionnelles issues d'entrepôts centralisés (Deshpande et al., 1998). Ces solutions permettent la réutilisation des résultats pour le calcul d'agrégats (Deshpande et al., 2000) et proposent des réseaux pairà-pair pour l'échange et la réutilisation de résultats entre systèmes client (Kalnis et al., 2002). Alors que cette approche décentralisée s'intègre bien dans le fonctionnement d'une grille, il n'existe pas d'approche pour l'intégration complète des données d'un entrepôt au sein d'une grille. Ainsi, les solutions existantes ne tirent pas profit des méthodes de fragmentation avancées et des capacités de gestion de données distribuée de la grille. Pour ce faire, il est nécessaire de déployer entièrement un entrepôt centralisé sur une grille afin de pouvoir exploiter pleinement les capacités de la grille en termes de ressources de traitement et de stockage. L'architecture décentralisée de la grille ne permettant pas l'application des mécanismes de gestion et de répartition uniforme connus, il est donc nécessaire de trouver une approche alliant les procédés de fragmentation et de répartition des entrepôts hébergés par les bases de données réparties avec la structure décentralisée en absence d'instance unique de contrôle que représente la grille. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 32

51

52

53 Chapitre 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Le fonctionnement décentralisé d'une grille nécessite d'adapter la gestion d'un entrepôt de données. Il est nécessaire de gérer la distribution des données multidimensionnelles matérialisées. Ces données matérialisées peuvent être des données détaillées et/ou agrégées. Dans ce chapitre, nous proposons une solution qui s'appuie sur : - Un modèle multidimensionnel qui permet la construction de fragments pour la table de faits, les tables d'agrégats et les tables de dimension. - Un modèle d'identification des données de l'entrepôt. La construction d'identifiants que nous proposons est basée sur des relations d'ordre total appliquées aux ensembles des membres de dimensions. Ce mécanisme nous permet d'identifier de façon unique et non ambigüe des blocs multidimensionnels de données contiguës dans l'espace de données. - Une méthode d'indexation locale au niveau des nœuds de la grille, utilisant ces identifiants de données pour une interrogation entièrement décentralisée de l'entrepôt. L'index référence l'ensemble des données matérialisées sur un nœud de la grille. Cet index permet de connaître le niveau d'agrégation et la position dans l'espace des dimensions des blocs de données matérialisés sur chaque nœud de la grille. Dans ce chapitre, après la présentation d'un cas d'utilisation issu du projet GGM, nous développerons notre modèle multidimensionnel d'entrepôt réparti sur grille. 1 Cas d'utilisation Les données utilisées dans le cadre du projet GGM sont des ensembles de résultats d'expériences géno-médicales sur biopuces associées aux dossiers médicaux informatisés des patients concernés. Ces données permettent notamment la sélection et l'étude de populations de patients. L'entrepôt de données permet de gérer des données concernant des patients atteints par les pathologies sur lesquelles portent les expériences. Les informations sur les patients sont issues d'un dossier médical informatisé, le fait étudié est le patient. Nous nous limitons à une version simplifiée à trois dimensions d'analyse qui sont la pathologie, la date de naissance et le lieu de naissance. Le modèle conceptuel de l'entrepôt selon le formalisme MultiDimER (Malinowski et al., 2006) est présenté par la figure 3.1. L'entrepôt contient comme première mesure l'évènement «décès» qui prend la valeur 0 ou 1 et qui est agrégée par la fonction SUM. La seconde mesure que nous intégrons est l'identifiant unique des patients, agrégé par la fonction LIST. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 35

54 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Pays de naissance pays capitale Pathologie Lieu Pathologie n ICD nom Ville de naissance ville population Région de naissance région chef-lieu famille de pathologies PATIENT Temps Date de naissance Mois de naissance date mois décès : SUM id_patient : LIST Année de naissance année Figure 3.1 : Schéma conceptuel de l'entrepôt centré Patient Ainsi, l'entrepôt centré Patient permettra par exemple d'étudier la population de patients atteints de la maladie d'alzheimer par tranches d'âge. Un utilisateur de cet entrepôt, par exemple un médecin ou un biologiste, doit pouvoir se connecter à l'entrepôt depuis n'importe quel site via une interface cliente. Cette interface OLAP classique (tableau de bord, table de pivot, graphiques ) doit donner accès aux données de l'entrepôt réparti comme s'il était centralisé. La figure 3.2 montre l'intégration de l'interface client dans l'architecture déployée pour l'entrepôt de données réparti. Figure 3.2 : Interfaces client dans l'architecture d'entrepôt réparti sur grille Le client peut accéder à l'entrepôt par une interface web déployée sur les points d'accès ou à l'aide de son propre client OLAP envoyant directement les requêtes OLAP au point d'accès. Afin de pouvoir gérer efficacement les données Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 36

55 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille réparties de l'entrepôt parmi les nœuds d'une grille, nous introduisons un modèle conceptuel pour les données décrivant le modèle multidimensionnel de l'entrepôt réparti. 2 Un modèle conceptuel de données multidimensionnelles réparties Lors de la conception d'un entrepôt de données, les dimensions du modèle multidimensionnel sont définies a priori comme des axes d'analyse des données qui sont présentées à l'utilisateur. Les possibilités de navigation réelles dans une dimension sont ensuite déterminées par le modèle conceptuel de cette dimension et les données mises à disposition par l'entrepôt. Ainsi, le contenu de la table de faits représente les données détaillées disponibles et la structure hiérarchisée des différentes tables de dimension donne accès aux agrégats de ces données. L'accessibilité des données et de leurs agrégats est d'autant plus importante dans un contexte de stockage réparti comme celui d'une grille, que chaque nœud stocke un sous-ensemble des données de l'entrepôt. La matérialisation du modèle multidimensionnel de l'entrepôt s'appuie dans ce caslà sur des fragments horizontaux de la table de faits ou des tables d'agrégats pré-calculées qui sont eux-mêmes liés à des fragments des tables de dimension. L'objectif de la répartition est de distribuer les données de l'entrepôt les plus demandées par les différents groupes d'utilisateurs de l'entrepôt en les matérialisant sur les nœuds de la grille les plus accessibles pour ces utilisateurs. Pour cela, nous utilisons la méthode de fragmentation horizontale dérivée exposée au chapitre 2 qui se base sur les profils de requêtes associés aux utilisateurs de l'entrepôt. Le placement des fragments obtenus sur les nœuds de la grille est optimisé pour fournir un accès rapide aux données en fonction de la demande initiale. Pour améliorer les performances du traitement de requêtes portant sur des agrégats, les agrégats les plus pertinents pour un groupe d'utilisateurs peuvent être pré-calculés selon les méthodes décrites par (Shukla et al., 1998) et (Ezeife, 2001). Le modèle d'entrepôt réparti doit donc également prendre en compte des tables d'agrégats intégrées au schéma. Nous développons par la suite les éléments du modèle décrivant les fragments de la table de faits et des tables de dimension de l'entrepôt matérialisés sur les nœuds de la grille. Le modèle met également en relation les fragments avec le modèle d'entrepôt complet tel qu'il est présenté à l'utilisateur. 2.1 Schéma et instance de dimension Nous introduisons ici des définitions pour les concepts de schéma et d'instance de dimensions largement inspirées des définitions classiques que l'on peut trouver dans la littérature (Golfarelli et al., 1998), (Malinowski et al., 2006). Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 37

56 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Définition 3.1 : Schéma de dimension Le schéma d'une dimension est défini par un ensemble de niveaux hiérarchiques reliés par des liens entre niveaux. Un lien représente le passage d'un niveau plus détaillé vers un niveau immédiatement supérieur. Nous nous limitons par la suite aux schémas de dimension représentant des hiérarchies dites «non-multiples», c'est-à-dire que chaque niveau possède au plus un niveau père, comme présenté dans l'état de l'art. La plupart des outils OLAP introduisent pour chaque dimension un niveau hiérarchique fait d'un seul membre nommé «ALL» qui représente l'agrégat de toutes les données de l'entrepôt selon cette dimension. Par la suite, nous allons inclure ce niveau dans les représentations d'instances de dimension. Définition 3.2 : Instance de dimension L'instance I D de la dimension D est constituée de l'union des ensembles de membres de tous les niveaux hiérarchiques et de l'union des ensembles de liens entre les membres de différents niveaux. k k 1 I M, L, où D i i i 0 i 0 - k est le nombre de niveaux hiérarchiques de D, - M i est l'ensemble des membres de chaque niveau hiérarchique i de D, - L i est l'ensemble des liens entre les membres du niveau i et les membres du niveau i+1. L'instance d'une dimension peut donc être représentée sous forme de graphe dirigé dont les sommets sont les membres de la dimension. Les arêtes de ce graphe sont l'expression des liens entre les membres de niveaux hiérarchiques différents. L'exemple 3.1 illustre les notions de schéma et d'instance de dimension créés pour l'entrepôt centré Patient issu du projet GGM. Exemple 3.1 : Schémas et instances des dimensions de l'entrepôt centré Patient La figure 3.3 présente le schéma de la dimension «lieu», et un extrait de l'instance de dimension de l'entrepôt centré Patient. Cette dimension est hiérarchisée avec l'ensemble des niveaux {ville, région, pays} et les liens hiérarchiques entre les niveaux (ville, région) et (région, pays). Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 38

57 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille dimension «lieu» schéma all (3) instance ALL pays (2) France Italie région (1) PACA Rhône Alpes Piémont ville (0) Marseille Nice Toulon Bourg-en-Bresse Grenoble Lyon St Etienne Alexandrie Novare Turin Figure 3.3: Schéma et extrait de l'instance de la dimension «lieu» La dimension «temps» est décrit par une table contenant les dates au format AAAA-MM-JJ, regroupées par mois et par année. La hiérarchie correspondante est définie par l'ensemble de niveaux {année, mois, date} et l'ensemble de liens hiérarchiques entre les niveaux (date, mois) et (mois, année). Un extrait du graphe associé est donné en figure 3.4. dimension «temps» schéma instance all (3) ALL année (2) mois (1) jour (0) Figure 3.4: Schéma et extrait de l'instance de la dimension «temps» Pour la dimension «pathologie», la hiérarchie comporte un nombre variable de niveaux en fonction des liens de filiation entre les membres de chaque instance. Il s'agit là d'une hiérarchie non-onto, non couvrante où les ascendants et descendants sont représentés par des liens récursifs. Nous avons montré dans le chapitre 2 comment ce type de hiérarchie pouvait être normalisée et un extrait de l'instance de cette dimension est représentée par la figure 3.5. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 39

58 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille ALL maladies du système nerveux maladies respiratoires méningite sclérose en plaques maladie d'alzheimer maladie de Parkinson sclérose latérale amyot. épilepsie pneumonie grippe BPCO bronchite, emphysème et asthme bronchite et emphysème asthme Figure 3.5: Extrait de l'instance de la dimension «pathologie» 2.2 Faits et agrégats répartis La table de faits d'un entrepôt modélisé en étoile contient des tuples qui associent une combinaison de membres de dimension à un ensemble de mesures nommé «fait». Les faits constituent les données les plus détaillées de l'entrepôt et servent de source pour le calcul de tous les agrégats disponibles à l'utilisateur. Plus formellement, la table de faits peut être définie de la façon suivante : Définition 3.3 : Table de faits Une table de faits F d'un entrepôt modélisé en étoile est une table dont les tuples t = <m 1,,m n, f 1,,f p > sont constitués d'un membre m i de dimension pour chacune des dimensions D 1,,D n de l'entrepôt et d'un ensemble de mesures f 1,,f p décrivant un fait. Chaque m i est une clé étrangère vers la table de dimension correspondante. La table de fait de l'entrepôt centralisé doit être répartie sur les différents nœuds de la grille sous forme de fragments. Définition 3.4 : Fragment de table de faits Soit F une table de faits, soient S 1,,S n des ensembles de membres sélectionnés sur l'attribut qui référence la table de dimension pour chacune des dimensions D 1,,D n. Le fragment frag({s 1,,S n },F) de F Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 40

59 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille correspondant aux sélections exprimées par S 1,,S n est l'ensemble des tuples de F pour lesquels m S i 1,, n. i i Cette définition est conforme aux notions de fragmentation introduites par (Özsu et al., 1991). L'exemple 3.2 illustre un cas simplifié de fragmentation d'une table de faits. Les tuples de cette table initiale sont regroupés en fonction de leur pertinence pour les différents groupes d'utilisateurs pour être stockés sur les nœuds de la grille associés à ces utilisateurs. Les données isolées pour chaque groupe d'utilisateurs sont sélectionnées grâce à un ensemble de prédicats de sélection sur les membres de dimensions qui permet d'identifier les tuples pertinents de la table de faits. Exemple 3.2 : Fragmentation de la table de faits d'un entrepôt modélisé en étoile Nous prenons comme exemple la fragmentation de la table de faits de l'entrepôt centré Patient. Supposons que la grille sur laquelle l'entrepôt est réparti est composée de trois nœuds A, B et C attribués à trois groupes d'utilisateurs. Chaque groupe d'utilisateurs désigne ses données pertinentes par les prédicats de sélection sur une ou plusieurs dimensions. Les prédicats de sélection portent uniquement sur les dimensions «lieu» et «temps», ce qui indique l'inclusion de tous les membres disponibles dans la dimension «pathologie». Groupe A : Sélection des patients de toutes les villes françaises dans la dimension «lieu» et de toutes les dates antérieures à 1927 dans la dimension «temps». Groupe B : Sélection des patients de toutes les villes françaises dans la dimension «lieu» et de toutes les dates postérieures à 1928 dans la dimension «temps». Groupe C : Sélection des patients de toutes les villes disponibles nés en 1927 ou 1928 pour la dimension «temps». La figure 3.6 montre les fragments désignés par les prédicats de sélection des différents groupes d'utilisateurs. Notons que dans le cas présent ces fragments sont disjoints. Nous verrons par la suite qu'un même tuple peut appartenir à plusieurs fragments, ce qui correspond au cas où plusieurs groupes d'utilisateurs ont des intérêts communs. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 41

60 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille groupe A : (lieu.pays = France) ET (temps.année < 1927) sélection des données demandées par les groupes d'utilisateurs groupe B : (lieu.pays = France) ET (temps.année > 1928) groupe C : (temps.année = 1927) OU (temps.année = 1928) table de faits «patient» fragmentée selon les critères utilisateurs fragment restant de la table à déployer sur un autre nœud lieu_naiss date_naiss pathologie id_patient décès Bourg-en-Bresse mal. d'alzheimer Bourg-en-Bresse grippe Grenoble bronchite Grenoble bronchite Grenoble méningite Grenoble mal. d'alzheimer Grenoble asthme Grenoble grippe Toulon asthme Toulon pneumonie Toulon asthme Toulon méningite Toulon bronchite Toulon grippe Toulon bronchite Toulon pneumonie Novare grippe Novare Novare Novare grippe épilepsie méningite Novare mal. d'alzheimer Turin mal. d'alzheimer Turin grippe Figure 3.6 : Table de faits «patient» fragmentée pour être répartie sur 3 nœuds de la grille selon les critères des 3 groupes d'utilisateurs associés à ces nœuds La structure des tables d'agrégats est identique à celle de la table de faits hormis le fait que les membres de dimension qui décrivent les agrégats dans chaque tuple appartiennent à des niveaux hiérarchiques plus élevés dans les tables de dimension. Ainsi, si l'attribut «lieu_naiss» de la table de faits pour la dimension «lieu» contient des valeurs de l'attribut «ville» dans la table de dimension, une table d'agrégat contient des valeurs issues des attributs «région» ou «pays» de cette même table de dimension. Définition 3.5 : Table d'agrégat Une table d'agrégat A est une table dont les tuples t = <m 1,,m n, a 1,,a p > sont constitués d'un membre m i de dimension pour chacune des dimensions D 1,,D n de l'entrepôt avec au moins un m i appartenant à un niveau d'agrégation supérieur à 0 et d'un ensemble d'agrégats a i, i = 1,,p obtenus par agrégation des mesures f 1,,f p. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 42

61 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille L'intégration des tables d'agrégats dans une structure de schéma en étoile est illustrée par la figure 3.7. lien «clé étrangère» lien entre attributs de jointure pour calcul d'agrégats table de dimension «temps» année mois date table de faits «patient» date_naiss lieu_naiss pathologie id_patient décès Lyon épilepsie Novare épilepsie Bourg-en-Bresse méningite Novare méningite Toulon asthme Toulon asthme Toulon pneumonie Alexandrie pneumonie table d'agrégat «patient-région-année» année région pathologie liste_id_patient somme_décès 1925 Rhône Alpes bronchite Rhône Alpes mal. d'alzheimer Rhône Alpes mal. de Parkinson Rhône Alpes méningite Rhône Alpes grippe Rhône Alpes grippe 15238, Piémont pneumonie Piémont mal. de Parkinson table de dimension «lieu» pays région ville France Rhône Alpes Bourg-en-Bresse France Rhône Alpes Grenoble France Rhône Alpes Lyon France Rhône Alpes St Etienne France PACA Marseille France PACA Nice France PACA Toulon Italie Piémont Alexandrie Italie Piémont Novare Italie Piémont Turin Figure 3.7 : Exemple d'une table d'agrégat aux niveaux {région, année, pathologie} Les tables d'agrégats sont fragmentées en utilisant les prédicats de sélection des utilisateurs portant sur des agrégats. La définition d'un fragment de table d'agrégats ne se distingue de la définition des fragments de tables de faits que par leur relation avec les tables de dimension. Définition 3.6 : Fragment de table d'agrégats Soit A une table d'agrégats, soient S 1,,S n des ensembles de membres sélectionnés sur les attributs correspondants aux membres contenus dans A pour chacune des dimensions D 1,,D n. Alors le fragment frag({s 1,,S n },A) de A correspondant aux sélections exprimées par S 1,,S n est l'ensemble des tuples de A pour lesquels m S i 1,, n. i i Exemple 3.3 : Fragmentation d'une table d'agrégat Nous reprenons l'entrepôt centré Patient de l'exemple précédent avec la table d'agrégat aux niveaux {région, année, pathologie} ajoutée au schéma de l'entrepôt. Supposons que les groupes d'utilisateurs A et B aient besoin des informations suivantes à un niveau agrégé : Groupe A : Sélection des régions Rhône Alpes et Piémont dans la dimension «lieu» et de toutes les années postérieures à 1935 dans la dimension «temps». Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 43

62 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Groupe B : Sélection des régions Rhône Alpes et PACA dans la dimension «lieu» et de toutes les années antérieures à 1936 dans la dimension «temps». Les fragments de la table d'agrégats sont déterminés indépendamment des fragments de la table de faits. Dans notre exemple, seuls les groupes d'utilisateurs A et B consultent fréquemment des agrégats de données qui ne sont qu'en partie matérialisées dans les fragments de la table de faits associés à chaque groupe. Par exemple, le groupe A consulte les agrégats portant sur la région Piémont, alors que les faits au niveau le plus détaillé (ville) pour cette région ne sont pas matérialisés pour ce groupe. La figure 3.8 présente la fragmentation de la table d'agrégats selon les besoins des groupes A et B. sélection des agrégats demandés par les groupes d'utilisateurs groupe A : (lieu.région IN {Rhône Alpes,Piémont}) ET (temps.année > 1935) groupe B : (lieu.région IN {Rhône Alpes,PACA}) ET (temps.année < 1936) table d'agrégats «patient» au niveau région-année fragmentée selon les critères utilisateurs région année pathologie liste_id_patient somme_décès Rhône Alpes 1925 bronchite Rhône Alpes 1925 mal. d'alzheimer Rhône Alpes 1935 mal. de Parkinson Rhône Alpes 1935 méningite Rhône Alpes 1936 grippe Rhône Alpes 1936 grippe 15238, Rhône Alpes 1939 grippe Rhône Alpes 1939 mal. d'alzheimer PACA 1925 asthme PACA 1925 mal. d'alzheimer PACA 1934 mal. d'alzheimer PACA 1934 pneumonie PACA 1936 pneumonie PACA 1937 épilepsie PACA 1938 mal. de Parkinson PACA 1938 pneumonie Piémont 1927 grippe 21341, Piémont 1928 épilepsie Piémont 1935 grippe Piémont 1935 mal. de Parkinson Piémont 1936 pneumonie Piémont 1938 pneumonie Piémont 1939 mal. de Parkinson Figure 3.8 : Table d'agrégat «patient-région-année» fragmentée pour être répartie sur les nœuds A et B de la grille Les fragments de table de faits et des tables d'agrégats créés par le processus de répartition sont stockés sur les nœuds de la grille désignés pour servir les différents groupes d'utilisateurs. Chacun de ces nœuds héberge donc un sousensemble bien défini des données détaillées et agrégées de l'entrepôt. Afin de Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 44

63 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille rendre ces données disponibles à l'interrogation des utilisateurs, il est nécessaire de répartir également les données concernant les dimensions, c'est-à-dire le contenu des tables de dimension. 2.3 Instances locales de dimension Alors que la répartition de la table de faits et des tables d'agrégats vise principalement à répartir la charge en termes de stockage et de calcul au sein de la grille, la répartition des tables de dimensions a comme objectif de rendre accessible localement les données détaillées et agrégées disponibles sur chaque nœud. En effet, le traitement d'une requête du type OLAP, même limitée aux données localement présentes, nécessite les informations contenues dans les tables de dimension pour identifier correctement le résultat demandé. Nous nous intéressons ici à des tables de dimension modélisées en étoile, c'est-à-dire selon un modèle dénormalisé. Ces tables de dimension contiennent donc des attributs représentant la hiérarchie et des attributs descriptifs. Par exemple, pour la dimension «lieu», la hiérarchie est représentée par les attributs ville, région et pays, et les attributs descriptifs pourraient être le nombre d'habitants par ville ou le nom de la préfecture d'une région. Pour un nœud donné, nous construisons l'instance locale de dimension à partir du contenu des fragments de table de faits ou d'agrégats matérialisés sur ce nœud. Définition 3.7 : Instance locale de dimension Soit R l'ensemble des fragments de la table de faits et des tables d'agrégats matérialisés sur un nœud de la grille. Soit I D l'instance de dimension de l'entrepôt pour la dimension D. Alors l'instance de dimension locale I D (R) est un sous-ensemble de I D constitué des éléments suivants : - l'ensemble M 0 des membres du niveau 0 le plus détaillé de la hiérarchie présents dans au moins un des tuples des fragments de la table de faits matérialisés par R, - l'union des ensembles M j de membres des niveaux agrégés j, j > 0 présents dans au moins un des tuples des fragments de tables d'agrégat matérialisés par R, - l'ensemble M' des membres contenus dans I D pour lesquels il existe un lien de filiation avec les membres de M 0 et/ou les membres de l'union des M j, - l'ensemble L' des liens entre les membres des différents niveaux présents dans l'union de M 0, de tous les M j et de M'. L'instance locale I D (R) matérialise donc la partie de I D qui se limite aux membres de l'union de M 0, de tous les M j et de M' avec l'ensemble L' des liens hiérarchiques entre ces membres. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 45

64 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille k k 1 I R M M M, L, L L D 0 i i i 0 i 0 Autrement dit, nous matérialisons dans l'instance locale de dimension sur ce nœud les membres contenus dans les fragments de table de faits ou d'agrégats ainsi que tous leurs ancêtres et descendants dans l'instance de dimension. Exemple 3.4 : Instance locale de dimension sur un nœud de la grille Le nœud de grille A héberge un fragment de la table de faits «patient» ainsi qu'un fragment de la table d'agrégats «patient-région-année». Comme le montre la figure 3.9, ces instances locales des dimensions «lieu» et «temps» représentent les tuples des tables de dimension qui contiennent les membres présents dans les fragments matérialisés sur le nœud. instance locale de la dimension «lieu» pays région ville France Rhône Alpes Bourg-en-Bresse France Rhône Alpes Grenoble France Rhône Alpes Lyon France Rhône Alpes St Etienne France PACA Marseille France PACA Nice France PACA Toulon Italie Piémont Alexandrie Italie Piémont Novare Italie Piémont Turin lieu_naiss fragment de la table de faits «patient» date_naiss pathologie id_patient décès Bourg-en-Bresse mal. d'alzheimer Bourg-en-Bresse grippe Grenoble bronchite Grenoble bronchite Toulon asthme Toulon pneumonie Toulon asthme instance local de la dimension «temps» année mois date fragment de la table d'agrégat «patient-région-année» région année pathologie liste_id_patient somme_décès Rhône Alpes 1936 grippe Rhône Alpes 1936 grippe 15238, Rhône Alpes 1939 grippe Rhône Alpes 1939 mal. d'alzheimer Piémont 1936 pneumonie Piémont 1938 pneumonie Piémont 1939 mal. de Parkinson lien «clé étrangère» lien entre attributs de jointure pour calcul d'agrégats Figure 3.9 : Instances locales des dimensions «lieu» et «temps» pour le nœud de grille A Ainsi, il devient possible d'interroger les données présentes sur le nœud A en ayant uniquement recours aux données matérialisées localement. Un utilisateur peut demander par exemple le détail de tous les patients nés en 1925 pour chaque ville en région PACA. L'entrepôt identifie alors à l'aide des informations dans les instances locales de dimensions toutes les dates de naissances disponibles pour l'année 1925 et les villes appartenant à la région Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 46

65 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille PACA, ce qui lui permet de sélectionner les tuples demandés dans le fragment de table de faits matérialisé localement. Grâce à la modélisation de fragments des tables de faits et d'agrégats associée à la création d'instances locales de dimensions, nous obtenons des parties indépendantes de l'entrepôt réparties sur les différents nœuds. Cette structure décentralisée donne une importante autonomie aux nœuds de la grille en termes de gestion des données matérialisées. Par contre, dès qu'il s'agit de répondre à des requêtes portant sur des données non disponibles localement, l'entrepôt de données réparti doit disposer d'un mécanisme d'identification des données permettant de rechercher les données manquantes localement parmi les nœuds de la grille. 2.4 Ordonnancement des membres de dimension L'objectif de l'ordonnancement des membres d'une instance de dimension est de faciliter le regroupement d'ensembles de données en les identifiant par leurs limites inférieures et supérieures sur chaque dimension. Cet ordonnancement permet ainsi d'obtenir des identifiants qui indiquent la position relative des données qu'ils représentent dans le modèle multidimensionnel. Nous introduisons pour cela certaines contraintes sur les instances de dimensions qui permettront par la suite l'ordonnancement des membres de dimensions sur la totalité de la structure hiérarchique de ces instances. Les liens de filiation entre les membres de la table de dimension sont décrits par la hiérarchie de dimension. Les hiérarchies possèdent certaines propriétés en fonction de leur structure, explicitées par (Pedersen et al., 1999). Ces propriétés permettent de déterminer si une instance peut être ordonnée selon la méthode présentée ici. Pour que notre méthode d'ordonnancement soit applicable, une hiérarchie de dimension doit être : - explicite, définie par un schéma de hiérarchie, - non-multiple, le schéma de hiérarchie ne comporte que des niveaux hiérarchiques avec au plus un seul père et un seul fils, - stricte, chaque membre a au maximum un père au niveau hiérarchique supérieur (pas de relations n à n entre niveaux hiérarchiques), - onto, c'est-à-dire représentée par un arbre balancé, - couvrante, tous les liens père-fils sont établis entre un niveau donné et un niveau immédiatement supérieur ou inférieur. Nous partons de l'hypothèse que toutes les instances de dimension utilisées respectent ces contraintes. Le chapitre 2 présente les méthodes de «normalisation» existantes qui permettent de transformer les instances de dimension ne respectant pas ces contraintes. C'est le cas de la dimension «pathologie» de l'entrepôt centré Patient dont la normalisation est illustrée au chapitre 2. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 47

66 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille L'identification par ensembles contigus de données utilise une relation d'ordre total i sur l'ensemble M i des membres du niveau hiérarchique i appartenant à une hiérarchie de dimension. Cette relation vérifie donc les propriétés suivantes : réflexive : x ix x M i antisymétrique : x i y y ix x y x, y M i transitive : x i y y iz x iz x, y, z M i total : x i y y ix x, y M i L'ordre total ne peut s'appliquer qu'à un ensemble de membres appartenant au même niveau hiérarchique, car la dernière condition exige que deux membres de l'ensemble ordonné soient comparables. Cette contrainte est nécessaire pour assurer que chaque sous-ensemble de M i possède un maximum et un minimum par rapport à la relation d'ordre. On peut ainsi créer des intervalles contigus de membres. Nous avons également la possibilité d'ordonner les autres niveaux hiérarchiques de la dimension à partir d'un ensemble de membres ordonné sur un niveau inférieur ou supérieur. La relation d'ordre peut ainsi être propagée aux autres niveaux ; nous introduisons ainsi la définition d'un «ordre propagé» par rapport à un niveau ordonné de référence. Selon la position du niveau de référence par rapport au niveau à ordonner, nous parlons de propagation ascendante ou descendante. Les notions suivantes sont nécessaires à la définition formelle de la propagation d'un ordre d'un niveau hiérarchique à l'autre. Soit : g : M, i M m, j g m, j j la fonction qui associe à chaque membre m de M i du niveau i le membre ou l'ensemble de membres de niveau j qui lui sont reliés par filiation. Par exemple, dans la dimension de la figure 3.11, g( Nice',3) = { France'} et g( PACA',1) = { Marseille', 'Nice', 'Toulon'}. Soit j la relation d'ordre total sur l'ensemble M j de membres au niveau j i qui sert à induire un ordre total sur l'ensemble M i de membres au niveau i. Nous distinguons alors les deux cas suivants : (1) Si i < j, alors l'ordre j doit être propagé de façon descendante vers le niveau i. Compte tenu des propriétés des dimensions que nous avons définies, deux membres arbitraires x et y du niveau i ont chacun un seul Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 48

67 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille ancêtre g(x,j) et g(y,j) au niveau j. En conséquence, x et y sont mis en d relation par la relation i directement déduite de j : d i j : g x, j g y, j x y j La relation d'ordre au niveau j ne permet cependant pas d'ordonner les membres au niveau i dans le cas où g x, j = g y, j. Par exemple, les deux villes Nice et Toulon ne peuvent pas être comparées à l'aide de leur ancêtre commun au niveau région (PACA), il faut donc trouver un autre critère pour créer un ordre total qui complète d i i. Les sous-ensembles aux ancêtres communs sont alors ordonnés par une relation d'ordre total relation e i. Cette e i peut être induite par une propriété de membre ou un autre niveau k avec k i,k j. Par exemple, les villes d'une même région peuvent être ordonnées à l'aide de leur population ou par ordre alphabétique, comme l'illustre l'exemple 3.5. Définition 3.8 : Relation d'ordre propagée descendante Une relation d'ordre total propagée descendante i sur l'ensemble M i de membres au niveau i est définie comme suit à partir de l'ordre j, avec i < j : x, y M : x y i i e x i d x y si g x, j g y, j i y si g x, j = g y, j (2) Si i > j, alors l'ordre j doit être propagé de façon ascendante vers le niveau i. Comme les membres au niveau i peuvent avoir plusieurs descendants au niveau j, il est nécessaire de sélectionner des représentants parmi ces descendants. Ainsi, nous introduisons l'ordre minimum des descendants selon j. i en utilisant le Définition 3.9 : Relation d'ordre propagée ascendante Une relation d'ordre total propagée ascendante i sur l'ensemble M i de membres au niveau i est définie comme suit à partir de l'ordre i > j : x,y M i : x i y min g x, j j min g y, j j, avec Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 49

68 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Par exemple, en ordonnant le niveau pays (i = 2) à partir du niveau région (j = 1) pour comparer les membres 'France' et 'Italie', on doit sélectionner des représentants parmi les ensembles g('france',1) = {'PACA', 'Rhône Alpes'} et g('italie',2) = {'Piémont'}. Nous supposons que le niveau région est ordonné en ordre alphabétique, donc min(g('france',1)) = 'PACA' et min(g('italie',1)) = 'Piémont'. Nous obtenons donc l'équivalence suivante : 'PACA' 1 'Piémont' 'France' 2 'Italie' Note : Nous avons choisi ici d'utiliser le minimum pour le choix d'un représentant parmi les descendants des membres du niveau i. Nous aurions pu aussi bien choisir le maximum ou une autre fonction injective définie sur les ensembles de descendants au niveau j. L'objectif de l'ordonnancement propagé par un niveau hiérarchique est de pouvoir déduire facilement les intervalles de membres représentant les mêmes données à différents niveaux d'agrégation. Par exemple, si on souhaite obtenir tous les agrégats associés aux membres entre 'PACA' et 'Rhône Alpes' au niveau région, comme l'illustre la figure 3.10, l'ordre sur l'instance de dimension permet de déterminer qu'il faut agréger pour cela l'ensemble des faits associés aux membres entre 'Toulon' et 'Lyon' au niveau ville. intervalle de membres au niveau «région» PACA Rhône Alpes Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon intervalle de membres au niveau «ville» Figure 3.10 : Intervalles de membres représentant des données équivalentes sur différents niveaux hiérarchiques Afin d'assurer cette possibilité sur la totalité de l'instance de dimension, nous définissons une instance de dimension ordonnée. Définition 3.10 : Instance de dimension ordonnée Soit I D une instance d'une dimension dont le schéma comporte n niveaux de 0 à n-1 et M i l'ensemble de membres du niveau i ordonné par la relation i. Alors I D est ordonnée si i 0,, n 1, x,y M : x y g x, i 1 g y, i 1 i i i 1 Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 50

69 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille L'exemple 3.5 illustre la construction d'instances de dimension ordonnées par l'usage de relations d'ordre propagées à travers leurs niveaux hiérarchiques. Exemple 3.5 : Ordonnancement d'instances de dimension Dans cet exemple, nous détaillons l'ordonnancement des instances de dimensions matérialisées pour l'entrepôt centré Patient. L'instance de la dimension «temps» peut être ordonnée facilement à l'aide de l'ordre chronologique. En effet, celui-ci fournit un ordre total, peu importe le niveau de la hiérarchie auquel il est appliqué. La figure 3.4 représente déjà l'instance ordonnée, car indépendamment de la propagation choisie, on obtient une instance entièrement ordonnée en utilisant l'ordre chronologique. L'ordonnancement de la dimension «lieu» s'avère plus complexe car la sélection de membres représentant des unités géographiques ne se fait pas selon un ordre prédéfini. Pour notre exemple, nous choisissons d'ordonner les membres du niveau «pays» à l'aide la relation d'ordre alphabétique 2. Les régions sont ordonnées en fonction de leur pays parent par la relation d'ordre d 1 propagée depuis le niveau «pays» : région1 d 1 région2 pays région1 pays région2 si pays région1 pays région2 2 Toutes les régions appartenant au même pays sont à leur tour triées par ordre alphabétique par la relation e 1. Enfin, les membres du niveau «ville» enfin sont ordonnées en fonction de l'ordre défini sur les régions : d ville1 0 ville2 région ville1 1 région ville2 Finalement, les villes au sein d'une région sont ordonnées à l'aide de leur propriété «population» qui définit la relation e 0. Si deux villes d'une même région ont la même population, il faudra introduire un nouveau critère, par exemple l'ordre alphabétique. Le résultat est présenté par la figure Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 51

70 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille dimension «lieu» schéma all (3) relation d'ordre instance ALL pays (2) France Italie région (1) PACA Rhône Alpes Piémont ville (0) Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin Figure 3.11 : Instance ordonnée de la dimension «lieu» Pour la dimension «pathologie», l'ordre numérique sur les numéros ICD fournit un ordre total applicable à tous les niveaux hiérarchiques. Nous nous basons ici sur la version «normalisée» de l'instance tel que décrite au chapitre 2. Issus du même ensemble de numéros ICD initial, les membres des différents niveaux hiérarchiques peuvent être ordonnés sur chaque niveau par ce même ordre numérique. Nous choisissons comme niveau de référence le niveau le plus détaillé (niveau 0) de la hiérarchie. Ainsi, chaque membre m j d'un niveau supérieur j avec j > 0 est comparé aux membres du même niveau à l'aide de ses descendants au niveau 0. Parmi ces descendants, le membre minimum est choisi, c'est-à-dire celui avec le plus petit numéro ICD. Au niveau 3, l'ordre est alors obtenu grâce aux numéros ICD des membres du niveau 0. La figure 3.12 met en relation ces deux niveaux avec comme exemple les membres 'maladies du système nerveux' et 'maladies respiratoires' au niveau 3. ICD 54 ICD 73 ' méningite' ' pneumonie' schéma 0 ' maladies du système nerveux' ' maladies respiratoires ' dimension «pathologie» instance 3 all ALL path-3 maladies du système nerveux (ICD 53) maladies respiratoires (ICD 72) path-0 méningite (ICD 54) épilepsie (ICD 59) pneumonie (ICD 73) maladie d'alzheimer (ICD 55) sclérose latérale amyot. (ICD 57) maladie de Parkinson (ICD 56) sclérose en plaques (ICD 58) bronchite et emphysème (ICD 76) grippe (ICD 74) asthme (ICD 78) Figure 3.12 : Ordres propagés de l'instance ordonnée de la dimension «pathologie» Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 52

71 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Les minima de leurs descendants au niveau 0 sont les membres 'méningite' (ICD 54) et 'pneumonie' (ICD 73). Nous sommes donc en mesure de mettre en relation les membres 'maladies du système nerveux' et 'maladies respiratoires' en partant des numéros ICD des membres au niveau 0. La méthode d'ordonnancement présentée est appliquée à toutes les dimensions de l'entrepôt de données. Sur cette base, nous introduisons un mécanisme d'identification permettant de rechercher aussi bien les données détaillées que les données agrégées disponibles parmi les nœuds de la grille. 3 Identification de données multidimensionnelles La recherche des données disponibles dans un contexte d'entrepôt distribué et décentralisé nécessite une identification non ambiguë des données de l'entrepôt. Nous proposons une approche qui s'inspire de la façon dont les requêtes OLAP référencent les données de l'entrepôt. En effet, une requête OLAP est constituée d'une sélection de membres pour une ou plusieurs dimensions ainsi qu'un choix de mesures ou de leurs agrégats. Notre modèle d'identification s'appuie sur les membres des instances de dimensions. Ces identifiants sont utilisés par chaque nœud de la grille pour indexer et publier les données qu'ils hébergent. De façon classique, l'index doit pouvoir identifier des ensembles de données. Nous allons utiliser la méthode d'ordonnancement des instances de dimension afin de comparer, regrouper et localiser les données de l'entrepôt. 3.1 Définition et identification de «chunks» de données Les travaux concernant la gestion distribuée de données multidimensionnelles s'appuient en grande partie sur une subdivision des données de l'entrepôt en unités élémentaires auxquelles sont attribués des identifiants. Le terme le plus souvent employé pour désigner ces unités est celui de «chunk», traduit par «morceau», «tronçon» ou «unité naturelle». La notion de «chunks» a été utilisée dans le cadre de travaux portant sur l'optimisation du stockage de données sur disque présentés par (Sarawagi et al., 1994) et la gestion de mémoires cache client pour entrepôts de données distants décrite par (Deshpande et al., 1998) et (Kalnis et al., 2002). Les «chunks» utilisés par ces systèmes sont de taille variable en fonction des blocs gérés par les disques ou la taille des résultats de requêtes stockées en mémoire cache. Afin de permettre un accès au grain le plus fin, nous fixons la taille d'un chunk au sein de notre méthode d'identification à un tuple d'une table de faits détaillés ou d'agrégats. Définition 3.11 : Chunk de données multidimensionnelles Soit T une table de faits détaillée ou une table d'agrégats, soit {D 1,.., D n } l'ensemble des dimensions de l'entrepôt, un chunk C correspond à un tuple donné de la table T. Ce tuple contient les clés Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 53

72 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille étrangères vers les membres de dimension et une ou plusieurs valeurs de mesures ou d'agrégats. L'identifiant unique c du chunk C est composé de la liste de ses membres. Chaque membre est décrit par un label précisant le nom de la dimension, le nom du niveau et le nom du membre : L'identifiant c s'écrit donc c = {nomdimension 1.nomNiveau 1.nomMembre 1,, nomdimension n.nomniveau n.nommembre n }. Nous introduisons une notation numérique équivalente qui substitue aux labels le numéro de la dimension, le rang du niveau hiérarchique et le rang du membre au sein de l'ordre défini sur le niveau de la dimension. Par exemple, l'identifiant de chunk c = {lieu.pays.france, temps.année.1937, pathologie.path-0.asthme} identifie le tuple représentant le nombre de décès et la liste des patients en France pour les patients nés en 1937 et la pathologie asthme. La notation numérique du label «temps.année.1937» est «2.2.13», car : - «temps» est la deuxième dimension, - «année» est le troisième niveau hiérarchique de la dimension temps (compté à partir du niveau 0 qui est le plus détaillé) et - le membre «1937» est le treizième membre dans l'ordre du niveau. L'espace de nommage créé par les identifiants de chunks va nous permettre de référencer toutes les données matérialisées du modèle multidimensionnel, qu'il s'agisse des données détaillées ou agrégées. Par la suite, nous désignons un chunk de données par son identifiant, peu importe si celui-ci est matérialisé dans l'entrepôt ou non. L'information sur la matérialisation d'un chunk est gérée par les structures plus complexes que nous introduisons au cours des chapitres suivants. Ainsi construit, un identifiant de chunk désigne toutes les copies existantes d'un même chunk sur la grille. Ceci présente une condition essentielle pour un recensement et une localisation efficace des données distribuées à travers les nœuds de stockage. En plus de référencer précisément un tuple d'une table de faits ou d'agrégats, l'identifiant de chunk permet également d'établir précisément les équivalences entre données détaillées et leurs agrégats. C'est à travers les liens hiérarchiques existants entre membres de dimensions qu'il est possible d'identifier les chunks d'un niveau d'agrégation inférieur nécessaires à l'obtention d'un chunk agrégé. La figure 2.12 illustre le lien identifié à l'aide des hiérarchies de dimension entre un ensemble de chunks définis dans deux dimensions «dim A» et «dim B» aux niveaux i et j et le chunk représentant l'agrégat de ces chunks aux niveaux hiérarchiques supérieurs i+1 et j+1. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 54

73 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille i+1 dim A dim B dim A dim B j+1 j i+1 chunk membre i j+1 agrégation Figure 3.13 : Lien entre un ensemble de chunks et un chunk agrégé en deux dimensions En utilisant le rang dans l'ordre total sur ces niveaux hiérarchiques et la notion d'intervalle introduite précédemment, il est également possible de calculer la distance entre deux identifiants de chunk et ainsi d'évaluer le volume multidimensionnel de données en nombre de chunks existantes entre deux identifiants. Par exemple, le volume multidimensionnel volume(c 1,c 2 ) désigne le maximum de chunks détaillés entre les deux chunks c 1 et c 2 : Chunk 1 : c 1 = {lieu.ville.toulon, temps.date , pathologie.path-0.pneumonie} (equ. {1.0.1, , 3.0.7}) Chunk 2 : c 2 = {lieu.ville.turin, temps.date , pathologie.path-0.pneumonie} (equ. {1.0.10, , }) volume c1, c 2 1;10 * 61;103 * 7;10 10*43* L'étape suivante est de définir des structures regroupant des ensembles contigus de chunks appelés blocs de chunks. 3.2 Construction de blocs de chunks Pour faciliter la gestion de grandes quantités de données identifiées par chunks au sein de l'entrepôt, nous définissons la notion de bloc de chunks. Celui-ci Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 55

74 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille représente un ensemble contigu de données dans un espace multidimensionnel de données créé par les ensembles de membres ordonnés de dimension. Définition 3.12 : Bloc de chunks Un bloc de chunks B est un ensemble de chunks dont les membres au sein d'une même dimension sont au même niveau hiérarchique. Un bloc de chunks regroupe une section contiguë dans l'espace multidimensionnel de données formé par les ensembles ordonnés de membres d'un niveau hiérarchique pour chaque dimension. Cette section est délimitée par une limite inférieure et une limite supérieure dans chaque dimension. Chaque limite correspond à un identifiant de chunk. L'identifiant unique b = <c inf, c sup > d'un bloc de chunks est alors composé des identifiants de chunk c inf pour la limite inférieure et c sup pour la limite supérieure du bloc. Remarquons que nous notons B (en majuscule) le bloc de chunks et b (en minuscule) son identifiant. Par exemple, le bloc de chunks qui regroupe tous les chunks au niveau ville pour la dimension «lieu», année pour la dimension «temps» et path-0 pour la dimension «pathologie» et dont les membres sont compris entre 'Toulon' et 'Turin' pour la dimension «lieu», entre 1935 et 1939 pour la dimension «temps» et entre 'pneumonie' et 'asthme' pour la dimension «pathologie», aura alors l'identifiant suivant : <{lieu.ville.toulon, temps.année.1935, pathologie.path-0.pneumonie}, {lieu.ville.turin, temps.année.1939, pathologie.path-0.asthme}> (equ. <{1.0.1, , 3.0.7},{1.0.10, , }>) La forme numérique de l'identifiant, qui contient les numéros des dimensions et des niveaux hiérarchiques et les rangs de membres dans leur ensemble de membres ordonné, permet de comparer les membres sans accéder à la hiérarchie de dimension et d'obtenir une estimation du volume de données contenu dans le bloc. De plus, la relation d'ordre définie dans un niveau permet de vérifier facilement l'appartenance d'un chunk à un bloc de chunks. Exemple 3.6 : Identification d'un bloc de chunks La figure 3.14 présente une section de la table de faits «patient» qui représente un ensemble contigu de chunks. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 56

75 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille lieu_naiss date_naiss pathologie id_patient décès Toulon asthme Toulon pneumonie Marseille épilepsie Bourg-en-Bresse mal. d'alzheimer Bourg-en-Bresse grippe Bourg-en-Bresse asthme Bourg-en-Bresse pneumonie Bourg-en-Bresse bronchite et éphysème Bourg-en-Bresse asthme Bourg-en-Bresse mal. de Parkinson Bourg-en-Bresse bronchite et éphysème Bourg-en-Bresse mal. de Parkinson Bourg-en-Bresse mal. d'alzheimer Bourg-en-Bresse asthme Bourg-en-Bresse pneumonie Bourg-en-Bresse mal. de Parkinson St Etienne mal. de Parkinson St Etienne St Etienne St Etienne asthme asthme pneumonie St Etienne asthme Grenoble grippe Grenoble bronchite et éphysème Grenoble mal. de Parkinson Grenoble mal. de Parkinson Grenoble asthme Grenoble asthme Grenoble grippe Lyon méningite Lyon asthme Lyon méningite Lyon grippe Alexandrie mal. de Parkinson Turin mal. d'alzheimer Figure 3.14 : Bloc de chunks contigus dans la table de faits «patient» Les parties encadrées en gras représente un bloc de chunks B dont l'identifiant b est : b = <{lieu.ville.bourg-en-bresse, temps.date , pathologie.path-0.pneumonie}, {lieu.ville.lyon, temps.date , pathologie.path-0.asthme}> (equ. <{1.0.4, , 3.0.7},{1.0.7, , }>) La table de faits étant triée par lieu de naissance, date de naissance et pathologie, les chunks inclus dans le bloc ne sont pas contigus au niveau de la table elle-même. Néanmoins, ces chunks sont contigus dans l'espace multidimensionnel. Les membres de la dimension «lieu» sont compris entre 'Bourg-en-Bresse' et 'Lyon', ceux de la dimension «temps» entre et et les membres de la dimension «pathologie» sont compris entre 'pneumonie' et 'asthme'. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 57

76 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Si on note c = {lieu.ville.x, temps.date.y, pathologie.path-0.z} (equ. {1.0.x, 2.0.y, 3.0.z}) l'identifiant d'un chunk C avec x,y,z les rangs des membres respectifs dans l'ordre total défini pour chacune des dimensions «lieu», «temps» et «pathologie», alors, la condition nécessaire et suffisante pour que c appartienne au bloc de chunks B est : C B rang Bourg en Bresse x rang Lyon rang y rang rang pneumonie z rang asthme 4 x 7 32 y 75 7 z 10 Dans l'espace multidimensionnel, la notion de bloc représente un hyperrectangle dans l'espace formé par les ensembles de membres de dimension et permet de gérer les fragments de l'entrepôt répartis sur les nœuds de la grille. Nous détaillons par la suite la représentation des fragments de l'entrepôt de données par ces blocs de chunks et leur déploiement sur la grille. 4 Indexation de données multidimensionnelles La structure d'indexation que nous allons détailler associe une indexation pour les différents niveaux d'agrégation, et, pour chaque niveau, une indexation spatiale des données multidimensionnelles. En effet, il est nécessaire de considérer ces deux modes d'indexation afin d'assurer la recherche des données disponibles sur un nœud de la grille. Le premier index, que nous appelons index T, est structuré en treillis et distingue les données détaillées et les agrégats de différents niveaux sur le nœud. Le deuxième index, que nous appelons index X, s'appuie sur une indexation spatiale en X-tree du contenu des blocs de chunks. L'index TX, qui permet d'indexer les données multidimensionnelles sur un nœud de la grille, résulte de la combinaison de ces deux index. Des primitives pour la maintenance (insertion, suppression) et la recherche au sein de la structure d'index sont ensuite proposées. 4.1 Index T sur les différents niveaux d'agrégation Classiquement, on définit un treillis de cuboïdes comme le graphe des agrégats calculables à partir d'un cube de base (Harinarayan et al., 1996). Un sommet représente un cuboïde à un niveau d'agrégation défini par la combinaison des niveaux hiérarchiques de chaque dimension. Afin d'indexer les niveaux d'agrégation présents sur chaque nœud de la grille, nous introduisons une structure d'index T inspirée des treillis de cuboïdes. La structure de l'index T Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 58

77 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille prend uniquement en compte le niveau d'agrégation des blocs disponibles sur le nœud de la grille. Définition 3.13 : Index T en treillis de niveaux d'agrégation L'index T en treillis de niveaux d'agrégation est un graphe orienté acyclique (V,E) constitué par un ensemble V de sommets et un ensemble E d'arêtes, tels que : - un sommet est créé dans V pour chaque niveau d'agrégation de données disponibles sur le nœud - une arête entre deux sommets est définie s'il existe au moins un lien de filiation entre les niveaux hiérarchiques de ces sommets Soit levels la fonction qui permet d'extraire à partir d'un identifiant de bloc la liste de ses niveaux hiérarchiques. Ainsi, pour b = <c inf, c sup > avec c inf = {nomdimension 1.nomNiveau 1.nomMembre 1,, nomdimension n.nomniveau n.nommembre n } et c sup = {nomdimension 1.nomNiveau 1.nomMembre 1 ',, nomdimension n.nomniveau n.nommembre n '}, on a : levels(b) = {nomniveau 1,,nomNiveau n } Un sommet du treillis regroupe tous les blocs de chunks aux niveaux hiérarchiques levels(b) identiques, donc du même niveau d'agrégation sur un nœud de la grille. Les arêtes entre les sommets indiquent les opérations d'agrégation nécessaires pour passer d'un niveau d'agrégation plus détaillé vers un niveau plus agrégé pour chaque dimension. Exemple 3.7 : Construction d'un index en treillis de niveaux d'agrégation Prenons par exemple un nœud de la grille hébergeant cinq blocs détaillés b d, b e, b f, b g et b h ainsi qu'un ensemble de blocs agrégés b k, b l et b m contenant des agrégats à des niveaux hiérarchiques supérieurs pour les dimensions «lieu» et «temps» : Les identifiants des blocs de chunks détaillés sont : b d = <{lieu.ville.toulon, temps.date , pathologie.path-0.méningite}, {lieu.ville.grenoble, temps.date , pathologie.path-0.pneumonie}> (equ. <{1.0.1, 2.0.1, 3.0.1},{1.0.6, , 3.0.7}>) b e = Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 59

78 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille <{lieu.ville.toulon, temps.date , pathologie.path-0.méningite}, {lieu.ville.marseille, temps.date , pathologie.path-0.épilepsie}> (equ. <{1.0.1, , 3.0.1},{1.0.3, , 3.0.6}>) b f = <{lieu.ville.toulon, temps.date , pathologie.path-0.méningite}, {lieu.ville.st Etienne, temps.date , pathologie.path-0.sclérose en pl.}> (equ. <{1.0.1, , 3.0.1},{1.0.5, , 3.0.5}>) b g = <{lieu.ville.alexandrie, temps.date , pathologie.path-0.grippe}, {lieu.ville.turin, temps.date , pathologie.path-0.asthme}> (equ. <{1.0.8, 2.0.1, 3.0.8},{1.0.10, , }>) b h = <{lieu.ville.lyon, temps.date , pathologie.path-0.grippe}, {lieu.ville.turin, temps.date , pathologie.path-0.asthme}> (equ. <{1.0.7, , 3.0.8},{1.0.10, , }>) Les identifiants de blocs de chunks agrégés sont : b k = <{lieu.région.rhône Alpes, temps.mois , pathologie.path-0.méningite}, {lieu.région.piémont, temps.mois , pathologie.path-0.asthme}> (equ. <{1.1.2, 2.1.2, 3.0.1},{1.1.3, , }>) b l = <{lieu.ville.bourg-en-bresse, temps.année.1928, pathologie.path-0.méningite}, {lieu.ville.turin, temps.année.1939, pathologie.path-0.asthme}> (equ. <{1.0.4, 2.2.4, 3.0.1},{1.0.10, , }>) b m = <{lieu.pays.italie, temps.année.1925, pathologie.path-0.méningite}, {lieu.pays.italie, temps.année.1928, pathologie.path-0.asthme}> (equ. <{1.2.2, 2.2.1, 3.0.1},{1.2.2, 2.2.4, }>) Le treillis construit à partir des identifiants de ces blocs comprend quatre sommets v 0,v 1,v 2 et v 4 avec les niveaux hiérarchiques suivants : - levels(v 0 ) = {ville, date, path-0} (equ. {0,0,0}) - levels(v 1 ) = {région, mois, path-0} (equ. {1,1,0}) - levels(v 2 ) = {ville, année, path-0} (equ. {0,2,0}) - levels(v 3 ) = {pays, année, path-0} (equ. {2,2,0}) Indépendamment de l'ordre d'insertion des blocs dans l'index, le treillis résultat prend la forme illustrée par la figure Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 60

79 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille v 3 v 1 v 2 v 0 répartition des identifiants de blocs sur les sommets du treillis : v 0 (equ. {0,0,0}) : b d, b e, b f, b g, b h v 1 (equ. {1,1,0}) : b k v 2 (equ. {0,2,0}) : b l v 3 (equ. {2,2,0}) : b m Figure 3.15 : Index en treillis de blocs matérialisés Grâce à cette structure, chaque sommet peut être atteint depuis tous les sommets ayant un niveau d'agrégation inférieur dans au moins une des dimensions. La recherche d'un sommet dans le treillis est toujours effectuée à partir du sommet racine qui indexe les données les plus détaillées. Comme décrit précédemment, un bloc de chunks est associé selon son niveau d'agrégation à un sommet de l'index T. Nous allons maintenant définir un index spatial en X-tree pour indexer les blocs de chunks dans l'espace multidimensionnel de données. 4.2 Index X sur les blocs de chunks Le X-tree (Berchtold et al., 1996) est une extension du R*-tree (Beckmann et al., 1990) qui minimise le nombre de zones indexées par plusieurs sous-arbres afin d'offrir un temps de recherche constant. Par rapport au R*-tree, le X-tree présente les caractéristiques suivantes : - Il introduit une limite supérieure de tolérance pour le chevauchement relatif de deux rectangles minimaux englobant caractérisant deux nœuds intermédiaires. - La division de nœuds intermédiaires est faite selon un algorithme basé sur l'historique des divisions de tous les sous-arbres dépendants si l'algorithme standard ne satisfait pas la contrainte de chevauchement maximum. - Des nœuds intermédiaires de capacité variable permettent d'éviter les fissions qui engendreraient un chevauchement au-delà du maximum toléré. Ceci permet à l'arbre de grandir «en largeur», augmentant ainsi la proportion de recherche séquentielle, préférable à la visite de plusieurs sous-arbres superposés dans la zone recherchée. Le X-tree reste équilibré en permanence et sa hauteur est limitée par rapport au nombre d'objets indexés. Une recherche dans l'arbre se fait donc en O(log n) Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 61

80 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille avec n le nombre de blocs indexés. Ce mécanisme rend le X-tree particulièrement bien adapté à l'indexation d'objets spatiaux ayant un grand nombre de dimensions. Or, l'ensemble de blocs associés à un sommet de l'index T peut être assimilé à un ensemble d'hyper-rectangles de l'espace multidimensionnel construit à partir des ensembles de membres de chaque dimension. La figure 3.16 présente l'association des sommets du treillis de l'index T et des blocs dans l'espace multidimensionnel (limité ici à deux dimensions) qui sont indexés par l'index X sur chaque sommet. TEMPS (année) b' b* v 3 v 1 v 2 TEMPS (date) LIEU (ville) v 0 b a b b b c LIEU (ville) Figure 3.16 : Index TX associant les sommets de l'index T en treillis et blocs de chunks dans l'espace multidimensionnel Soit M l'ensemble ordonné de membres de la dimension D i au niveau i li hiérarchique l i. L'espace de données est alors décrit par le produit cartésien 1 n M M. Les hyper-rectangles à indexer dans cet espace sont créés à l 1 l n partir des coordonnées des limites inférieures et supérieures des identifiants de blocs de chunks indexés par le sommet de l'index T. Pour connaître les blocs de chunks associés à chaque sommet de l'index T, nous introduisons un index, que nous appelons index X. Définition 3.14 : Index X des données multidimensionnelles L'index X est un X-tree qui indexe le contenu des données multidimensionnelles d'un ensemble de blocs associé à un sommet de l'index T. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 62

81 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Exemple 3.8 : Indexation spatiale au sein d'un sommet de l'index T Considérons le sommet v 0 avec levels(v 0 ) = {ville, date, path-0} (equ. {0,0,0}) présenté dans l'exemple 3.7. Comme nous l'avons vu, les blocs identifiés par ce sommet sont b d, b e, b f, b g, b h. La figure 3.17 illustre la représentation multidimensionnelle en hyper-rectangle de chacun de ces blocs. représentation des blocs de chunks dans l'espace multidimensionnel de membres : TEMPS (date) TEMPS (date) b e b h b e b h b f b f b g b g b d b d Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 3.17 : Représentation spatiale des blocs aux niveaux {ville,date,path-0} Les identifiants de blocs sont insérés un par un dans l'index X de v. Le X-tree que nous utilisons pour l'exemple est paramétré pour autoriser au maximum trois fils et au minimum un fils par nœud de l'arbre. Lors de l'insertion des cinq blocs, trois nœuds intermédiaires N1, N2 et N3 sont donc créés par division. Chaque nœud intermédiaire stocke les hyper-rectangles englobant minimum de ses fils. La structure finale de l'arbre est présentée en figure structure de l'index X du sommet v avec levels (v) = {ville, date, path-0} N1 N2 - N3 - - noeud racine noeud intermédiaire b d b e b f b g b h feuilles (identifiant de bloc de chunks) Figure 3.18 : Structure du X-tree hébergeant les blocs indexés aux niveaux {ville,date,path-0} Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 63

82 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille Comme le montre la figure 3.19, les identifiants de blocs de chunks sont regroupés dans l'espace multidimensionnel par les nœuds intermédiaires. Les hyper-rectangles englobant sont optimisés de façon à minimiser aussi bien l'espace vide couvert que les chevauchements. représentation des rectangles englobants du X-tree dans l'espace multidimensionnel de membres : N3 N2 N1 TEMPS (date) TEMPS (date) b e b h b e b h b f b f b g b g b d b d Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 3.19 : Structure de l'index X spatial hébergeant les blocs au niveaux {ville,date,path-0} Les relations d'ordre définies sur les ensembles de membres M,,M sont essentielles pour l'implémentation des opérations géométriques utilisées par l'index X puisque celles-ci reposent sur la notion de contiguïté et de proximité. En effet, en plus de calculer le volume et le contour d'un bloc en n dimensions, il s'agit de fournir l'intersection précise de deux blocs avec leur position relative dans l'espace. En utilisant le rang d'un membre dans l'ordre total comme coordonnée dans sa dimension, notre modèle permet de réaliser efficacement ces opérations. 1 l 1 n l n 4.3 Opérations sur l'index TX L'index TX sur un nœud de la grille est composé d'un index T identifiant les différents niveaux d'agrégation des données disponibles sur le nœud et, pour chaque sommet de l'index T, un index X identifiant les données multidimensionnelles associées. Nous introduisons ici les opérations de Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 64

83 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille maintenance, c'est-à-dire l'insertion et la suppression de blocs au sein de la structure d'index TX. L'index doit être mis à jour lorsque l'entrepôt est rafraîchi avec de nouvelles données et/ou lors du déplacement des données d'un nœud de la grille à l'autre Insertion dans l'index TX L'index des données disponibles sur un nœud de la grille est construit par insertions successives des identifiants de blocs matérialisés stockés sur ce nœud. L'opération d'insertion débute par la recherche d'un sommet de l'index T capable d'indexer le bloc à insérer. Le treillis est parcouru depuis sa racine vers les sommets indexant les données agrégées. Si le sommet recherché n'existe pas dans le treillis, il est créé à la position correspondante aux niveaux d'agrégation du bloc à insérer. L'insertion du nouveau sommet dans le treillis est décrite en détail par l'algorithme 3.1 présenté en annexe A. Une fois le bloc à insérer associé à un sommet de l'index T, celui-ci est inséré dans l'index X hébergé par ce sommet selon le mécanisme classique d'insertion dans les X-tree (Berchtold et al., 1996). Exemple 3.9 : Insertion d'un identifiant de bloc de chunks dans l'index TX Le fonctionnement de l'insertion dans l'index T est illustré à partir de l'exemple 3.7. Supposons que l'index TX indexe les blocs b d, b e, b f, b k et b l. Nous insérons alors l'identifiant de bloc de chunks b m de la façon suivante : b m = <{lieu.pays.italie, temps.année.1925, pathologie.path-0.méningite}, {lieu.pays.italie, temps.année.1928, pathologie.path-0.asthme}> (equ. <{1.2.2, 2.2.1, 3.0.1},{1.2.2, 2.2.4, }>) insertion du bloc b m dans l'index T : représentation de l'index X du sommet v 3 dans l'espace multidimensionnel de membres : TEMPS (date) TEMPS (date) v v 1 v 2 v 1 v b m b m v 0 v 0 identifiants de blocs indexés : v 0 (equ. {0,0,0}) : b d, b e, b f v 1 (equ. {1,1,0}) : b k v 2 (equ. {0,2,0}) : b l insertion de b m création du sommet v 3 (equ. {2,2,0}) ajout d'arêtes depuis v 1 et v 2 France Italie LIEU (pays) noeud racine méningite PATHOLOGIE (path-0) asthme Figure 3.20 : Opération d'insertion sur l'index TX Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 65

84 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille L'insertion de b m engendre une recherche en profondeur sur l'index T qui n'emploie que les chemins faits d'ancêtres du sommet v 3 tels que levels(v 3 ) = {pays,année,path-0} (equ. {2,2,0}). Comme un tel sommet n'existe pas dans l'index T, le sommet v 3 est créé, comportant un index X vide. Ce sommet est ensuite inséré dans le treillis de façon récursive afin d'obtenir une arête à l'extrémité de chaque chemin possible menant vers v 3. L'identifiant de bloc b m est ensuite inséré dans le X-tree de v 3, comme le montre la figure Suppression dans l'index TX Lors du déplacement de blocs de chunks parmi les nœuds de la grille et/ou lorsqu'un bloc de chunks devient indisponible sur un nœud de la grille, l'index TX est mis à jour par suppression de l'identifiant du bloc de chunks supprimé. La procédure de suppression débute par la recherche du sommet associé aux niveaux d'agrégation du bloc à supprimer dans l'index T. Le bloc est ensuite recherché et supprimé dans l'index X du sommet. Si le X-tree est vide suite à la suppression du bloc, alors le sommet et les arêtes associées sont à leur tour supprimés de l'index T. Si cette suppression crée un sommet isolé dans le graphe, alors une arête est créée depuis son ancêtre le plus proche. La mise à jour de l'index T est détaillée par l'algorithme 3.2 présenté en annexe A. Exemple 3.10 : Suppression d'un identifiant de bloc de chunks dans l'index TX Nous reprenons l'exemple 3.9 avec les blocs b d, b e, b f, b k, b l et b m indexés sur notre nœud de grille. Supposons que le bloc b k soit supprimé sur le nœud, nous allons donc supprimer son identifiant de l'index TX : b k = <{lieu.région.rhône Alpes, temps.mois , pathologie.path-0.méningite}, {lieu.région.piémont, temps.mois , pathologie.path-0.asthme}> (equ. <{1.1.2, 2.1.2, 3.0.1},{1.1.3, , }>) L'opération de suppression sur l'index T est illustrée par la figure Le bloc b k est recherché sur l'index T qui lui attribue le sommet v 1 puis sur l'index X associé à v 1. La suppression du bloc b k dans l'index X entraîne une mise à jour de l'index T. En effet, l'absence de blocs indexés par le X-tree du sommet v 1 avec levels(v 1 ) = {région,mois,path-0} déclenche la suppression de celui-ci dans le treillis. Les arêtes (v 0,v 1 ) et (v 1,v 3 ) sont supprimées. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 66

85 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille suppression du bloc b k dans l'index TX : v 3 v 3 v 1 v 2 v 2 v 0 identifiants de blocs indexés : v 0 (equ. {0,0,0}) : b d, b e, b f v 1 (equ. {1,1,0}) : b k v 2 (equ. {0,2,0}) : b l v 3 (equ. {2,2,0}) : b m v 0 suppression de b k suppression du sommet v 1 (equ. {1,1,0}) et des arêtes depuis v 0 et vers v 3 Figure 3.21 : Opération de suppression sur l'index T A l'aide des opérations d'insertion et de suppression, l'index TX peut fournir et maintenir à jour l'information sur les fragments d'entrepôt matérialisés sur un nœud. L'index T permet d'accéder rapidement aux niveaux d'agrégation disponibles et l'index X fournit l'information sur les positions dans l'espace multidimensionnel de données. 5 Conclusion Nous avons introduit dans ce chapitre un modèle multidimensionnel adapté aux exigences d'un entrepôt de données décentralisé réparti sur les nœuds d'une grille. L'ordonnancement des membres de dimension à travers les hiérarchies de dimension permet de créer des identifiants uniques pour l'ensemble des données matérialisées décrites par le modèle multidimensionnel. Il est ainsi possible d'identifier tous les réplicas disponibles d'une donnée entreposée parmi les nœuds de la grille. La méthode d'identification par chunks et blocs de chunks contigus que nous avons proposée permet de localiser rapidement l'ensemble des fragments d'entrepôt répondant à une requête. L'avantage par rapport à une solution basée sur la médiation est que ces identifiants référencent directement les fragments matérialisés sans nécessiter de transformation vers les schémas et formats spécifiques aux sources de données hétérogènes. Pour faciliter l'accès aux informations sur les blocs disponibles sur un nœud, nous avons conçu un mécanisme d'indexation utilisant les identifiants introduits. L'index TX regroupe les données de mêmes niveaux d'agrégation et indexe les composantes spatiales des blocs de chunks dans l'espace multidimensionnel de données. Au lieu de centraliser la gestion de la répartition des fragments, l'entrepôt réparti Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 67

86 3 Modélisation, identification et indexation des données multidimensionnelles matérialisées sur grille publie l'information sur la disponibilité par blocs de données de façon entièrement décentralisée à l'aide des index TX déployés sur chaque nœud. Les nœuds de la grille peuvent donc gérer les données multidimensionnelles qu'ils hébergent de façon autonome et répartissent ainsi la charge sans coordination centrale. De plus, l'information sur le modèle multidimensionnel ainsi répartie permet de déduire l'ensemble des agrégats calculables sur chaque nœud. Il nous faut intégrer cette information au mécanisme d'indexation de l'index TX. Cet aspect est développé par le chapitre suivant. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 68

87

88

89 Chapitre 4 Intégration et gestion des agrégats calculables Une grande partie des requêtes traitées par un entrepôt de données portent sur des agrégats, tels la somme ou la moyenne des mesures à différents niveaux de détail des dimensions. Ces requêtes nécessitent des calculs parfois coûteux sur les données détaillées. Il est classique qu'une partie de ces agrégats fréquemment utilisés peut être matérialisée par avance grâce aux capacités de stockage et de calcul mises à disposition par la grille. Comme nous l'avons vu au chapitre 3, les données détaillées et les agrégats matérialisés sont distribués et parfois répliqués sur les différents nœuds de la grille. Les agrégats manquants sont calculés à la volée au moment du requêtage. Il existe ainsi plusieurs stratégies pour l'obtention d'un agrégat. Ainsi, compte tenu de l'évolution de l'accessibilité des nœuds et des coûts de transfert, il est parfois plus judicieux de calculer un agrégat à partir des données existantes que de le transférer depuis un nœud distant. Pour sélectionner la meilleure stratégie, il est nécessaire de répertorier a priori les possibilités d'obtention des agrégats à partir des données détaillées ou d'autres agrégats de niveaux inférieurs. L'indexation des blocs de chunks que nous avons présenté au chapitre 3 recense l'ensemble des données détaillées et agrégats matérialisés sur un nœud de la grille. C'est pourquoi nous proposons d'étendre notre structure d'indexation à l'ensemble des données calculables à partir des données matérialisées. Pour cela, il nous faut : - déduire les données calculables à partir de données détaillées ou agrégats matérialisés sur un nœud, - recueillir les informations nécessaires à l'obtention de l'agrégat calculable, - étendre l'index TX à ces agrégats. 1 Principes d'obtention des agrégats calculables Les blocs de chunks matérialisés sur les nœuds de la grille sont représentés par leurs identifiants, comme introduits au chapitre 3. Ces identifiants sont indexés au niveau local sous forme d'hyper-rectangles dans l'espace de données multidimensionnel de chaque niveau d'agrégation existant sur le nœud. Les parties de cet espace recouvert par un ou plusieurs blocs représentent les données utilisables pour le calcul d'agrégats. La combinaison de blocs de données nécessaires à l'obtention d'un agrégat s'effectue dans l'espace multidimensionnel décrit par les schémas hiérarchiques et les instances locales des dimensions (voir chapitre 3). Nous appelons «blocs sources» les blocs utilisés pour le calcul des agrégats et «partie utile d'un bloc source» la partie réellement utilisée pour fournir l'agrégat. Afin de maximiser la taille des Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 71

90 4 Intégration et gestion des agrégats calculables agrégats, il est nécessaire dans un premier temps de détecter des volumes de données contigus parmi les données matérialisées. Ainsi, certains blocs de chunks matérialisés pourront être «fusionnés» dans la dimension d'agrégation. Cette fusion doit avoir la forme de bloc de chunks pour pouvoir servir de base pour la construction d'un bloc calculable au niveau agrégé. A leur tour, les blocs calculables pourront être utilisés pour calculer de nouveaux agrégats de niveaux supérieurs. L'information sur les blocs sources et les parties à en extraire doit être associée à l'agrégat calculable. Ces informations seront utiles lors de l'exécution de requêtes. De plus, s'il existe plusieurs stratégies d'obtention d'un agrégat calculable, l'estimation du coût d'extraction de la partie utile de chaque bloc source sera utilisée. Ainsi, la liste de blocs sources nécessaires pour obtenir un bloc calculable est intégrée dans une structure de plan de calcul associé au bloc calculable. Pour chaque bloc source, le plan contient également le bloc désignant la partie utile du bloc source et l'estimation de coût pour son extraction. 2 Construction de blocs de chunks calculables Un bloc de chunks calculable est un bloc de chunks au sens de la définition introduite au chapitre 3. Ses chunks ne sont pas matérialisés sur le nœud, mais peuvent être obtenus à partir de l'agrégation de chunks matérialisés sur ce nœud. Le bloc de chunks calculable est décrit par un identifiant de bloc, associé à un plan de calcul référençant les blocs sources, les parties extraites de ceux-ci et le coût estimé de cette extraction. A partir d'un bloc source, on peut obtenir un nouveau bloc calculable contenant un chunk pour le membre m si le bloc source contient des chunks pour tous les membres fils de m. Suite à la fragmentation et au comportement dynamique de l'entrepôt, il se peut que les fils nécessaires au calcul d'une agrégation ne soient pas dans le même bloc de chunks mais dans plusieurs blocs sur le même nœud. Dans ce cas, il est intéressant de construire des assemblages de blocs du nœud afin de constituer un bloc source contenant tous les fils nécessaires. Cet assemblage est réalisé en fusionnant géométriquement les blocs sources dans l'espace multidimensionnel. 2.1 Fusion géométrique de blocs de chunks L'intérêt de regrouper les blocs de chunks disponibles par une opération de fusion géométrique réside dans la possibilité d'obtenir des chunks agrégés dont les descendants sont initialement répartis sur plusieurs blocs sources. Prenons par exemple un bloc de chunks, identifié par b x, contenant des chunks pour tous les membres au niveau mois entre janvier et septembre 1925 dans la dimension «temps» et b y contenant des chunks pour tous les membres d'octobre 1925 à juin b x et b y permettent de calculer un bloc d'agrégats au niveau «année» pour le membre 1925 si les membres associés aux chunks de b x et b y dans les autres dimensions sont identiques. Ainsi, un chunk associé par exemple à la Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 72

91 4 Intégration et gestion des agrégats calculables ville de Nice dans la dimension «lieu» ne peut être utilisé avec un chunk associé à Lyon pour calculer le chunk agrégé contenant les agrégats pour l'année 1925 sur la ville de Lyon. Il est nécessaire de déterminer comment les positions relatives de plusieurs blocs dans l'espace multidimensionnel peuvent permettre leur fusion en vue de l'obtention d'un bloc calculable. Soient b et b' deux blocs de chunks tels que : - b et b' sont adjacents ou bien b et b' ont une intersection non nulle sur la dimension D i au niveau j, - et b et b' ont une intersection non vide sur toutes les autres dimensions, alors on peut extraire le bloc de chunk maximum noté fusion(b,b',d i ) contenu dans l'union des blocs de chunks b et b'. Ce bloc de chunks correspond à l'hyper-rectangle contenu dans l'union géométrique des hyper-rectangles représentant b et b' couvrant le maximum de membres dans la dimension D i et correspondant à l'intersection de b et b' dans les autres dimensions. Notons m1, m 2 l'intervalle des membres du bloc b dans la dimension D i au niveau j et m1, m l'intervalle des membres du bloc b' dans la dimension D 2 i au niveau j, alors l'adjacence de b et b' est vérifiée si : m2, m1 m2 m1 m2, m1 m2 m 1 L'intersection de b et b' est vérifiée si : m1, m2 m1, m 2 Lorsque deux blocs sont ainsi adjacents ou ont une intersection non nulle sans être entièrement superposés dans la dimension D i, leur inclusion dans un bloc calculable agrégé dans cette dimension est pertinente. En effet, les chunks de données complémentaires inclus dans le bloc calculable permettent l'obtention d'un ensemble d'agrégats maximum dans la dimension D i. Nous formalisons cette combinaison des blocs sources et définissons ainsi la fusion de blocs de chunks. Définition 4.1 : Fusion de blocs de chunks La fusion dans la dimension D i de deux identifiants de blocs de chunks b et b' adjacents ou ayant une intersection non vide, notée fusion(b,b',d i ) est le plus grand hyper-rectangle contenu dans l'union géométrique de b et b'. L'identifiant de fusion(b,b',d i ) est composé des membres de l'intersection de b et b' dans toutes les dimensions D j avec j 1,..., n, j i et les membres de l'union de b et b' dans la dimension D i. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 73

92 4 Intégration et gestion des agrégats calculables L'exemple qui suit illustre les possibilités de fusion de deux blocs de chunks en vue d'une création d'un bloc de chunks regroupant les données sources pour un bloc calculable. Nous détaillons le cas où les blocs sont adjacents dans plusieurs dimensions et le cas où les blocs sont en partie superposés. Exemple 4.1 : Fusion de blocs de chunks Le cas particulier des blocs de chunks adjacents dans une dimension est illustré par la figure 4.1. Cet exemple utilise les deux blocs de chunks b 1 et b 2 aux niveaux levels(b 1 ) = levels(b 2 ) = {ville, date, path-0}, qui ont une intersection vide. positions de blocs de chunks adjacents sans intersection et de leur fusion dans la dimension «temps» : fusion dans la dimension «temps» TEMPS (date) TEMPS (date) b 1 b b 2 b Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 4.1 : Fusion de blocs de chunks adjacents dans la dimension «temps» Pour la dimension «temps» D 2, l'intersection entre b 1 et b 2 est vide. Bien que les intersections dans les autres dimensions soient toutes non nulles, l'intersection dans l'espace multidimensionnel est également vide. Il est néanmoins possible de créer un intervalle contigu de membres, car les intervalles de membres en D 2 se touchent : ' ',' ' ' ' ' ' Les blocs b 1 et b 2 peuvent donc être fusionnés, mais uniquement dans la dimension «temps». Le résultat de la fusion sera le nouveau bloc ayant pour identifiant : fusion(b 1,b 2,D 2 ) = <{lieu.ville.toulon, temps.date , pathologie.path-0.méningite}, Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 74

93 4 Intégration et gestion des agrégats calculables {lieu.ville.bourg-en-bresse, temps.date , pathologie.path-0.épilepsie}> (equ. <{1.0.1, 2.0.1, 3.0.1},{1.0.4, , 3.0.6}>) Le deuxième cas illustré dans cet exemple est basée sur deux blocs identifiés par b 3 et b 4 aux niveaux levels(b 3 ) = levels(b 4 ) = {ville, date, path-0}, dont les positions relatives sont présentées en figure 4.2. Nous obtenons une intersection non nulle entre les deux identifiants de blocs : b3 b 4 = <{lieu.ville.bourg-en-bresse, temps.date , pathologie.path-0.méningite}, {lieu.ville.lyon, temps.date , pathologie.path-0.épilepsie}> (equ. <{1.0.4, , 3.0.1},{1.0.7, , 3.0.6}>) positions de blocs de chunks et de leur fusion dans les dimensions «temps» et «lieu» : fusion dans la dimension «temps» fusion dans la dimension «lieu» TEMPS (date) TEMPS (date) b 3 b b b Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 4.2 : Fusion de blocs de chunks dans les dimensions «temps» et «lieu» En conséquence, la fusion de b 3 et b 4 est possible dans toutes les dimensions. Pour les dimensions «lieu» D 1 et «temps» D 2, les blocs fusionnés sont illustrés en figure 4.2. Pour la dimension «pathologie» D 3, la fusion est égale à l'intersection, donc plus petite qu'au moins l'un des deux blocs. Elle n'est donc pas intéressante pour un bloc calculable dans la dimension D 3 regroupant b 3 et b 4. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 75

94 4 Intégration et gestion des agrégats calculables L'opération de fusion permet de faire émerger des hyper-rectangles maximum au niveau i d'une dimension qui seront utilisés pour le calcul d'agrégats au niveau i Parties utiles pour l'obtention du bloc calculable La fusion d'un ou plusieurs blocs sources au niveau i sert de base à la construction d'un bloc calculable sur le niveau i+1 de la dimension sélectionnée. A partir des identifiants de blocs fusionnés et des instances locales des dimensions, il est possible de construire les identifiants de blocs calculables au niveau i+1. Les blocs de chunks étant composés de chunks ordonnés et contigus, il suffit d'utiliser les limites inférieures et supérieures du bloc fusionné au niveau i et le schéma hiérarchique de la dimension pour en déduire l'ensemble des chunks calculables au niveau i+1. L'algorithme pour la construction du bloc de chunks calculable transpose au niveau i+1 l'intervalle que représente la fusion au niveau i, en éliminant les membres au niveau i+1 pour lesquelles tous les descendants ne sont pas représentés dans la fusion des blocs sources. Il construit ainsi des intervalles aux extrémités du bloc fusion qui ne sont pas utilisables pour le calcul de l'agrégat au niveau supérieur. Pour déterminer les parties utiles de chaque bloc source, ces intervalles «inutiles» sont enlevés dans la partie que chaque bloc source contribue à la fusion. Lors de cette opération, les parties utiles b p des blocs sources b s, c'est-à-dire les chunks réellement utilisés pour le calcul de l'agrégat, sont identifiés. Par exemple, en prenant les blocs b x et b y, avec b x contenant des chunks pour tous les membres au niveau mois entre janvier et septembre 1925 dans la dimension «temps» et b y contenant des chunks pour tous les membres d'octobre 1925 à juin La fusion des deux blocs dans la dimension «temps» contient donc les membres de janvier 1925 à juin 1926 inclus. La transposition de la fusion vers le niveau année contient uniquement le membre 1925, car tous les mois de 1926 ne sont pas couverts par la fusion. Pour constituer l'agrégat pour l'année 1925, il nous faut utiliser tous les chunks de b x et une partie des chunks de b y. La partie utile dans la dimension «temps» du bloc source b x est donc constituée de l'intervalle allant de janvier à juin 1925, celle du bloc source b y de l'intervalle allant de juillet à décembre L'exemple qui suit illustre la procédure pour le cas multidimensionnel. Exemple 4.2 : Parties utiles de blocs sources associées à un bloc de chunks calculable Nous prenons comme exemple la construction du bloc calculable b c1 à partir de la fusion de deux blocs source matérialisés b 5 et b 6. La figure 4.3 présente les positions dans l'espace multidimensionnel de ces blocs. Pour chacun des blocs sources, nous sélectionnons la partie utile du bloc pour le calcul de b c1. Comme le montre la figure 4.3, l'intégralité des chunks du bloc b 5 est utilisée pour le calcul de b c1. Nous obtenons donc un identifiant de partie utile b p5 = b 5. Parmi Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 76

95 4 Intégration et gestion des agrégats calculables les chunks de b 6, seuls ceux entre Marseille et Grenoble dans la dimension «lieu» et entre méningite et épilepsie dans la dimension «pathologie» sont utilisés au moment de calculer b c1. De plus, nous constatons que b p6, la partie utile de b 6, ne contient qu'une partie des chunks sources nécessaires au niveau «date» dans la dimension «temps» pour couvrir le membre ' ' au niveau «mois». b c1 ne contient donc pas de chunks associés à ce membre et b p6 est réduit en conséquence. positions de la fusion dans la dimension «temps» de deux blocs sources : fusion dans la dimension «temps» TEMPS (date) TEMPS (date) b b b 5 b Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme position du bloc de chunks calculable construit à partir de la fusion des deux blocs sources : TEMPS (mois) TEMPS (mois) b c b c Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 4.3 : Blocs sources fusionnés dans la dimension «temps» pour créer un bloc calculable aux niveaux {ville, mois, path-0} Nous obtenons donc b p6 par l'intersection entre la fusion de b 5 avec b 6 et b 6 et la suppression des chunks sources associés au membre ' ' dans la Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 77

96 4 Intégration et gestion des agrégats calculables dimension «temps». Pour le bloc calculable b c1, nous obtenons donc la liste de blocs sources L c (b c1 ) = {<b p5, b 5 >, <b p6, b 6 >}, où : b p5 = b 5, b p6 = <{lieu.ville.marseille, temps.date , pathologie.path-0.méningite}, {lieu.ville.grenoble, temps.date , pathologie.path-0.épilepsie}> (equ. <{1.0.3, , 3.0.1},{1.0.6, , 3.0.6}>) 2.3 Plans de calcul associés aux blocs calculables L'objectif du plan de calcul que nous construisons et associons à chaque bloc calculable est de faciliter l'exécution de requêtes en permettant d'accéder à l'ensemble de l'information sur les blocs sources utilisés par le bloc calculable. Les éléments du plan de calcul d'un bloc calculable sont les blocs de chunks sources, leurs parties utiles pour l'obtention du bloc calculable et une estimation de coût pour l'extraction des parties utiles. Nous définissons ce plan de calcul de la façon suivante : Définition 4.2 : Plan de calcul associé à un bloc de chunks calculable Un plan de calcul P c associé à un bloc de chunks calculable b c est un ensemble de tuples {<b p1, S 1, coutextraction(b p1, S 1 )>,, <b pn, S n, coutextraction(b pn, S n )>} où : - b pi est l'identifiant de la partie utile de S i qui contribue au calcul de b c, - S i est l'identifiant du bloc source utilisé pour l'obtention de b pi. S i est soit un bloc matérialisé, soit un bloc calculable, - coutextraction(b pi, S i ) représente le coût estimé pour extraire la partie utile b pi à partir de S i. Le calcul de coût d'extraction de b p à partir d'un bloc source S dépend si S est matérialisé ou non. Le coût d'extraction de b p à partir d'un bloc matérialisé S est fonction du nombre de chunks de b p, du nombre de chunks de S et des coûts de lecture sur le système de fichiers. Le nombre de chunks de b p est lié au nombre de chunks de la source S ayant pour identifiant b s. Afin de pouvoir estimer le coût d'extraction, nous prenons en compte le nombre de chunks nbchunks(b s ) matérialisés de chaque bloc source b s. La proportion de ces chunks qu'il faut extraire pour obtenir la partie utile est estimée à l'aide du ratio entre les volumes volume(b p ) de la partie utile b p par rapport au bloc source entier dans l'espace multidimensionnel de données. nbchunks b p nbchunks b s volume bp * volume b s Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 78

97 4 Intégration et gestion des agrégats calculables Si on note chunksparpage le nombre de chunks stockés sur une page disque et tempsaccespage le temps moyen pour accéder à une page disque, alors le coût d'extraction pour la partie utile b p d'un bloc matérialisé b s est calculé comme suit : nbchunks bp coutextraction bp, bs * tempsaccespage chunksparpage Si b p est obtenu à partir du bloc calculable S, alors S est associé à un plan de calcul P s avec P s = {<b' p1, S' 1, coutextraction(b' p1,s' 1 )>,, <b' pm, S' m, coutextraction(b' pm,s' m )>. Le coût d'extraction de b p selon le plan de calcul associé à S est la somme des coûts d'extraction des blocs de P s. Nous obtenons donc : m coutextraction b, S coutextraction b, S p pj j j 1 Chaque S' j peut lui-même être un bloc matérialisé ou calculable. Ce processus de calcul des coûts est un procès itératif qui s'arrête lorsque tous les blocs intervenants dans les plans de calcul sont matérialisés. Exemple 4.3 : Plan de calcul associé à un bloc calculable Nous allons illustrer la structure de plan de calcul à l'aide d'un bloc calculable b c1 aux niveaux d'agrégation {ville, mois, path-0} (equ. {0,1,0}), comme introduit par l'exemple 4.2. Comme le montre la figure 4.4, le bloc calculable b c1 est obtenu à l'aide des parties utiles des deux blocs sources b 5 et b 6 aux niveaux {ville, date, path-0} (equ. {0,0,0}). Le plan de calcul P c1 associé à b c1 comporte donc les deux tuples <b p5, b 5, coutextraction(b p5, b 5 )> et <b p6, b 6, coutextraction(b p6, b 6 )>. Nous obtenons les valeurs suivantes pour le nombre de chunks à extraire nbchunks(b p ) : volume bp5 nbchunks bp5 nbchunks b5 * volume b 5 3;4 * 1;36 * 1; chunks * 648 chunks * 3;4 * 1;36 * 1; chunks Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 79

98 4 Intégration et gestion des agrégats calculables nbchunks b nbchunks b p6 6 volume b * volume b p6 6 3;7 * 37;60 * 1; chunks * 1050 chunks * 1;7 * 37;61 * 1; chunks positions des parties utiles de deux blocs sources intégrées à un plan de calcul : TEMPS (date) TEMPS (date) b 6 b p b b 5 b p5 b Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 4.4 : Eléments sources d'un bloc calculable sur l'index X du nœud LYON L'estimation du coût d'accès en temps de chargement dépend du nombre de chunks stockés sur une page disque chunksparpage = 32 et du temps moyen d'accès à une page disque tempsaccespage = 8ms. A l'aide de ces valeurs nous obtenons les résultats suivants : nbchunks bp5 coutextraction bp5, b5 * tempsaccespage chunksparpage 648 *8 ms 162 ms 32 nbchunks bp6 coutextraction bp6, b 6= * tempsaccespage chunksparpage 540 *8 ms 135 ms 32 Le plan de calcul P c1 associé à b c1 est donc représenté de la façon suivante : P c1 = {<b p5, b 5, 162ms>, <b p6, b 6, 135ms>} Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 80

99 4 Intégration et gestion des agrégats calculables Nous avons vu comment on pouvait identifier des blocs de chunks calculables et élaborer les plans de calcul associés. Le processus de mise en évidence des blocs de chunks calculables doit être déclenché à chaque fois que les données matérialisées évoluent sur le nœud de la grille, c'est-à-dire à chaque fois qu'un bloc matérialisé est inséré ou supprimé du nœud. Ce processus est donc intégré aux opérations de mise à jour dynamique de l'index. Ainsi, lors de la recherche de données répondant à une requête, nous connaîtrons pour chaque nœud la totalité des données qui sont disponibles sur ce nœud, matérialisées et/ou calculables. 3 Indexation dynamique des agrégats calculables Lorsqu'un bloc de chunks est matérialisé ou supprimé sur un nœud de la grille, l'index TX est mis à jour. Cette procédure s'applique aussi bien lors du déploiement initial des fragments de l'entrepôt de données sur la grille que pour les mouvements de blocs matérialisés en phase d'exploitation. Dans les deux cas, l'ensemble des blocs calculables dans l'index qui dépendent du bloc matérialisé inséré ou supprimé doivent être mis à jour afin d'assurer la cohérence des informations de l'index concernant la disponibilité des données sur un nœud. Nous commençons par le mécanisme d'insertion d'un nouveau bloc de chunks matérialisé conduisant à l'insertion d'un ou plusieurs blocs calculables. 3.1 Insertion des blocs calculables dans l'index TX L'insertion d'un identifiant de bloc matérialisé b m dans l'index TX, comme décrit au chapitre 3, déclenche une mise à jour récursive qui crée ou modifie les blocs calculables à partir de b m. Si le bloc b m est inséré au sein d'un sommet v de l'index T aux niveaux hiérarchiques levels(v) = {l 1,.., l n }, alors nous pouvons déterminer la partie du treillis de l'index T susceptible d'indexer des blocs calculables utilisant b m comme source. Soient a 1,,a n les niveaux «all», i.e. les plus agrégés des hiérarchies, pour les dimensions D 1,,D n. La partie du treillis à mettre à jour contient tous les sommets v' du treillis avec levels(v') = {l' 1,.., l' n } pour lesquels li li ai i 1,, n. Par exemple, si le bloc b m est indexé aux niveaux levels(v) = {région, mois, path-0} (equ. {1,1,0}), alors les sommets concernés pas la mise à jour sont tous ceux avec un niveau entre pays(2) et «all»(3) dans la dimension «lieu», un niveau entre année(2) et «all»(3) dans la dimension «temps» et un niveau entre path-1(1) et «all»(4) dans la dimension «pathologie». Notre méthode se distingue de l'approche de la «Virtual Count Based Method» (VCM), présentée par (Deshpande et al., 2000), qui maintient pour chaque agrégat calculable un compteur représentant le nombre de «chemins» à travers le treillis à l'aide desquels cet agrégat peut être obtenu. Alors que cette approche nécessite une recherche sur tous les ancêtres d'un sommet dans le treillis pour retrouver les données sources, notre approche met en relation les blocs indexés sur un sommet de l'index T avec les niveaux d'agrégation Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 81

100 4 Intégration et gestion des agrégats calculables directement supérieurs dans chacune des dimensions. Ainsi, pour chaque sommet, nous prenons en compte les positions relatives des blocs au sein de son index X pour créer des blocs calculables qui sont insérés sur les sommets qui sont ses successeurs directs dans le treillis. Notre sommet exemple v avec levels(v) = {région, mois, path-0} (equ. {1,1,0}) va donc générer des blocs calculables pour les niveaux {pays, mois, path-0} (equ. {2,1,0}), {région, année, path-0} (equ. {1,2,0}) et {région, mois, path-1} (equ. {1,1,1}). Les blocs calculables pertinents sont déterminés en utilisant l'index X du sommet v. L'identifiant de bloc b m qui vient d'être inséré est l'élément déclencheur de la construction de blocs calculables utilisant b m et les autres blocs indexés par l'index X. Pour chaque dimension D i où le niveau «all» n'est pas encore atteint, l'ensemble des blocs qu'il est possible de fusionner avec b m est recensé. Les fusions possibles de b m avec ces blocs sont ensuite évaluées par un algorithme de programmation dynamique présenté en annexe A (algorithme 4.1). Le ou les blocs calculables qui en résultent sont finalement insérés dans l'index X du sommet v' aux niveaux levels(v') = {l 1,,l i +1,,l n }, ce qui déclenche à son tour la mise à jour des successeurs de v'. Exemple 4.4 : Mise à jour de l'index TX suite à l'insertion d'un bloc matérialisé Cet exemple illustre la mise à jour d'un index TX à l'aide des opérations d'insertion de deux blocs de chunks agrégés matérialisés b 7 et b 8 aux niveaux levels(b 7 ) = levels(b 8 ) = {région, mois, all} (equ. {1,1,4}). Nous supposons qu'au départ il n'y a pas de bloc indexé à ce niveau d'agrégation. Les blocs b 7 et b 8 sont insérés l'un après l'autre dans l'index TX. L'insertion de b 7 engendre la création du sommet v 4 avec levels(v 4 ) = {région, mois, all} (equ. {1,1,4}). Nous commençons par déterminer la partie du treillis de l'index T concernée par la mise à jour des blocs calculables. La dimension «pathologie» ne peut être plus agrégée, donc la partie du treillis mise à jour suite à l'insertion de b 7 et b 8 comprend les sommets des niveaux pays et «all» dans la dimension «lieu» et année et «all» dans la dimension «temps». La mise à jour récursive déclenchée par l'insertion de b 7 produit un seul bloc calculable b c7 inséré sur le sommet v 5, levels(v 5 ) = {région, année, all} (equ. {1,2,4}), avec comme seul bloc source b 7. La recherche d'autres blocs calculables à partir de b 7 aux niveaux «all» dans la dimension «temps» et aux niveaux pays et «all» dans la dimension «lieu» ne donne aucun résultat. Nous insérons donc le bloc matérialisé b 8. La figure 4.5 montre la situation de la partie de l'index TX concernée après l'insertion de b 8. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 82

101 4 Intégration et gestion des agrégats calculables positions de blocs de chunks matérialisés et d'un bloc calculable sur plusieurs sommets : TEMPS (mois) v 4 v 5 b 7 b 8 TEMPS (année) b c7 PACA Rhône Alpes Piémont LIEU (région) PACA Rhône Alpes Piémont LIEU (région) Figure 4.5 : Index TX après insertion d'un bloc matérialisé avant la mise à jour des blocs calculables dans les dimensions «lieu» et «temps» La mise à jour des blocs calculables suite à l'insertion de b 8 commence par rechercher les possibles agrégats dans la dimension «lieu». La figure 4.6 montre qu'aux niveaux {pays, mois, all}, il est possible de calculer l'agrégat pour la France à partir de b 8. Nous insérons donc un sommet v 6 avec levels(v 6 ) = {pays, mois, all} (equ. {2,1,4}) pour indexer le bloc calculable b c8. positions de blocs de chunks calculables dépendants sur plusieurs sommets : TEMPS (mois) v 4 v 6 b 7 b 8 TEMPS (mois) b c8 TEMPS (année) v 7 b' c8 PACA Rhône Alpes Piémont LIEU (région) France Italie LIEU (pays) France Italie LIEU (pays) Figure 4.6 : Index TX après l'insertion des blocs calculables dépendants uniquement de b 8 Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 83

102 4 Intégration et gestion des agrégats calculables L'insertion de ce bloc sur v 6 déclenche à son tour la création d'un sommet v 7 avec levels(v 7 ) = {pays, année, all} (equ. {2,2,4}) pour indexer un deuxième bloc calculable b' c8, toujours basé sur b 8. Comme le montre la figure 4.6, les chunks agrégés pour l'année 1931 ne sont pas disponibles car b 8 ne couvre que les 6 derniers mois de cette année-là. Pour créer un bloc calculable optimal en agrégeant la dimension «temps» à partir du sommet v 4, les blocs b 7 et b 8 sont fusionnés dans cette dimension. Comme le montre la figure 4.7, cette fusion permet d'indexer aux niveaux {région, année, all} un bloc calculable b c78 inséré sur le sommet v 5. Pour l'année 1931, b 8 fournit les chunks pour les 6 derniers mois, ce qui permet d'inclure les chunks agrégés pour cette année dans b c78. La partie de b 8 non couverte par la fusion est utilisée pour créer un deuxième bloc calculable b* c8. Nous constatons également que b c7, le bloc précédemment inséré sur v 5, est entièrement couvert par b c78 et peut être supprimé. position du bloc de chunks calculable mis à jour suite à une insertion : v 4 TEMPS v 5 (année) TEMPS fusion dans la (mois) dimension «temps» b 7 b b* c b c78 PACA Rhône Alpes Piémont LIEU (région) PACA Rhône Alpes Piémont LIEU (région) Figure 4.7 : Insertion d'un bloc calculable issu de la fusion de deux blocs source dans l'index TX La recherche de blocs calculables sur l'index X de v 5 suite à cette insertion ne fournit aucun nouveau bloc calculable pertinent pour l'agrégation dans la dimension «lieu». L'indexation récursive des blocs calculables à travers l'index TX permet de recenser tous les agrégats qu'il est possible d'obtenir grâce aux blocs matérialisés hébergés par un nœud de grille. En fonction des niveaux d'agrégation de bloc matérialisé inséré dans l'index, la mise à jour peut être Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 84

103 4 Intégration et gestion des agrégats calculables coûteuse. Néanmoins, l'étendue de la mise à jour de l'index est limitée par deux facteurs. Le premier facteur est le phénomène d'épuisement des chunks disponibles au fil des agrégations. Comme le démontre l'exemple ci-dessus, cet effet intervient au moment où les chunks présents à un niveau hiérarchique i ne sont plus suffisants pour constituer un chunk agrégé au niveau i+1 car on ne dispose pas de tous les fils nécessaires. Le deuxième facteur intervient lorsqu'un nouveau bloc calculable est déjà entièrement inclus dans les blocs indexés par l'index X sur un sommet v. Si le nouveau bloc calculable ne présente pas un avantage au niveau des coûts d'extraction estimés par rapport aux blocs existants, il n'est pas inséré dans l'index et la mise à jour ne va pas au-delà de v. Comme l'insertion de nouveaux blocs, la suppression d'un bloc provoque une mise à jour récursive à travers la partie de l'index T susceptible d'indexer des blocs calculables dépendants du bloc supprimé. 3.2 Suppression des blocs calculables dans l'index TX La mise à jour de l'index TX après la suppression d'un identifiant de bloc matérialisé b m concerne uniquement les blocs calculables indexés dépendant de b m. Soit v le sommet de l'index T aux niveaux hiérarchiques levels(v) = {l 1,.., l n }. Une fois b m supprimé dans l'index X de v, comme décrit au chapitre 3, les blocs calculables touchés par cette suppression sont recherchés et modifiés. La partie de l'index T susceptible de contenir ces blocs est identique à celle identifiée pour la mise à jour après une insertion sur v. L'ordre dans lequel cette partie est parcourue reste également inchangé, la principale différence avec la procédure d'insertion réside dans l'adaptation des blocs de chunks touchés par la suppression de b m. En effet, lorsque l'identifiant de bloc calculable b c dépendant de b m doit être modifié, notre méthode prévoit plusieurs étapes afin de limiter l'impact de la suppression sur la disponibilité des données. Soit v' le sommet de l'index T sur lequel est indexé b c et v le sommet ancêtre sur lequel b m a été supprimé. La première étape consiste à évaluer l'impact de la suppression sur le bloc calculable en déterminant l'identifiant de bloc bm b c qui correspond à la partie calculée à partir de b m que contribue b m à b c. Ensuite, les sommets ancêtres v* v de v' sont consultés pour vérifier s'il existe un b m* indexé sur v* qui peut remplacer b m pour fournir b' m. Par exemple, si levels(v) = {région, année, path-0} (equ. {1,2,0}) et levels(v') = {pays, année, path-0} (equ. {2,2,0}), alors les sommets v* peuvent avoir les niveaux {pays, mois, path-0} (equ. {2,1,0}) ou {pays, date, path-0} (equ. {2,0,0}). Si un remplaçant pour b' m est trouvé, celui-ci va être intégré dans b c. Par contre, s'il n'existe aucun remplacement, le bloc calculable doit être modifié ou reconstruit à partir des blocs sources restants. Dans le cas où b c peut être Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 85

104 4 Intégration et gestion des agrégats calculables diminué de b' m tout en restant un bloc calculable contigu, il est modifié puis réinséré dans l'index X de v' sans déclencher une mise à jour de l'index TX supplémentaire. Dans l'autre cas, b c est supprimé de v', sans déclencher de mise à jour parmi les descendants de v'. Les blocs sources de b c qui n'ont pas été supprimés sont utilisés pour la construction de blocs calculables remplaçant les parties de b c qui sont encore calculables. L'ensemble de blocs calculables résultat R c = {b rc1,,b rct } est inséré dans v', la différence R diff entre et les éléments de R c est considérée comme supprimée sur v' : t R b \ b, R b,, b diff c b rci c rc1 rct i 1 La mise à jour des sommets descendants de v' provoquée par la suppression de b c prend en compte les ensemble R c et R diff. Ceci permet d'inclure le remplacement de b c dans le processus de mise à jour récursive. Exemple 4.5 : Mise à jour d'un bloc calculable dans l'index TX suite à la suppression d'un bloc matérialisé Nous reprenons l'exemple 4.4 avec l'index TX entièrement mis à jour. Supposons que par la suite, l'identifiant de bloc b 8 soit supprimé de l'index TX, car le bloc matérialisé correspondant a été déplacé vers un autre nœud de la grille. TEMPS (mois) v 4 TEMPS v 5 (année) partie déduite suite 1939 à suppression b 7 b b* c b c78 nouveau bloc inséré suite à suppression PACA Rhône Alpes Piémont LIEU (région) PACA Rhône Alpes Piémont LIEU (région) Figure 4.8 : Mise à jour d'un bloc calculable suite à la suppression d'un bloc matérialisé Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 86

105 4 Intégration et gestion des agrégats calculables C'est sur le sommet v 4 avec levels(v 4 ) = {région, mois, all} (equ. {1,1,4}) que b 8 est retrouvé et supprimé dans l'index X. La recherche de blocs calculables dépendants de b 8 commence sur le sommet v 5 avec levels(v 5 ) = {région, année, all} (equ. {1,2,4}). Le bloc calculable b c78 doit être modifié pour prendre en compte la suppression des chunks contenus dans la partie contribuée par b 8. Comme le montre la figure 4.8, b c78 peut être diminué sans perdre sa structure de bloc calculable. En conséquence, il ne reste que b 8 comme seul bloc source pour le calcul de b c78. La suite de la mise à jour supprime les blocs calculables b c8 sur le sommet v 6 et b' c8 sur le sommet v 7. Comme les sommets v 6 et v 7 n'ont plus de blocs indexés sur leur index X, ces sommets sont supprimés de l'index T. Les opérations d'insertion et de suppression de blocs de chunks matérialisés dans l'index TX d'un nœud de la grille permettent ainsi de maintenir à jour les informations détaillées sur l'ensemble des données que peut fournir chaque nœud. 4 Conclusion L'intégration des agrégats calculables dans notre méthode d'indexation s'appuie sur le modèle multidimensionnel adapté que nous avons introduit au chapitre 3. Les index locaux permettent de connaître l'ensemble des données matérialisées sur chaque nœud, mais aussi l'ensemble des agrégats qui peuvent être calculés à la volée à partir de ces données matérialisées. La consultation des données calculables est aussi rapide que pour les données matérialisées car l'index X spatial chargé de recenser les composantes spatiales des blocs de données indexe les blocs calculables de façon entièrement transparente. Lors de la construction de blocs calculables, toute l'information nécessaire à leur calcul est stockée dans un plan de calcul associé. Ce plan est conçu pour être directement exploitable pour le traitement de requêtes et comporte déjà les estimations de coûts statiques indispensables pour une optimisation de l'exécution de requêtes. La construction du plan de calcul pour chaque bloc calculable évite en conséquence les longues recherches de données répondant à une requête. Toutes les opérations complexes d'optimisation de la construction des blocs calculables sont effectuées lors de la mise à jour de l'index TX. Au moment de la recherche de données répondant à une requête, l'index fournit les blocs matérialisés et calculables disponibles sans traitement préalable. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 87

106

107 Chapitre 5 Exécution et optimisation de requêtes L'utilisateur va accéder à l'entrepôt et effectuer ses requêtes sur le nœud de la grille sur lequel il est connecté au travers d'une interface client. Cette interface client doit lui permettre de requêter l'entrepôt dont la répartition doit rester transparente. L'utilisateur aura ainsi accès à un entrepôt que nous appelons entrepôt virtuel comme si celui-ci était centralisé. Compte tenu de la puissance de stockage et de calcul fournie par la grille, l'utilisateur doit recevoir rapidement les données qu'il recherche ainsi que les agrégats les plus complexes sur ces données. Pour répondre à ces exigences, le système d'entrepôt réparti doit être associé à un mécanisme de traitement de requêtes OLAP optimisé pour minimiser le temps de réponse à une requête utilisateur. L'environnement de grille est généralement hautement dynamique et varie en fonction de la disponibilité des ressources (données, nœuds, réseau). La solution que nous proposons est la suivante : Dans un premier temps, le processus d'exécution de requêtes doit disposer des informations sur la disponibilité des données demandées sur la grille. Il recense ensuite les différents choix possibles pour l'obtention du résultat de la requête. Ce résultat peut être obtenu par des données directement stockées sur un ou plusieurs nœuds de la grille ou à partir de données détaillées qui devront être agrégées à la volée. La solution correspondant au temps de réponse estimé minimal est ensuite choisie. Il s'agit enfin d'ordonnancer les opérations de transfert et de calcul distribuées qui produisent le résultat final. Dans ce chapitre, nous définissons les différentes phases du traitement de requêtes au sein de l'entrepôt réparti sur la grille. Les mécanismes et procédés spécifiques à notre approche sur chacune de ces phases d'exécution sont présentés en détail. Ces mécanismes sont illustrés sur le cas d'utilisation que nous présentons ci-dessous. 1 Cas d'utilisation Le scénario d'utilisation que nous introduisons se base sur une grille expérimentale établie sur les trois sites des équipes participantes au projet GGM, à savoir Toulouse, Lille et Lyon. Les données utilisées sont celles introduites au chapitre 3. Nous supposons dans l'exemple que la grille expérimentale est composée d'un nœud sur chacun des trois sites de Lyon, Lille et Toulouse. L'ensemble des blocs de chunks matérialisés de l'entrepôt est réparti sur ces nœuds. Lors de la phase de déploiement, l'index TX de chaque nœud intègre les agrégats calculables à partir des blocs matérialisés localement. Nous supposons que le réseau déployé entre les différents nœuds fournit un débit constant pour tous les transferts de Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 89

108 5 Exécution et optimisation de requêtes données et une latence fixe pour la transmission des messages. Pour l'exemple, les différents nœuds ont tous la même capacité de calcul. Nous présentons par la suite la répartition des blocs de chunks matérialisés sur les nœuds de la grille. Par souci de lisibilité, les figures se limitent à la représentation des blocs matérialisés dans l'espace multidimensionnel de membres avec les sommets de l'index T associés. La structure des index X ainsi que les blocs calculables seront introduits au fur et à mesure de leur utilisation lors des exemples de ce chapitre. La figure 5.1 représente l'ensemble des blocs matérialisés sur le nœud LYON. L'index T, pour ces blocs matérialisés, comporte deux sommets v LY1 et v LY2 respectivement aux niveaux levels(v LY1 ) = {ville, date, path-0} (equ. {0,0,0}) et levels(v LY2 ) = {région, année, path-0} (equ. {1,2,0}). Par exemple, l'index X du sommet v LY1 comprend le bloc suivant : b LY1 = <{lieu.ville.toulon, temps.date , pathologie.path-0.grippe}, {lieu.ville.bourg-en-bresse, temps.date , pathologie.path-0.asthme}> (equ. <{1.0.1, 2.0.1, 3.0.8},{1.0.4, , }>) Nous représentons ce bloc multidimensionnel sur la figure 5.1 dans le plan lieutemps et dans le plan pathologie-temps. v LY1 TEMPS (date) TEMPS (date) b LY4 b LY b LY2 b LY3 b LY3 b LY b LY1 b LY Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme v LY2 TEMPS (année) TEMPS (année) b LY5 b LY PACA Rhône Alpes Piémont LIEU (région) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 5.1 : Identifiants de blocs matérialisés sur le nœud LYON Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 90

109 5 Exécution et optimisation de requêtes De même, la figure 5.2 représente les blocs matérialisés sur le nœud de Toulouse et la figure 5.3 ceux du nœud de Lille. On trouvera en annexe B (exemple 5.a) le détail des identifiants de blocs présents sur ces trois nœuds. v TO1 TEMPS (date) TEMPS (date) b TO b TO b TO b TO Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 5.2 : Identifiants de blocs matérialisés sur le nœud TOULOUSE v LI1 TEMPS (date) TEMPS (date) b LI2 b LI b LI1 b LI Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme v LI2 TEMPS (année) TEMPS (année) b LI3 b LI Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 5.3 : Identifiants de blocs matérialisés sur le nœud LILLE Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 91

110 5 Exécution et optimisation de requêtes Note : La notation employée dans ce chapitre pour les identifiants de blocs est basée sur une numérotation continue des blocs matérialisés de chaque nœud, par exemple b LY1, b LY2,,b LYn. Les blocs calculables à partir de ces blocs matérialisés sont notés b' et portent en indice les index de leurs nœuds sources accolés, par exemple b' LY12 désigne le bloc calculable issu des blocs source b LY1 et b LY2. Dans ce chapitre, nous utiliserons pour les exemples un ensemble de paramètres qui caractérisent les conditions d'exploitation de la grille. Ces paramètres décrivent un état momentané de la grille. L'ensemble des paramètres est répertorié dans le tableau 5.1. description du paramètre Nombre moyen de chunks matérialisés dans un bloc b par rapport au volume multidimensionnel de son identifiant, i.e. le taux de remplissage des blocs matérialisés Nombre de chunks par page disque du medium de stockage sur chaque nœud de la grille (voir chapitre 4, section 2.3) temps de lecture d'une page disque depuis le medium de stockage taille d'un chunk matérialisé d'un bloc b débit disponible sur le réseau reliant les nœuds capacité de calcul disponible sur les nœuds de la grille, en opérations par seconde Valeur nbchunks(b)/volume(b) = 0,75 chunksparpage = 20 chunks tempsaccespage = 4ms taillechunk(b) = 1,6 Ko lien LYON vers LILLE : 260 Ko/s lien LYON vers TOULOUSE : 200 Ko/s lien TOULOUSE vers LYON : 400 Ko/s lien TOULOUSE vers LILLE : 280 Ko/s lien LILLE vers LYON : 240 Ko/s lien LILLE vers TOULOUSE : 320 Ko/s nœud LYON : 500 ops/s nœud TOULOUSE : 900 ops/s nœud LILLE : 800 ops/s Tableau 5.1 : Paramètres d'exploitation de la grille à la base des exemples du chapitre A l'aide de cet entrepôt réparti, nous allons présenter la procédure d'exécution de requêtes. Dans notre déploiement, que nous présentons ci-après, les requêtes Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 92

111 5 Exécution et optimisation de requêtes peuvent être soumises à tous les nœuds de la grille et sont traitées en plusieurs phases. 2 Présentation générale des phases de traitement de requêtes Les différentes étapes de traitement d'une requête OLAP sont décrites succinctement ci-dessous. Nous les détaillerons dans les paragraphes suivants. (1) Réécriture de la requête client : Les requêtes soumises à l'entrepôt distribué portent sur l'entrepôt virtuel et sont exprimées sous forme de requêtes OLAP classiques. La requête OLAP est traduite sous forme d'identifiants de blocs de chunks afin de pouvoir localiser les données demandées via l'interrogation des index TX sur les différents nœuds de la grille. La réécriture d'une requête OLAP, initialement exprimée en SQL, vers la représentation en identifiants de blocs de chunks s'appuie d'une part sur le modèle multidimensionnel de l'entrepôt et d'autre part sur l'ordre que nous avons défini sur les instances de dimension. (2) Localisation des données utiles pour la requête : Il s'agit lors de cette phase de localisation d'identifier les données contribuant au résultat d'une requête et de les localiser parmi les données disponibles sur l'ensemble des nœuds de la grille sous forme de blocs de chunks matérialisés ou calculables. Le résultat de cette localisation est le recensement des différentes sources permettant d'obtenir les données utiles pour une requête ainsi que les informations nécessaires à l'évaluation de leurs coûts d'obtention. (3) Construction du plan d'exécution optimisé : Afin de pouvoir répartir et exécuter efficacement les tâches qui extraient et calculent les données demandées par une requête, le processus d'optimisation que nous mettons en place sélectionne les meilleures sources ainsi que le meilleur ordonnancement des transferts et calculs. La phase d'optimisation consiste à estimer le coût total pour l'obtention de chaque bloc de chunks source localisé. Le coût total prend en compte le coût de chargement des données (i.e. la lecture des chunks) et si nécessaire le coût de calcul d'agrégation et le coût de transfert des données depuis le nœud source. Pour déterminer le plan d'exécution optimisé en termes de temps d'exécution, les différents blocs de chunks source doivent être sélectionnés en fonction de ce coût estimé. Finalement, pour la requête traitée, nous construisons le plan d'exécution distribuée optimisé à partir des blocs sources choisis pour fournir les données demandées. Le processus de création du plan d'exécution doit prendre en compte les possibilités de calcul à la volée d'agrégats et favorise l'implication d'un maximum de sources en parallèle. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 93

112 5 Exécution et optimisation de requêtes (4) Exécution parallèle et distribuée de la requête : La phase d'exécution proprement dite regroupe l'ordonnancement, le lancement et la surveillance des tâches du plan d'exécution distribuée pour une requête. Ce plan d'exécution se décompose en tâches de calcul et de transfert attribués aux différents nœuds sources de données. Ces tâches sont ordonnancées en fonction de leurs besoins en capacité de calcul et en bande passante pour minimiser l'accès concurrent aux ressources et ainsi permettre un maximum d'exécutions en parallèle. Il s'agit en particulier de répartir au mieux la charge sur les ressources du nœud destination sur lequel le résultat final est matérialisé (i.e. celui sur lequel a été émise la requête). Par exemple, si un bloc de chunks détaillés doit être transféré du nœud TOULOUSE vers le nœud LYON où il sert de source pour un calcul de chunks agrégés, alors le transfert de ce bloc est prioritaire par rapport au transfert de blocs agrégés matérialisés qui n'ont plus besoin de subir de calculs avant de pouvoir être ajoutés au résultat de la requête. Le lancement des tâches dans l'ordre préconisé est associé à une surveillance de leur exécution afin de minimiser les délais imprévus, tels la déconnexion d'un nœud ou un retard exceptionnel suite à une charge plus haute que prévue sur un nœud. Finalement, le résultat de la requête est matérialisé sur le nœud destination au fur et à mesure de l'aboutissement de chaque tâche. Nous détaillons par la suite les quatre grandes phases identifiées pour le traitement des requêtes. 3 Réécriture de la requête client Nous introduisons ici la méthode de réécriture d'une requête posée via l'interface client de l'entrepôt réparti. Cette requête s'appuie sur le schéma de l'entrepôt virtuel présenté à l'utilisateur et doit donc être réécrite sous forme d'identifiants de blocs pour pouvoir être traitée par l'entrepôt réparti. La réécriture de la requête client consiste à extraire de la requête OLAP les éléments capables d'identifier les données recherchées et à construire l'identifiant de bloc correspondant. Une requête OLAP classique s'exprime sous forme d'une requête SQL comportant les éléments suivants : - La clause «SELECT» désigne les attributs correspondants aux niveaux hiérarchiques sélectionnés sur les différentes dimensions ainsi que les agrégats demandés. - La clause «FROM» contient la source des données demandées, qui est pour une requête OLAP l'hypercube lui-même, i.e. la jointure entre les tables de dimension et la table de faits. - La clause «WHERE» comporte les prédicats de sélection des membres de dimension pour chaque dimension. - La clause «GROUP BY» précise les niveaux d'agrégation demandés sur les dimensions. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 94

113 5 Exécution et optimisation de requêtes Nous allons exploiter ces éléments de la requête pour identifier les blocs de chunks qui représentent les données demandées. Les clauses «SELECT» et «GROUP BY» donnent l'information sur les niveaux d'agrégation demandés par la requête. Les parties contiguës dans l'espace multidimensionnel de membres sont déterminées à l'aide des prédicats de la clause «WHERE». Prenons par exemple la requête OLAP suivante : SELECT lieu.ville, temps.mois, pathologie.path-0, list(id_patient), sum(décès) FROM faits, lieu, temps, pathologie WHERE (ville BETWEEN 'Toulon' AND 'Lyon') AND (mois BETWEEN ' ' AND ' ') AND (path-0 BETWEEN 'épilepsie' AND 'grippe') GROUP BY lieu.ville, temps.mois, pathologie.path-0 Cette requête recherche des données des niveaux {ville, mois, path-0} (equ. {0,1,0}) et définit pour chaque dimension des membres limite inférieure et limite supérieure qui délimitent le bloc de chunks b r, représentation multidimensionnelle du résultat recherché. b r = <{lieu.ville.toulon, temps.mois , pathologie.path-0.épilepsie}, {lieu.ville.lyon, temps.mois , pathologie.path-0.grippe}> (equ. <{1.0.1, 2.1.1, 3.0.6},{1.0.7, , 3.0.8}>) L'origine des données telle qu'elle est décrite dans la clause «FROM» n'est pas prise en compte car elle fait référence au schéma virtuel de l'entrepôt tel qu'il est présenté à l'utilisateur. Au sein de l'entrepôt réparti, les chunks de données sont extraits des fragments de la table de faits ou des tables d'agrégats à l'aide des instances locales de dimensions sur chaque nœud. Comme nous allons le montrer en section 6, ces sous-requêtes transparentes pour l'utilisateur ont la même structure que des requêtes OLAP. 4 Localisation des données utiles pour la requête Une requête OLAP est soumise par un utilisateur sur un nœud de la grille. Cette requête OLAP correspond à un bloc de chunks recherchés. Ces chunks recherchés existent, éventuellement en plusieurs exemplaires, sur la grille sous leur forme matérialisée et/ou calculable. Ils sont contenus dans des blocs indexés sur un ou plusieurs nœuds. Le processus de localisation de données utiles pour la requête consiste alors à rechercher, parmi tous les nœuds de la grille, l'ensemble des blocs qui contribuent à la requête. 4.1 Principe général L'utilisateur est connecté à un nœud DST sur lequel il émet sa requête OLAP, réécrite sous forme d'un bloc de chunk b r. L'index TX de ce nœud est interrogé en premier afin de déterminer si la requête peut être satisfaite à partir des blocs Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 95

114 5 Exécution et optimisation de requêtes de chunks disponibles localement. Ces blocs, s'ils sont matérialisés, sont retenus comme éléments de réponse à la requête dans un ensemble noté R. Si R suffit pour répondre à la requête, alors le processus de localisation est terminé. Dans le cas où les données matérialisées localement ne permettent pas de répondre à l'intégralité de la requête, alors les données manquantes M doivent être recherchées dans les blocs calculables localement et également dans les blocs matérialisés et/ou calculables sur les autres nœuds de la grille. En effet, pour des raisons de performance, il peut être plus efficace d'aller chercher des données matérialisées, voire même de les calculer et de les transférer, depuis un nœud distant plutôt que de les calculer sur le nœud d'émission de la requête. Ces possibilités sont recueillies dans un ensemble de blocs candidats noté C. 4.2 Algorithme de localisation des données Nous explicitons ci-dessous l'algorithme de localisation sur le nœud local DST et l'algorithme de localisation sur les nœuds distants SRC. Algorithme 1 : localisation sur le nœud DST Entrées : - le bloc recherché b r Sorties : - l'ensemble R des blocs matérialisés localement - l'ensemble C 0 des blocs candidats - l'ensemble M des blocs recherchés 1 début 2 M = {b r } // au départ M représente la requête elle-même 3 construire les ensembles B 1 et B 2 de blocs b i indexés dans TX tels que bi b r // B 1 contient les blocs matérialisés et B 2 contient les blocs calculables 4 pour chaque bloc b i de B 1 faire 5 R = R bi 6 pour chaque b Qj de M faire 7 calculer la contribution de b i à b Qj 8 mettre b Qj dans l'ensemble des requêtes à supprimer M s 9 calculer l'ensemble de requêtes M a = parties manquantes de b Qj après soustraction de la contribution de b i 10 finpour 11 mettre à jour M en enlevant la contribution de b i, i.e. en remplaçant dans M les éléments de M s par les éléments de M a Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 96

115 5 Exécution et optimisation de requêtes 12 finpour 13 pour chaque bloc b i de B 2 faire 14 si bi b Qj alors 15 pour chaque b Qj de M faire 16 C0 C 0 bi 17 mettre à jour le plan de calcul de b i en limitant à la partie utile bi b Qj 18 finpour 19 finsi 20 finpour 21 fin Algorithme 2 : localisation des données manquantes sur un nœud SRC Entrées : - l'ensemble des blocs recherchés M Sorties : - l'ensemble C SRC des blocs candidats 1 début 2 pour chaque b Qj de M faire 3 construire les ensembles B 1 et B 2 de blocs b i indexés dans TX tels que bi b Qj // B 1 contient les blocs matérialisés et B 2 contient les blocs calculables 4 pour chaque bloc b i de B 1 faire 5 CSRC C SRC bi 6 créer un plan de calcul pour l'obtention de b i avec la partie utile bi b Qj 7 finpour 8 pour chaque bloc b i de B 2 faire 9 CSRC C SRC bi 10 mettre à jour le plan de calcul de b i en limitant à la partie utile b i b Qj 11 finpour 12 finpour 13 fin Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 97

116 5 Exécution et optimisation de requêtes L'algorithme 1 commence par lancer la requête sur l'index TX du nœud DST. Celui-ci fournit l'ensemble des blocs indexés qui contribuent au résultat de la requête. Les éléments du résultat sont divisés en un ensemble de blocs matérialisés B 1 et un ensemble de blocs calculables localement B 2. Les blocs matérialisés sont considérés comme éléments certains pour le calcul du résultat. Ces blocs matérialisés sont donc ajoutés à l'ensemble R des blocs sources à partir de la ligne 6. Au fur et à mesure que ces blocs sont sélectionnés, leur contribution au résultat est enlevée de l'ensemble M décrivant les données manquantes. Ce mécanisme est décrit en détail par la section 4.3. Une fois que M est mis à jour et représente les données demandées non matérialisées sur DST, la contribution des blocs calculables localement est analysée (ligne 13 ). Pour chaque bloc calculable localement qui contribue à une partie de M, on construit un plan de calcul adapté pour fournir la partie utile identifiée. Cette méthode est illustrée en section Ces blocs sont ajoutés à l'ensemble des candidats C O pour fournir les données manquantes afin de les mettre en concurrence avec les blocs matérialisés ou calculables qui seront trouvés par la suite sur les autre nœuds SRC de la grille. L'algorithme 2 effectue la recherche des données manquantes sur un nœud distant SRC. Ces données manquantes sont issues de l'algorithme 1 : il s'agit de l'ensemble M, ensemble de blocs recherchés. L'index TX est interrogé pour fournir l'ensemble B 1 des blocs matérialisés et l'ensemble B 2 des blocs calculables sur SRC correspondants aux données manquantes recherchées. Les blocs matérialisés de B 1 sont ajoutés à C (ligne 6 ) et nous créons un plan de calcul pour extraire la partie utile de chaque bloc. Les blocs calculables sont également ajoutés à C en adaptant leur plan de calcul en fonction de la partie utile qu'ils fournissent pour la construction du résultat (ligne 10 ). A la fin du processus, R représente les blocs matérialisés sur le nœud DST contribuant à la requête. L'union C de C 0 et des ensembles C SRC pour chaque nœud, représente les blocs candidats pour fournir les données manquantes. 4.3 Calcul de la contribution des blocs et mise à jour de la requête Nous introduisons ici la méthode de construction progressive de l'ensemble M des identifiants de blocs décrivant les données manquantes sur un nœud exécutant une requête. Lorsqu'une requête b r est soumise à l'index TX, celui-ci fournit l'ensemble des blocs matérialisés localement qui contribuent à b r. Chacun de ces blocs matérialisés b i est inséré dans l'ensemble R en calculant sa partie utile pour la construction du résultat de b r. Au fur et à mesure que les parties utiles des blocs sont déterminées, notre méthode calcule les éléments de l'ensemble M des données encore manquantes pour répondre à la requête. Pour constituer l'ensemble M, notre méthode créé à chaque itération un ensemble M s de blocs Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 98

117 5 Exécution et optimisation de requêtes à supprimer de M et un ensemble M a de blocs à ajouter à M. Les blocs à supprimer de M s sont ceux qui ont une intersection non nulle avec la requête et dont la contribution doit être supprimée de M. Leurs identifiants sont remplacés dans M par les blocs de M a, l'ensemble de blocs représentant la différence géométrique entre les données manquantes et le bloc matérialisé localement. Nous allons illustrer le fonctionnement de l'algorithme à l'aide d'un exemple comportant une requête b r pour laquelle la recherche sur l'index TX a identifié deux blocs matérialisés b 1 et b 2 qui ont une intersection non nulle. La partie de b r considérée comme manquante est obtenu grâce à une opération de différence géométrique notée «\ b» qui permet d'enlever progressivement la contribution des blocs matérialisés. L'opérateur de différence géométrique «\ b» prend en paramètre un bloc représentant une requête et calcule l'intersection avec un second bloc donné. La différence est représentée par un ensemble de blocs couvrant les chunks du premier bloc non couverts par le second. Pour construire cet ensemble, nous commençons par rechercher les intervalles de membres de la requête non couverts par un bloc matérialisé dans toutes les dimensions et construisons les volumes manquants à partir de ceux-ci. La construction des volumes manquants utilise les intervalles non couverts en ordre décroissant pour maximiser le volume des blocs recherchés. Le détail de ces opérations est décrit par l'algorithme 5.1 en annexe A. La figure 5.4 illustre la situation de départ, c'est-à-dire les blocs b 1 et b 2 qui contribuent chacun une partie des chunks demandés. M est initialisé avec un unique élément b r, tous les chunks de b r étant considérés comme manquants avant la prise en compte des contributions de b 1 et b 2 dans l'ensemble R. blocs de chunks matérialisés b 1 et b 2 ayant une intersection non nulle avec la requête b r bloc matérialisé requête d'origine b r b 2 b 1 Figure 5.4 : Intersections dans l'espace de données entre une requête et deux blocs de chunks matérialisés sur le nœud destination Le résultat de la première itération de l'algorithme est présenté en figure 5.5. La contribution de b 1 est prise en compte par l'ajout de b 1 à R. L'opération de différence géométrique b r \ b b 1 engendre la création de trois blocs b r11, b r12 et b r13 pour décrire les parties manquantes de la requête après la suppression de la Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 99

118 5 Exécution et optimisation de requêtes contribution de b 1. Ces nouveaux blocs sont ajoutés à l'ensemble M a alors que b r est ajouté à M s. division de la requête d'origine pour supprimer la contribution du bloc de chunks matérialisés b 1 b r11 bloc matérialisé requête sur chunks manquants b r13 b 2 b r12 b 1 Figure 5.5 : Calcul de la contribution du premier bloc à la requête et mise à jour de l'ensemble des données manquantes A la fin de la première itération, les éléments de M s, à savoir b r, sont supprimés dans M et remplacés par les éléments de M a, b r11, b r12 et b r13. La deuxième itération de l'algorithme est illustrée par la figure 5.6. Pour chaque élément de M, la contribution de b 2 est soustraite et le résultat ajouté à M a. Comme b 2 n'a qu'une intersection avec b r11 et b r12, ces deux blocs sont marqués pour être supprimés dans M s, tandis que les ensembles b r11 \ b b 2 = {b r21, b r22 } et b r12 \ b b 2 = {b r23 } sont ajoutés à M a. division des requêtes pour supprimer la contribution du bloc de chunks matérialisés b 2 b r21 b r22 bloc matérialisé requête sur chunks manquants b r13 b 2 b r23 b 1 Figure 5.6 : Calcul de la contribution du deuxième bloc à la requête et finalisation de l'ensemble des données manquantes Suite à cette dernière itération nous obtenons un ensemble M contenant les quatre blocs recouvrant les chunks de b r qui ne sont ni fournis par b 1, ni par b 2. La trace d'exécution complète de cet exemple est détaillée par le tableau 5.2. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 100

119 5 Exécution et optimisation de requêtes Itération R M M a M s 1 b r 1 b 1 b r b r 1 b 1 b r b r11, b r12, b r13 b r 1 b 1 b r11, b r12, b r13 2 b 1, b 2 b r11, b r12, b r13 b r11 2 b 1, b 2 b r11, b r12, b r13 b r21, b r22 b r11 2 b 1, b 2 b r11, b r12, b r13 b r21, b r22 b r11, b r12 2 b 1, b 2 b r11, b r12, b r13 b r21, b r22, b r23 b r11, b r12 2 b 1, b 2 b r21, b r22, b r13 Tableau 5.2 : Trace d'exécution de l'algorithme pour la construction de M L'exemple suivant illustre la procédure décrite dans le cadre du traitement d'une requête sur le nœud LILLE. Exemple 5.1 : Construction de requêtes portant sur les chunks recherchés Soit une requête soumise au nœud LILLE, réécrite sous forme d'identifiant de bloc b' r. Elle porte sur les chunks des niveaux {ville, année, path-0} (equ. {0,2,0}) où sont indexés le bloc matérialisé b LI3 et Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 101

120 5 Exécution et optimisation de requêtes le bloc calculable b' LI12, issu de la fusion des blocs b LI1 et b LI2 dans la dimension «temps». b' r = <{lieu.ville.marseille, temps.année.1930, pathologie.path-0.pneumonie}, {lieu.ville.lyon, temps.année.1939, pathologie.path-0.grippe}> (equ. <{1.0.3, 2.2.6, 3.0.7},{1.0.7, , 3.0.8}>) La figure 5.7 montre l'intersection de b' r avec le bloc matérialisé b LI3 et fait apparaître les parties identifiées par notre méthode comme manquantes (zones blanches de la figure). Le regroupement des chunks manquants aboutit à une répartition en deux blocs b' rm1 et b' rm2 représentés dans la figure 5.7. b' rm1 est créé en premier pour occuper un volume maximum dans la dimension «temps», tout en gardant les mêmes coordonnées que b' r dans les autres dimensions. b' rm2 occupe ensuite le restant de l'espace contenu dans b' r non rempli par b LI3. contour du bloc requête b' r TEMPS (année) TEMPS (année) b LI3 b' rm2 b LI b' rm b' LI b' LI Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 5.7 : Découpage d'une requête portant sur les blocs indexés du nœud LILLE Nous obtenons ainsi deux requêtes exprimées sous forme de blocs de chunks à rechercher sur les autres nœuds de la grille. b' rm1 = <{lieu.ville.marseille, temps.année.1930, pathologie.path-0.pneumonie}, {lieu.ville.lyon, temps.année.1936, pathologie.path-0.grippe}> (equ. <{1.0.3, 2.2.6, 3.0.7},{1.0.7, , 3.0.8}>) Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 102

121 5 Exécution et optimisation de requêtes b' rm2 = <{lieu.ville.grenoble, temps.année.1937, pathologie.path-0.pneumonie}, {lieu.ville.lyon, temps.année.1939, pathologie.path-0.grippe}> (equ. <{1.0.5, , 3.0.7},{1.0.7, , 3.0.8}>) Grâce à cette méthode les parties non matérialisés localement du résultat de la requête sont identifiées et peuvent être recherchées parmi les blocs calculables localement ou disponibles sur d'autres nœuds de la grille. Pour ces blocs non matérialisés localement, il est nécessaire de créer ou d'adapter les plans de calcul utiles pour leur obtention. 4.4 Mise à jour des plans de calcul L'ensemble des chunks manquants sont recherchés parmi les blocs calculables localement et les blocs matérialisés et/ou calculables sur les autres nœuds de la grille. Afin de pouvoir évaluer les différentes possibilités d'obtenir ces chunks, il est nécessaire de déterminer la partie utile de chacun de ces blocs et d'ajouter son coût d'obtention estimé. La partie utile ainsi que les coûts associés à chaque bloc source sont répertoriés par des plans de calcul réunis dans un ensemble de blocs candidats. L'ensemble de blocs candidats C SRC associée à l'ensemble de chunks manquants M sur le nœud DST est constitué des identifiants des blocs sources qui fournissent les chunks utiles à la requête et pour chaque bloc source un plan de calcul qui décrit les opérations nécessaires pour obtenir la partie utile à partir du bloc source. Les plans de calcul comprennent l'estimation de coûts pour l'obtention de la partie utile à partir du bloc source. Pour un bloc source matérialisé sur un nœud distant il est nécessaire de créer ce plan de calcul. Pour les blocs sources calculables, le plan de calcul existant est mis à jour afin de fournir uniquement la partie utile contribuant à la requête Création de plan de calcul pour blocs matérialisés Soit M = {b rm1,, b rmk } l'ensemble des blocs recherchés pour répondre à la requête b r. Soit b m un bloc de chunks matérialisé sur un nœud distant pour lequel il existe au moins un b rmi tels que b b, i 1,, k. Le bloc b m offre donc une possibilité d'obtenir une partie du résultat de b r par extraction et transfert de chunks matérialisés. Pour prendre en compte l'ensemble des chunks que peut fournir b m pour la construction du résultat nous créons un plan de calcul P m associé à b m, composé d'un ou plusieurs éléments de la forme suivante : P m = {< b pm1, b m, coutextraction(b pm1, b m )>,, < b pmu, b m, coutextraction(b pmu, b m )>}, 1 u k rmi m Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 103

122 5 Exécution et optimisation de requêtes La partie utile b pmj de b m est obtenu par l'intersection du bloc de chunks manquants b rmi et b m : b b, i 1,, k, j 1,, l pmj b rmi m Ainsi, un plan de calcul est créé pour chaque bloc b m matérialisé sur un nœud SRC ayant une intersection non nulle avec un ou plusieurs des blocs de M. Comme chaque partie utile b pmj est disjointe des autres parties utiles, les coûts d'extraction sont calculés de la même manière que si les différentes b pmj provenaient de sources différentes. L'élément ajouté à C SRC est l'identifiant de bloc b m et son plan de calcul associé P m. Exemple 5.2 : Création d'un plan de calcul pour blocs candidats matérialisés sur nœuds distants Pour cet exemple nous utilisons l'ensemble M = {b rm1, b rm2 } comportant deux blocs requêtes aux niveaux {région, année, path-0} (equ. {1,2,0}). Comme le montre la figure 5.8, ce deux requêtes sont soumises au nœud distant LYON. b rm1 = <{lieu.région.rhône Alpes, temps.année.1934, pathologie.path-0.pneumonie}, {lieu.région.rhône Alpes, temps.année.1935, pathologie.path-0.asthme}> (equ. <{1.1.2, , 3.0.7},{1.1.2, , }>) b rm2 = <{lieu.région.paca, temps.année.1925, pathologie.path-0.épilepsie}, {lieu.région.rhône Alpes, temps.année.1933, pathologie.path-0.bronchite}> (equ. <{1.1.1, 2.2.1, 3.0.6},{1.1.2, 2.2.9, 3.0.9}>) Le bloc de chunks matérialisé b LY5 a une intersection non nulle avec les deux requêtes posées. Ce bloc est ainsi considéré comme bloc candidat et un plan de calcul P LY5 est créé avec les intersections comme parties utiles : P LY5 = {< b rm1 b LY 5, b LY5, coutextraction( b rm1 b LY 5, b LY5 )>, < b rm2 b LY 5, b LY5, coutextraction( b rm2 b LY 5, b LY5 )>} Le bloc b LY5 associé à son plan de calcul P LY5 est donc ajouté à la l'ensemble C des candidats pour fournir les chunks recherchés par M. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 104

123 5 Exécution et optimisation de requêtes TEMPS (année) TEMPS (année) b LY5 b rm b LY b' LY12 b rm2 b' LY PACA Rhône Alpes Piémont LIEU (région) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 5.8 : Eléments d'un plan de calcul créé pour un bloc candidat matérialisé sur le nœud LYON Mise à jour du plan de calcul des blocs calculables Soit M = {b rm1,, b rmk } l'ensemble des blocs recherchés pour répondre à la requête b r. Soit b c un bloc de chunks calculable localement qui fournit une partie des chunks couverts par au moins un b rmi, i.e. b b, i 1,, k. Soit P c le plan de calcul associé à b c, tel que : P c = {<b p1, S 1, coutextraction(b p1, S 1 )>,, <b pn, S n, coutextraction(b pn, S n )>} Il existe alors un plan de calcul P' c extrait du plan de calcul P c qui fournit les chunks du bloc calculable contenus dans les intersections b b, i = 1,,k. P' c est défini par {<b' p1, S 1, coutextraction(b' p1, S 1 )>,, <b' pn, S n, coutextraction(b' pn, S n )>}, n > 0, où : - b' pj est l'identifiant de la partie utile de S j qui contribue au calcul d'une intersection b b, i 1,, k, rmi c - S j est l'identifiant du bloc source utilisé pour l'obtention de b' pj. - coutextraction(b' pj, S j ) représente le coût estimé pour extraire la partie utile b' pj à partir de S j. rmi c rmi c La construction du plan P' c permet d'adapter l'estimation des coûts pour l'extraction des données source à la seule partie utile. Le nouveau coût tiendra compte de la réduction du volume des données. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 105

124 5 Exécution et optimisation de requêtes Exemple 5.3 : Mise à jour du plan de calcul pour les blocs candidats calculables L'exemple qui suit poursuit l'exemple 5.2 avec l'ensemble M = {b rm1, b rm2 } soumis au nœud distant LYON. Ces requêtes sont recherchés au sein de l'index TX, qui fournit pour la requête b rm2 le bloc calculable b' LY12 en résultat. Le plan de calcul de ce bloc (cf. chapitre 4) utilise les blocs b p1 et b p2. v LY1 TEMPS (date) TEMPS (date) b LY b LY b' p b LY1 b' p1 b LY Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme v LY2 TEMPS (année) TEMPS (année) b LY5 b rm b LY b' LY12 b rm2 b' LY PACA Rhône Alpes Piémont LIEU (région) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 5.9 : Extraction partielle d'un plan de calcul d'un bloc calculable en fonction d'une requête sur le nœud LYON Comme le montre la figure 5.9, nous calculons l'intersection de ces deux blocs avec la requête pour obtenir les deux parties utiles b' p1 et b' p2 : b' p1 = bp 1 b rm2 = <{lieu.ville.toulon, temps.date , pathologie.path-0.grippe}, Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 106

125 5 Exécution et optimisation de requêtes {lieu.ville.marseille, temps.date , pathologie.path-0.bronchite}> (equ. <{1.0.1, 2.0.1, 3.0.8},{1.0.3, , 3.0.9}>) b' p2 = bp2 b = rm2 <{lieu.ville.toulon, temps.date , pathologie.path-0.grippe}, {lieu.ville.marseille, temps.date , pathologie.path-0.bronchite}> (equ. <{1.0.1, , 3.0.8},{1.0.3, , 3.0.9}>) Dans le plan de calcul mis à jour, b' p1 et b' p2 remplacent les blocs b p1 et b p2 dans les tuples du plan initial. Nous construisons ainsi un nouveau plan de calcul P' LY12 qui nous permettra d'extraire les parties utiles du bloc calculable : P' LY12 = {<b' p1, b LY1, coutextraction(b' p1,b LY1 )>, <b' p2, b LY2, coutextraction (b' p2,b LY2 )>} Les valeurs pour les estimations de coûts d'extraction sont également mises à jour en fonction des parties utiles identifiées. Le bloc b' LY12 est donc ajouté à l'ensemble C SRC, associé à son plan de calcul mis à jour P' LY12. Les ensembles C SRC obtenus sur les différents nœuds distants sont transmis au nœud DST où ils sont intégrés avec l'ensemble des blocs calculables localement C 0 dans l'ensemble de blocs candidats global C. On trouvera en annexe B (exemple 5.b) un exemple de la constitution des ensembles des blocs candidats C SRC sur plusieurs nœuds distants pour une requête donnée. A la fin de la phase de localisation, l'ensemble R des blocs matérialisés localement et l'ensemble C des blocs candidats distants ou locaux est constituée sur le nœud destination DST. A l'aide de cette information DST va pouvoir sélectionner les possibilités les plus avantageuses pour obtenir les chunks non matérialisés localement. 5 Plan d'exécution et optimisation de l'exécution Cette phase a pour objectif de construire un plan d'exécution distribué pour la requête en choisissant parmi les solutions possibles celle qui minimise le temps d'exécution. Le critère utilisé pour effectuer le choix des blocs candidats est l'estimation d'un coût total qui inclut l'extraction depuis les blocs sources matérialisés, le calcul d'agrégation pour les blocs calculables et le transfert par le réseau vers le nœud destination pour les blocs distants. Les coûts d'extraction depuis les blocs source matérialisés sont statiques, comme décrit au chapitre 4. Les autres coûts sont fonction de caractéristiques dynamiques de la grille telles que la bande passante disponible, la latence, la capacité de calcul de chaque nœud. Pour chaque bloc candidat identifié lors de la phase de localisation les coûts dynamiques doivent être calculés à la volée en fonction des nœuds source et destination. Ces coûts vont en particulier permettre de choisir entre le nœud Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 107

126 5 Exécution et optimisation de requêtes source et nœud destination le meilleur site pour effectuer le calcul d'agrégation. La construction du plan d'exécution final emploie un algorithme de type glouton pour sélectionner les sources de chunks en minimisant le temps d'exécution estimé. 5.1 Calcul des estimations de coûts Le coût total d'obtention d'un bloc sur le nœud destination est fonction du coût d'extraction coutextraction(b p,b s ) de la partie utile b p du bloc source b s disponibles sur le nœud et de coûts dynamiques. Ces coûts dynamiques concernent les coûts de transfert des chunks matérialisés distants, la combinaison entre les coûts de calcul pour les chunks calculables et le transfert soit des chunks à agréger, soit des chunks résultats du calcul d'agrégation. Ciaprès nous détaillons le calcul des coûts pour les blocs matérialisés, puis pour les blocs calculables Estimation des coûts pour les blocs matérialisés Le coût d'obtention couttotal(b p, SRC, DST) d'une partie b p du bloc matérialisé b m sur le nœud SRC, est la somme de son coût d'extraction coutextraction(b p,b m ) et de son coût de transfert vers le nœud DST. Pour estimer le coût de transfert d'un bloc de chunks b p extrait d'un bloc matérialisé b m, nous supposons que l'infrastructure de surveillance de la grille nous permet de connaître la bande passante bandepass(src,dst) disponible entre le nœud source et le nœud destination. La taille totale de données à transférer est calculée à partir du nombre estimé de chunks nbchunks(b p ) à transférer et la taille taillechunk(b p ) d'un chunk du bloc source. Le temps de transfert total transf(b p,src,dst) est calculé selon le «Raw BandWidth model» (RBW) utilisé par (Faerman et al., 1999) pour les transferts de données sur grille : transf b,src, DST = p nbchunks b p taillechunk b bandepass SRC,DST p si SRC DST 0 sinon Cette fonction renvoie le temps estimé à l'aide des données de surveillance les plus récentes disponibles sur la grille. Le nœud destination peut mettre à jour ces données au moment de l'interrogation des nœuds sources pendant la phase de localisation. Le coût total pour la partie utile b p est alors : couttotal bp, SRC, DST coutextraction bp, bm transf b p,src, DST Le coût total pour l'obtention de la partie utile d'un bloc candidat matérialisé b m est associé à ce bloc dans l'ensemble des candidats C. Dans le cas où la partie Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 108

127 5 Exécution et optimisation de requêtes utile est représentée par plusieurs blocs b p1,,b pn, le coût total est calculé comme la somme des coûts totaux de chaque b pi, i = 1,,n : couttotal b, SRC couttotal b, SRC m i 1.. n pi Exemple 5.4 : Estimation des coûts pour bloc de chunks matérialisé Nous prenons comme exemple un ensemble de requêtes sur chunks manquants M' = {b* rm }, dont l'unique élément est recherché sur le nœud source LILLE pour une requête dont le résultat doit être matérialisé sur le nœud destination TOULOUSE. L'intersection avec les blocs indexés sur le nœud LILLE est illustré en figure b* rm = <{lieu.ville.marseille, temps.année.1936, pathologie.path-0.pneumonie}, {lieu.ville.lyon, temps.année.1939, pathologie.path-0.grippe}> (equ. <{1.0.3, , 3.0.7},{1.0.7, , 3.0.8}>) TEMPS (année) b LI3 TEMPS (année) 1929 b' LI b' LI b* rm b LI3 Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 5.10 : Bloc candidat matérialisé sur le nœud LILLE pour une requête soumise au nœud TOULOUSE Le bloc candidat matérialisé b LI3, dont la partie utile correspond au bloc b cli3, est ajouté à la liste des candidats C LILLE et renvoyé au nœud TOULOUSE qui calcule l'estimation de coûts de transfert pour la partie utile. b cli3 = <{lieu.ville.marseille, temps.année.1937, pathologie.path-0.pneumonie}, {lieu.ville.st Etienne, temps.année.1939, pathologie.path-0.grippe}> Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 109

128 5 Exécution et optimisation de requêtes (equ. <{1.0.3, , 3.0.7},{1.0.5, , 3.0.8}>) Le lien réseau du nœud LILLE vers le nœud TOULOUSE dispose d'une bande passante de 320Ko/s, qui sont entièrement utilisés pour transférer les 18 chunks de b cli3. nbchunks b cli 3 cli 3 transf b cli 3,LYON, TOULOUSE = bandepass LYON, TOULOUSE 18*1, 6Ko 320 Ko / s 0,09s taillechunk b En somme nous obtenons un coût total suivant pour la partie utile du bloc candidat matérialisé b LI3 : couttotal b LI 3, LYON, TOULOUSE coutextraction b, b transf b,lyon, TOULOUSE 0,128s 0, 09s 0,137s cli 3 LI 3 cli Estimation des coûts pour des blocs calculables Le coût d'obtention couttotal(b c, SRC, DST) d'un bloc calculable b c disponible sur le nœud SRC et le transfert des données vers le nœud DST dépend du nœud où est effectué le calcul. Nous distinguons trois cas de figure. - Cas 1 : le bloc calculable est déjà sur le nœud destination. - Cas 2 : le bloc calculable est sur un nœud source distant et le calcul de l'agrégat est effectué sur ce nœud source. - Cas 3 : le bloc calculable est sur un nœud source distant et le calcul de l'agrégat est effectué sur le nœud destination. Dans le cas 1, pour un bloc calculable qui est déjà sur le nœud destination, le coût d'obtention couttotal(b c,dst,dst) est la somme du coût d'extraction des parties utiles de b c à partir du plan de calcul P c et du coût de calcul des agrégats sur le nœud destination à partir de b c. Le coût de calcul coutcalcul(b c,dst) dépend du temps de calcul d'une opération élémentaire calcelem(dst) sur le nœud et du nombre de chunks matérialisés à traiter pour fournir l'agrégation. Soit le plan de calcul P c = {<b p1, S 1, coutextraction(b p1, S 1 )>,, <b pm, S m, coutextraction(b pm, S m )>}, alors le coût de calcul est estimé de la façon suivante : coutcalcul b, DST nbchunks b * calcelem DST c i 1.. m pi Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 110

129 5 Exécution et optimisation de requêtes Le coût total est alors fourni par : couttotal bc, DST, DST coutextraction bc, Pc coutcalcul b c,dst Dans le cas 2, le bloc calculable est sur un nœud source distant SRC et le calcul d'agrégat est effectué sur ce même nœud source. Le coût de calcul de l'agrégat est donc fonction des caractéristiques du nœud source. Soit le plan de calcul P c = {<b p1, S 1, coutextraction(b p1, S 1 )>,, <b pm, S m, coutextraction(b pm, S m )>}, le coût de calcul est donc estimé de la façon suivante : coutcalcul b, SRC nbchunks b * calcelem SRC c i 1.. m pi Le coût de transfert de l'agrégat depuis la source SRC jusqu'à la destination DST est transf(b c,src,dst). Le coût total est alors fourni par : couttotal b, SRC, DST i 1.. m c coutextraction b, S coutcalcul b,src transf b, SRC, DST pi i c c Dans le cas 3, le bloc calculable b c est sur un nœud source distant SRC et le calcul d'agrégat est effectué sur le nœud destination DST. Le coût total sera donc la somme : - du coût d'extraction sur la source SRC des parties utiles b pi des blocs sources éléments du plan de calcul de b c, - du transfert des b pi depuis SRC à DST, - du calcul de l'agrégat sur le nœud destination DST. Soit le plan de calcul P c = {<b p1, S 1, coutextraction(b p1, S 1 )>,, <b pm, S m, coutextraction(b pm, S m )>}, alors couttotal b, SRC, DST c i 1.. m coutextraction b, S transf b, SRC, DST coutcalcul b, DST pi i pi c L'avantage du calcul sur le nœud source consiste à réduire le volume de données à transférer par la suite, car s'agissant d'un agrégat, le résultat du calcul est bien moins volumineux. En revanche, le calcul sur le nœud destination peut s'avérer plus rapide si le nœud destination dispose d'une capacité de calcul disponible plus importante et que la bande passante du lien entre les nœuds ne pénalise pas le transfert des blocs source. Lors de la phase d'exécution et d'optimisation de la requête, la solution la moins coûteuse sera retenue. Le coût total incluant les coûts dynamiques est ajouté à chaque élément b a de l'ensemble de blocs candidats C établi lors de la phase de localisation. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 111

130 5 Exécution et optimisation de requêtes En utilisant les estimations de coûts calculées pour chacun des blocs candidats, nous introduisons maintenant une méthode pour la construction d'un plan d'exécution de requêtes distribué optimisé. 5.2 Construction d'un plan d'exécution de requêtes optimisé Nous disposons maintenant de l'ensemble C de blocs candidats pour contribuer au résultat d'une requête, associés à leurs plans d'exécution et à une estimation de leurs coûts d'obtention. Le mécanisme de construction du plan d'exécution optimisé est basé sur un mécanisme de sélection de réplicas spécifique aux grilles de calcul, introduit par (Weng et al., 2005). Nous reprenons en particulier la mesure de bénéfice de cette méthode pour sélectionner les candidats à intégrer au plan d'exécution Mesure de la contribution au résultat pour les blocs candidats La contribution d'un bloc candidat ba C à l'ensemble de chunks manquants M est facilement mesurable en utilisant le nombre de chunks nbchunks(b a ) du bloc candidat. Si l'identifiant de bloc b a représente toujours une partie d'un ou plusieurs éléments de M, certains des chunks de b a peuvent cependant être fournis par d'autres blocs candidats. Afin de pouvoir mettre à jour la contribution réellement fournie par chaque bloc candidat au cours de la démarche d'optimisation, nous normalisons le coût total à l'aide du nombre de chunks maximum fournis par un bloc candidat b a. Nous obtenons ainsi le coût d'obtention moyen coutchunk(b a ) d'un chunk du bloc candidat : coutchunk b a couttotal b,, a SRC DST nbchunks b a Le nombre de chunks nbchunkscontr(b a, M) de b a retenus pour contribuer à la construction du résultat représenté par M permet de calculer le bénéfice g(b a,m), appelé «goodness» par (Weng et al., 2005). nbchunkscontr ba, M g b a, M = coutchunk b La normalisation de la valeur du coût «par chunk» rend les différents blocs candidats comparables, car il inclut l'ensemble des coûts, de l'extraction depuis les blocs matérialisés au calcul d'agrégat. Le bénéfice est calculé pour l'ensemble des blocs candidats à la construction des blocs résultat représentés par M. Le mécanisme de sélection des meilleurs candidats que nous présentons par la suite se sert de cette valeur pour inclure progressivement les candidats retenus dans le plan d'exécution distribué. a Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 112

131 5 Exécution et optimisation de requêtes Algorithme glouton pour la construction du plan d'exécution L'algorithme que nous proposons pour la construction progressive du plan d'exécution de requête est orienté vers la minimisation locale du temps de réponse. Il s'agit d'un algorithme de type glouton opérant sur l'ensemble C de blocs candidats triée par leur valeur de bénéfice. Ces blocs doivent être utilisés pour recouvrir un ensemble M d'identifiants de blocs qui représentent la différence géométrique entre la requête initiale b r et les parties déjà couvertes par des blocs matérialisés localement. L'objectif est de trouver le meilleur recouvrement de ces blocs par une itération basée sur la sélection successive des blocs candidats. A chaque itération, l'algorithme met à jour les identifiants des blocs candidats restants afin de prendre en compte les changements occasionnés par l'ajout progressif de blocs candidats au plan d'exécution. On calcule ainsi la partie utile de chaque bloc, c'est-à-dire la partie non couverte par les blocs déjà sélectionnés. Le détail de ces opérations est décrit par l'algorithme 5.2 en annexe A. Lorsque l'algorithme choisit le bloc candidat b* a avec le plus grand bénéfice g(b* a,m) dans l'ensemble C des candidats, le reste des blocs dans C doit être mis à jour selon les règles suivantes : - Le nombre de chunks utiles nbchunkscontr(b a,m) des blocs restants dans C est diminué si ceux-ci contribuent au résultat avec les mêmes chunks que b* a. Cela entraîne notamment la suppression des blocs entièrement couverts par b* a. - Les blocs qui proviennent du même nœud source que b* a sont pénalisés, en réduisant leur bénéfice, pour tenir compte de l'occupation de ressources de ce nœud engendrée par la sélection de b* a. Cette mesure privilégie en même temps la parallélisation en favorisant l'implication d'un grand nombre de nœuds sources dans l'exécution de la requête. Le résultat que rend l'algorithme est un plan d'exécution qui permet l'exécution des sous-requêtes pour chaque bloc de M. Les opérations incluses dans ce plan d'exécution sont d'abord celles nécessaires à l'extraction des parties de blocs matérialisés. Les calculs d'agrégation sur le nœud source sont inclus dans ces requêtes générées à partir des identifiants de blocs. Pour compléter la description de l'exécution, il est nécessaire d'introduire des opérations de transfert par le réseau, que ce soit les blocs matérialisés source ou les résultats de calculs d'agrégation. L'opération d'union est également incluse afin de décrire l'assemblage des chunks des parties du résultat. Exemple 5.5 : Construction progressive d'un plan d'exécution optimisé Nous prenons l'exemple simplifié d'une requête b* r soumise au nœud LYON aux niveaux levels(b* r ) = {ville, année, path-0} (equ. {0,2,0}). Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 113

132 5 Exécution et optimisation de requêtes b* r = <{lieu.ville.nice, temps.année.1932, pathologie.path-0.grippe}, {lieu.ville.st Etienne, temps.année.1939, pathologie.path-0.bronchite}> (equ. <{1.0.2, 2.2.8, 3.0.8},{1.0.5, , 3.0.9}>) Les blocs indexés sur les différents nœuds répondant en partie à la requête sont les suivants : Nœud LYON : b* LY12 = <{lieu.ville.toulon, temps.année.1925, pathologie.path-0.grippe}, {lieu.ville.marseille, temps.année.1933, pathologie.path-0.bronchite}> (equ. <{1.0.1, 2.2.1, 3.0.8},{1.0.3, 2.2.9, 3.0.9}>) Nœud TOULOUSE : b' TO2 = <{lieu.ville.toulon, temps.année.1930, pathologie.path-0.pneumonie}, {lieu.ville.st Etienne, temps.année.1939, pathologie.path-0.asthme}> (equ. <{1.0.1, 2.2.6, 3.0.7},{1.0.5, , }>) Nœud LILLE : b LI3 = <{lieu.ville.marseille, temps.année.1937, pathologie.path-0.pneumonie}, {lieu.ville.st Etienne, temps.année.1939, pathologie.path-0.asthme}> (equ. <{1.0.3, , 3.0.7},{1.0.5, , }>) La figure 5.11 illustre les positions des différents blocs dans l'espace multidimensionnel de membres et leurs chevauchements respectifs. Nous commençons par calculer les valeurs de bénéfice pour chaque bloc candidat : g(b cli3,b* r ) = nbchunkscontr(b cli3,b* r ) / coutchunk(b cli3 ) = 18 / 0,112s = 160,71s -1 g(b' cto2,b* r ) = nbchunkscontr(b' cto2,b* r ) / coutchunk(b' cto2 ) = 48 / 0,185s = 259,46s -1 g(b cly12,b* r ) = nbchunkscontr(b cly12,b* r ) / coutchunk(b cly12 ) = 8 / 0,32s = 25s -1 Avant de pouvoir lancer l'algorithme glouton de sélection des blocs candidats, l'ensemble C est trié selon le bénéfice : C = {(b' cto2 ;259,46s -1 ),(b cli3 ;160,71s -1 ),(b cly12 ;25s -1 )} Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 114

133 5 Exécution et optimisation de requêtes TEMPS (année) TEMPS (année) b LI3 b LI b* r 1936 b' TO2 b' TO b* LY b* LY Toulon Nice Marseille Bourg-en-Bresse St Etienne Grenoble Lyon Alexandrie Novare Turin LIEU (ville) méningite mal. Alzheimer sclérose en pl. épilepsie pneumonie grippe bronchite PATHOLOGIE (path-0) asthme Figure 5.11 : Recouvrement de la requête b* r sur le nœud LYON A partir de cet ensemble, la première itération de l'algorithme sélectionne le bloc candidat b' cto2 avec le bénéfice maximum. La mise à jour des blocs candidats restants dans C élimine aussi bien b cli3 que b cly12, car ceux-ci sont entièrement contenus dans b' cto2. L'identifiant b' cto2 sert à construire le plan d'exécution sous forme de requête OLAP sur le nœud TOULOUSE. Le transfert vers le nœud LYON et l'assemblage du résultat sont ajoutés pour donner le plan d'exécution final. L'ensemble des opérations nécessaires associées à un bloc source qui fournit une partie du résultat avant cet assemblage final sont regroupées au sein d'une «tâche», ou «job» dans le vocabulaire usuel des grilles de calcul. Afin de compléter le plan d'exécution, pour chaque élément de l'ensemble R des blocs source matérialisés localement une tâche est construite et ajoutée au plan d'exécution. A partir du plan d'exécution ainsi construit, le nœud destination va procéder à l'ordonnancement des différentes tâches décrites par ce plan. Le lancement de ces tâches sur les différents nœuds de la grille entraîne une phase d'exécution parallèle des sous-requêtes associées aux blocs sources sélectionnés. Nous présentons ce processus plus en détail dans la section suivante. 6 Exécution parallèle et distribuée de requêtes L'exécution proprement dite du plan d'exécution distribué se divise en une phase préparatoire, qui comprend un ordonnancement rapide des différentes Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 115

134 5 Exécution et optimisation de requêtes tâches qui peuvent être parallélisées et une phase de lancement et de surveillance qui aboutit avec l'assemblage du résultat et sa transmission à l'application client. Dans un premier temps, nous considérons que le plan d'exécution construit est constitué de tâches indépendantes attribuées à différents nœuds source. Ces tâches ont pour seul point commun la matérialisation de leur résultat sur le nœud destination, ce qui les rend entièrement indépendantes les unes des autres. Dans un deuxième temps, il nous faudra prendre en compte la compétition qui existe entre les différentes tâches pour les ressources en rapport avec le nœud destination sur lequel le résultat doit être matérialisé. 6.1 Ordonnancement des tâches de transfert et de calcul Le nœud destination procède à un ordonnancement par catégories de tâches. Cet ordonnancement se fait selon un ensemble de règles heuristiques visant à prendre en compte les conflits de ressources potentiels dus au fait que l'ensemble des chunks résultat doit aboutir sur un seul nœud destination. La procédure d'ordonnancement attribue à chaque tâche une priorité pour le lancement de son exécution. Comme le montre la figure 5.12, nous obtenons ainsi plusieurs phases en fonction du type et de la complexité de chaque tâche, c'est-à-dire selon si elle est constituée uniquement d'une opération d'extraction, d'opérations de transfert voire d'opérations de calcul sur les nœuds sources ou nœuds destination. extraction distante phase 1 extraction locale phase 2 transfert sources calcul local calcul local phase 3 extraction distante calcul distant transfert résultat phase 4 phase 5 extraction distante extraction locale transfert source union parties TEMPS Figure 5.12 : Phases de lancement des différentes tâches du plan d'exécution distribué Le nœud source regroupe donc les tâches du plan d'exécution en cinq phases de lancement distinctes : Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 116

135 5 Exécution et optimisation de requêtes 1. Les tâches comportant le transfert de blocs matérialisés depuis un nœud source suivi d'un calcul d'agrégation sur le nœud destination sont lancées en premier. Pour ce type de tâche, le calcul d'agrégation dépend de l'aboutissement du transfert des données source vers le nœud destination. L'anticipation de ce transfert augmente les possibilités d'ordonnancement des calculs sur le nœud destination. 2. Les tâches constituées d'opérations de calcul d'agrégation à partir de blocs matérialisés sur le nœud destination sont lancées ensuite. Ceci permet d'utiliser au mieux la capacité de calcul du nœud destination en attendant l'aboutissement des transferts lancés précédemment. 3. Les tâches comportant des calculs d'agrégation sur le nœud source avant le transfert des chunks résultat sont ensuite soumises aux nœuds sources concernés. Il s'agit ici d'anticiper le transfert des résultats qui dépend essentiellement de l'aboutissement du calcul d'agrégation. 4. Les dernières tâches dépendant de nœuds sources distants, à savoir les simples tâches de transfert de blocs matérialisés sont lancées par la suite. Elles sont indépendantes des capacités de calcul disponibles des différents nœuds et occupent la bande passante du lien réseau en attendant l'aboutissement des calculs lancées en phase Les tâches qui ne consistent qu'à extraire des chunks matérialisés sur le nœud destination sont lancées en dernier. Leur aboutissement rapide permet d'assembler immédiatement une partie du résultat qui peut déjà être transférée à l'utilisateur ou peut lui indiquer la progression de l'exécution. Exemple 5.6 : Ordonnancement des tâches d'un plan d'exécution distribué optimisé Le plan d'exécution construit dans le cadre de l'exemple 5.5 est illustré par la figure Ce plan comprend une tâche qui extrait et transfère la partie b cli3 du bloc matérialisé b LI3 du nœud LILLE vers le nœud LYON. La seconde tâche extrait et agrège les parties b' cto2-1 et b' cto2-2 du bloc calculable b' TO2 sur le nœud TOULOUSE avant de transférer le résultat vers le nœud LYON. La première tâche appartient donc à la phase de lancement 4 (transfert de bloc matérialisé) et doit être lancée juste après la deuxième tâche qui appartient, elle, à la phase de lancement 3 (calcul sur nœud source, puis transfert). Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 117

136 5 Exécution et optimisation de requêtes Figure 5.13 : Plan d'exécution distribué optimisé pour la requête b* r Une fois le lancement de l'ensemble des tâches effectué, le nœud destination met en place une surveillance de l'exécution et réceptionne les chunks résultat dans une structure dédiée. 6.2 Surveillance de l'exécution et assemblage du résultat Les fonctions de surveillance de l'exécution des différentes tâches sont fournies par l'infrastructure de grille. L'objectif de la surveillance est de prévenir les délais supplémentaires dus à la surcharge ou l'indisponibilité soudaine d'un nœud source, un phénomène connu dans un environnement dynamique et partagé comme la grille Surveillance et mise à jour du statut de l'exécution La surveillance concerne uniquement les nœuds sources sur lesquels sont exécutés des tâches sur plan d'exécution distribué. En fonction de la durée estimée de l'exécution, le nœud destination sollicite à intervalles réguliers les nœuds source. Ce mode de communication appelé «polling» permet de mettre à jour régulièrement le statut d'avancement de l'exécution de la requête. Le nœud destination peut ainsi transmettre en continu l'information sur la progression de la requête à l'application client. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 118

137 5 Exécution et optimisation de requêtes De plus, cela permet de détecter au plus tôt l'indisponibilité d'un nœud source et de prendre des mesures adaptées pour compenser cette défaillance. Le nœud destination garde en mémoire le temps estimé pour l'exécution de chaque tâche et la compare au temps réellement utilisé. Dès que ce temps est dépassé et/ou si un nœud source tarde à répondre à la sollicitation du nœud destination, celui-ci peut déclencher une opération de remplacement pour la partie b p des chunks résultat qui aurait due être fournie par le nœud source. Le remplacement consiste essentiellement à relancer la procédure de choix optimisé d'un bloc candidat b a décrite en section 5.2.2, mais cette fois-ci limité à la requête b p. Si un recouvrement de b p est trouvé, le nœud source peut alors créer une ou plusieurs tâches qui vont fournir les chunks demandés Assemblage du résultat Les blocs de chunks représentant les différentes parties du résultat sont matérialisés au fur et à mesure de l'aboutissement des tâches du plan d'exécution sur le nœud destination. Il reste alors une opération d'union à effectuer pour chacun de ces résultats partiels afin d'obtenir le bloc représentant le résultat. Comme ces parties sont toutes complémentaires, il n'y a aucune détection de doublons à effectuer. Grâce à l'ordonnancement des membres dans les différentes dimensions le nœud destination peut facilement assembler les chunks dans l'ordre dans lequel ils seront transmis à l'application client. 7 Conclusion La méthode d'optimisation et d'exécution des requêtes sur l'entrepôt réparti sur grille que nous avons présenté dans ce chapitre tire pleinement profit de nos structures d'indexation des données disponibles déployées sur la grille. Cette infrastructure basée sur le modèle d'identification unique des chunks de données multidimensionnelles introduit au chapitre 3 facilite le recensement des différentes possibilités pour obtenir les chunks qui satisfont la requête. Ainsi, à partir d'une requête OLAP utilisateur classique, nous avons développé les différentes phases de traitement, de la recherche des chunks disponibles jusqu'à une démarche d'optimisation pour minimiser le temps de réponse à la requête. L'optimisation se base sur un calcul de coût qui inclut aussi bien les estimations de coût d'extraction calculées lors de l'indexation des blocs que les estimations de coût de calcul et de transfert par le réseau qui sont calculées dynamiquement grâce aux données fournies par le système de surveillance de la grille. La phase d'optimisation produit un plan d'exécution distribué dont les opérations sont regroupées en tâches exécutables en parallèle. Ces tâches subissent une dernière sélection pour favoriser un ordonnancement adapté aux contraintes du traitement sur la grille avant d'être lancées sur les différents nœuds. La phase finale comporte la surveillance de l'exécution et l'assemblage progressif du résultat qui est finalement transmis à l'application client. L'ensemble du traitement des requêtes est transparent aux yeux de l'utilisateur qui s'adresse à un seul nœud interface interagissant avec les autres nœuds de la grille pour répondre à la requête. Nous détaillons au chapitre suivant l'architecture de services de grille qui implémente la structure d'indexation et l'ensemble des Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 119

138 5 Exécution et optimisation de requêtes services pour la recherche des chunks de données sur la grille et l'exécution optimisée des requêtes. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 120

139

140

141 Chapitre 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Dans ce chapitre, nous présentons l'architecture de services de grille conçue pour implémenter les modèles et les méthodes pour l'identification, l'indexation et l'interrogation des données multidimensionnelles de l'entrepôt réparti sur grille. Les services que nous avons réalisés pour l'exploitation de l'entrepôt distribué s'appuient sur les services existants dans l'infrastructure de grille. Après l'organisation fonctionnelle des services, nous introduisons un schéma de répartition des services de grille parmi les différents nœuds de grille. En fonction de la structure d'une organisation virtuelle sur la grille, nous définissons une politique de déploiement de ces fonctionnalités. La démarche est illustrée par la description du traitement de requêtes sur l'entrepôt de données réalisé dans le cadre du projet GGM. 1 Présentation des services de grille GIROLAP pour l'entrepôt distribué Les services de grille qui constituent l'infrastructure de grille proprement dite sont encadrés par l'intergiciel de grille Globus Toolkit 4.0 (Foster, 2005) conforme au standard OGSA (Open Grid Services Architecture). Une application utilisant la grille dispose des fonctionnalités d'un ensemble de services déjà fournis par l'infrastructure de grille. Sur cette base, nous avons conçu et implémenté l'architecture de services de grille GIROLAP (Grid Infrastructure for Relational OLAP) qui s'appuie sur l'infrastructure de grille initiale. GIROLAP ajoute à l'infrastructure des services spécifiques à la gestion et à l'interrogation des données multidimensionnelles d'un entrepôt réparti sur la grille. Les nœuds de la grille qui participent à l'exploitation de l'entrepôt de données distribué fournissent un ensemble de services prenant en charge l'indexation, la communication et le catalogage des données présentes sur la grille. Le tableau 6.1 présente le nom de chaque service et la forme sous laquelle il est implémenté, avec les fonctionnalités mises à disposition par chacun des services. Les services en italique sont les services fournis par l'infrastructure de grille Globus Toolkit ou réalisés par d'autres équipes du projet GGM, les autres étant ceux que nous avons développés. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 123

142 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Nom GridFTP(intégré à Globus) Type d'implémentation application client/server Fonctionnalités - Transfert de fichiers entre nœuds de grille Grid Resource Allocation and Management service (GRAM, intégré à Globus) service de grille - Exécution de tâches de calcul sur un nœud - Suivi de la progression de l'exécution de tâche Dimension Manager (DM) bibliothèque logicielle - Mise à disposition d'identifiants de chunks multidimensionnels - Calculs géométriques sur les identifiants de chunks Local Index Service (LIS) Service de grille - Indexation des chunks matérialisés sur un nœud de grille - Calcul et mise à jour des chunks calculables à partir des chunks matérialisés Chunks Resolution Service (CRS) Service de grille - Localisation de chunks au niveau de la grille entière - Evaluation des coûts de calcul et de transfert Chunk Localization Array Catalog (CLAC) Service de grille - Recensement des blocs disponibles sur la grille Network Weather Service (NWS, intégré à Globus) Application client/server - Localisation des nœuds possédant certains blocs - Mesure de bande passante, capacité CPU etc. - Transfert et stockage des mesures recueillies Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 124

143 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Network Distance Service (NDS) Service de grille - Mise à disposition des informations sur les conditions de transfert et de calcul - Calcul d'indicateurs de performances Query Execution Management Service (QEMS) Service de grille - Réécriture de requêtes OLAP client - Construction de plans d'exécution optimisés à partir du résultat de la localisation IHM client OLAP JPivot+Mondrian Application web client - Lancement et gestion de l'exécution distribuée de la requête - Client OLAP - Construction de requêtes OLAP en SQL - Présentation interactive des résultats (tableau Pivot, présentation graphique) Tableau 6.1 : Nom et fonctionnalités mises à disposition par chaque service de grille Un exemple de l'architecture GIROLAP déployée sur une grille est illustré par la figure 6.1. On notera qu'un service peut être déployé sur plusieurs nœuds de la grille, par exemple le service LIS qui prend en charge l'indexation des données locales sera implémenté sur les nœuds qui hébergent des données de l'entrepôt. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 125

144 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Figure 6.1 : Déploiement exemple des services de l'architecture GIROLAP Nous détaillons par la suite les fonctionnalités de chaque service ainsi que les interfaces et interactions de ces services entre eux. Afin de garantir une démarche cohérente, nous commençons par les services fournis par l'infrastructure de grille que nous utilisons. 1.1 Services d'accès aux données et de calcul fournis par le Globus Toolkit L'infrastructure de grille basée sur l'intergiciel «Globus Toolkit 4.0» comprend un choix de services de base nécessaires pour effectuer les tâches inhérentes à une grille de calcul, à savoir l'exécution de calculs sur des données stockées sur les différents nœuds de la grille. Chaque nœud donne accès aux données qu'il héberge en activant une instance du service GridFTP (Allcock et al., 2002). Ce service opère au niveau de fichiers pour en extraire des lignes selon plusieurs critères de sélection. Les blocs de chunks étant stockées sous forme de fichiers, c'est donc ce service que nous utilisons pour effectuer l'extraction des chunks suite à une requête. Pour le calcul des agrégats, un nœud met sa capacité de calcul à disposition de la grille via le service d'allocation et de gestion des ressources qui prend en charge et ordonnance les tâches de calcul à exécuter sur ce nœud. Ce service, nommé «Grid Resource Allocation and Management service» (GRAM), permet de calculer à la volée des agrégats sur chaque nœud. Ces services fonctionnent localement sur chaque nœud de grille. Leurs fonctionnalités se limitent aux données matérialisées sur les supports physiques du nœud et ne prennent pas en compte le modèle multidimensionnel de l'entrepôt de données réparti. L'accès par les identifiants basés sur le modèle multidimensionnel est géré par le service d'identification des données multidimensionnelles. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 126

145 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) 1.2 Service d'identification des données multidimensionnelles : «Dimension Manager» (DM) Comme nous l'avons décrit au chapitre 3, les identifiants de chunks et de blocs de chunks sont construits à partir des ensembles de membres ordonnés pour chacune des dimensions du modèle. L'ordonnancement des hiérarchies de membres de dimension et la gestion des identifiants sont pris en charge par le service d'identification des données multidimensionnelles, implémenté par le «Dimension Manager» (DM) Fonctionnalités Pour disposer des hiérarchies de membres ordonnées, le DM s'appuie sur les instances locales des dimensions matérialisées sur chaque nœud. Le DM construit des identifiants de chunks à partir de ces membres ordonnés. En utilisant les identifiants de chunks, le DM définit les identifiants de blocs de chunks matérialisés ou calculables, i.e. il détermine les ensembles de chunks contigus selon l'ordre introduit. Figure 6.2 : Représentation des identifiants de blocs et de leur intersection Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 127

146 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Le DM définit également le plan de calcul associé aux identifiants de blocs de chunks calculables. Il réalise les opérateurs géométriques tels que l'intersection ou la différence sur l'ensemble des identifiants de chunks. Ces opérateurs sont essentiels pour l'indexation et la localisation des chunks ainsi que le traitement de requêtes. La figure 6.2 montre plusieurs identifiants de blocs indexés sur le nœud LYON. Par exemple, le bloc encadré A est décrit par les informations décrivant la forme sous laquelle est matérialisé le bloc ainsi que le coût estimé pour le chargement du bloc entier (A.1). Cette information est associée à l'identifiant du bloc décrivant sa position dans l'espace multidimensionnel de membres (A.2) Interaction avec les autres services Les fonctionnalités mises à disposition par le Dimension Manager sont utilisées par la majorité des services du système GIROLAP. En effet, en mettant à disposition les fonctionnalités de création et de modification des identifiants de chunks et de blocs de chunks, le DM fournit les opérations de base pour le fonctionnement des mécanismes d'indexation et de localisation au sein de l'entrepôt réparti. Compte tenu du nombre d'appels que cela représente, le DM n'est pas réalisé comme un service de grille, mais comme une bibliothèque logicielle. Cette bibliothèque est intégrée à chaque service faisant appel aux fonctions d'identification et de calculs sur ces identifiants. Le service d'indexation locale notamment intègre le DM pour construire l'index TX des blocs disponibles sur un nœud. 1.3 Service d'indexation locale : «Local Indexing Service» (LIS) Pour pouvoir localiser les données de l'entrepôt réparti sur la grille, chaque nœud hébergeant des données matérialisées de l'entrepôt déploie une instance du service d'indexation locale, le «Local Indexing Service» (LIS) Fonctionnalités Ce service construit et maintient l'index TX des blocs de chunks localement disponibles, tel que décrit au chapitre 3 pour les données matérialisées et au chapitre 4 pour les agrégats calculables. Cet index permet de rendre rapidement accessible l'ensemble des blocs de chunks disponibles sur le nœud sur lequel il est déployé, soit par extraction depuis un bloc matérialisé, soit par calcul à la volée suite à une requête portant sur des agrégats non matérialisés. Le LIS fournit ainsi l'information nécessaire à la localisation des chunks disponibles pour répondre à une requête. La figure 6.3 illustre la structure de l'index TX avec un sommet de treillis et un index X spatial associé à chaque niveau d'agrégation. Dans l'exemple présenté, les blocs calculables b' 1 et b' 2 sont indexés sur le sommet v' du treillis. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 128

147 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Figure 6.3 : Visualisation en deux dimensions de la structure de l'index TX sur un nœud Le service LIS offre également les fonctionnalités de mise à jour et de recherche dans l'index TX. La construction ou la modification de l'index TX intervient lors du déploiement ou de la mise à jour de l'entrepôt. L'index doit être mis à jour en fonction des ajouts ou suppressions de blocs matérialisés sur le nœud de grille. Le LIS permet donc d'insérer dans l'index un bloc matérialisé décrit par son identifiant associé à un ensemble de propriétés nécessaires à l'accès aux données et à l'estimation des coûts d'extraction de chunks à partir de ce bloc (voir chapitres 3 et 4). Seuls les identifiants de blocs matérialisés sont explicitement insérés car l'ensemble des blocs calculables est automatiquement créé et mis à jour au sein de l'index en fonction des blocs matérialisés indexés. Lors de l'appel de l'opération de suppression d'un bloc matérialisé dans l'index TX, le LIS effectue la mise à jour des blocs calculables dépendants. Pour chaque insertion ou suppression d'un bloc indexé, le LIS implémente un mécanisme de notification. Celui-ci permet de faire remonter les informations sur les blocs disponibles pour une publication au sein de la grille vers le service de catalogue des blocs de chunks (voir section 1.5). Contrairement aux opérations d'insertion et de suppression, la consultation de l'index TX n'entraîne aucune mise à jour ou notification. L'opération de requête est donc conçue pour renvoyer en un délai minimum toute l'information pertinente sur les possibilités d'obtenir les chunks de données décrits par la requête. Pour cette opération, le LIS prend en argument un identifiant de bloc de chunks recherchés. Le résultat est une liste d'identifiants de blocs Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 129

148 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) matérialisés ou calculables indexés qui peuvent fournir au moins une partie des chunks demandés. Comme nous l'avons décrit au chapitre 5, les plans de calcul pour ces blocs calculables sont adaptés et les mesures de coût estimé pour l'obtention des chunks résultat sont également recalculées en fonction de la requête Interaction avec les autres services Les fonctionnalités du service LIS sont sollicitées par le service de recherche de chunks (voir section 1.4) lors de la phase de localisation des données, aussi bien lors de la recherche locale que pendant la recherche parmi l'ensemble des nœuds de la grille. Pour orienter la recherche sur l'ensemble de la grille, le LIS publie à l'avance l'information sur les blocs disponibles. Cette publication se fait via le service de catalogue de chunks (CLAC) qui stocke l'ensemble de l'information sur la disponibilité de blocs de chunks sur chaque nœud. Il est donc nécessaire de mettre à jour les informations publiées suite à toute opération de maintenance sur le LIS. Le déclenchement de cette mise à jour passe par un système de notification auquel est abonné le CLAC, qui est ainsi averti de tout changement dans l'index TX d'un nœud. La fraîcheur des informations ainsi recueillies par le CLAC est importante pour un bon déroulement de la phase de localisation de chunks qu'effectue le service de recherche de chunks. 1.4 Service de recherche de chunks : «Chunk Resolution Service» (CRS) Le service de recherche de chunks, nommé «Chunk Resolution Service» (CRS), permet de localiser les blocs matérialisés ou calculables disponibles sur la grille correspondant à une requête donnée Fonctionnalités La fonction de recherche de chunks mise à disposition par le CRS prend comme argument une requête exprimée sous forme d'identifiant de bloc. Le résultat qu'il renvoie est constitué de la liste des blocs candidats introduite au chapitre 5, c'est-à-dire l'ensemble des identifiants de blocs calculables qui répondent au moins partiellement à la requête. Avec ces identifiants de blocs candidats, le CRS fournit également le plan de calcul associé à chaque bloc candidat ainsi que les mesures de débit réseau et de capacité de calcul des nœuds source et destination. La figure 6.4 montre le déroulement de la recherche avec l'interrogation successive des nœuds source. Ainsi on voit la phase de localisation d'une requête exécutée sur le nœud «TOULOUSE». Aucun bloc indexé sur ce nœud ne peut contribuer au résultat, donc le CRS soumet la même requête aux autres nœuds (après avoir consulté le catalogue) et reçoit une réponse positive de la part du nœud LYON. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 130

149 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Figure 6.4 : Phase de localisation de chunks exécutée par le service de recherche de chunks Interaction avec les autres services L'opération de localisation des chunks parmi l'ensemble des nœuds de la grille s'appuie sur l'opération de recherche locale dans l'index TX construit sur un nœud via l'interface du LIS. Le CRS interroge en premier le catalogue des blocs disponibles au sein de la grille entière mis à disposition par le CLAC. Une fois orienté par la liste de nœuds fournie par le CLAC, le CRS interroge les instances du LIS de la liste de façon ciblée. Les informations sur les conditions de transfert et de calcul sur les nœuds source et destination sont obtenues à partir d'une interrogation du service de surveillance NDS (voir section 1.6). Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 131

150 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) 1.5 Service de catalogue des blocs de chunks : «Chunk Localization Array Catalog» (CLAC) Afin d'orienter les recherches de chunks effectuées par le CRS sur la grille les identifiants des blocs de chunks disponibles sur chaque nœud sont publiés par le service de catalogue, nommé «Chunk Localization Array Catalog» (CLAC). Ce service regroupe les identifiants des blocs indexés sur l'ensemble des nœuds Fonctionnalités Chaque index local signale à une instance du CLAC sa capacité à fournir des chunks de l'entrepôt. Cet index transmet tous les identifiants de blocs en spécifiant s'ils sont matérialisés ou calculables. Le CLAC stocke les identifiants recensés en les associant aux adresses des nœuds qui les hébergent. Le catalogue ne sauvegarde que les identifiants, ce qui permet de détecter les intersections avec les requêtes soumises sans gérer les dépendances entre les blocs matérialisés et calculables. Les données associées sur les lieux de stockage physiques des blocs sources ainsi que les plans de calculs ne sont fournis que par les nœuds sources eux-mêmes. Le catalogue est stocké dans une base de données relationnelle capable de traiter un grand nombre de requêtes simples. La structure du déploiement du service de catalogue par rapport aux instances de LIS et de CRS est décrite en section Interaction avec les autres services Le CLAC met à disposition l'opération de recherche de nœuds utilisée par les différentes instances du CRS. Les interactions avec les services d'indexation locale (LIS) sur lequel s'appuie le CLAC sont les suivantes : - Une instance du LIS nouvellement déployée signale sa présence, - le CLAC s'abonne à cette nouvelle instance, - le LIS signale par notification les changements dans son index TX. Le catalogue dispose ainsi de données à jour à propos de la disponibilité des blocs de chunks sur les nœuds de la grille. Pour enrichir encore cette information, les données de surveillance de la grille sont fournies par un service spécialisé. 1.6 Service de surveillance de la grille : «Network Distance Service» (NDS) Comme nous l'avons présenté au chapitre 5, au moment de la dernière étape de la phase de localisation, les mesures de capacité de transfert et de calcul pour chaque nœud source potentiel sont recensées. Ces données sont fournies par le service de surveillance de l'état de la grille, le «Network Distance Service» (NDS). Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 132

151 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Fonctionnalités Le NDS a été développé par une des équipes partenaires du projet GGM (Gossa et al., 2006). Il s'appuie notamment sur le «Network Weather Service» (NWS) (Wolski, 1997), intégré à l'infrastructure de grille qui mesure en continu la vitesse et la latence des liens entre nœuds à l'aide d'un réseau de senseurs sur l'ensemble des nœuds de la grille. Le NDS permet d'obtenir des valeurs brutes sur l'état de la grille ainsi que des valeurs calculées à partir des métriques de base. La figure 6.5 montre un client graphique qui expose les fonctionnalités du service, avec en 1) la sélection des sources et destination des transferts à mesurer, 2) le choix des métriques disponibles, 3) la définition des fonctions dérivées des valeurs de base et en 4) le graphe des nœuds objets de la mesure. Figure 6.5 : Client graphique Java du service NDS (Gossa et al., 2006) Interaction avec les autres services Le NDS utilise les données obtenues par le réseau de senseurs du NWS. Le NDS est invoqué par le CRS au cours de la phase de localisation. Les données collectées sont intégrées au résultat de la localisation et transmises au service de gestion de l'exécution des requêtes, que nous allons présenter dans la section suivante. Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 133

152 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) 1.7 Service de gestion de l'exécution de requêtes : «Query Execution Management Service» (QEMS) Le service de gestion de l'exécution de requête a pour but de coordonner l'ensemble des opérations nécessaires à l'interrogation de l'entrepôt réparti GIROLAP. Ce service, baptisé «Query Execution Management Service» (QEMS), délègue la recherche des chunks demandés au CRS mais gère lui-même l'optimisation, l'ordonnancement et la surveillance de l'exécution d'une requête. Il prend en charge la communication avec l'application client et gère l'exécution distribuée des requêtes en interne de l'entrepôt Fonctionnalités Le QEMS assure la fonction de réécriture de la requête client soumise en format SQL. Cette réécriture vers le format bloc de chunks, comme décrite au chapitre 5, permet de transmettre la requête au CRS chargé le la localisation des données. La gestion de l'exécution assurée par le QEMS implique également la construction d'un plan d'exécution optimisé pour l'obtention des chunks non matérialisés sur le nœud destination. Cette fonction prend en entrée la liste des blocs candidats avec les estimations de coûts fournies pas le CRS suite à la phase de localisation. L'exécution du plan établi est ordonnancée, lancée et supervisée par le QEMS qui assemble ensuite les résultats partiels avant de les transférer au client. La figure 6.6 montre l'interface de gestion conçue pour lancer manuellement les opérations de la démarche implémentée par le QEMS. Figure 6.6 : Phase de localisation supervisée par le service de gestion de l'exécution de requêtes Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 134

153 6 Le prototype GIROLAP (Grid Infrastructure for Relational OLAP) Une fois que le chargement et l'indexation des blocs matérialisés et des blocs calculables à partir de ceux-ci est achevé, cette interface permet de charger des requêtes exprimées sous forme de blocs de chunks et de les exécuter sur un des nœuds, en obtenant en retour la trace de l'exécution de la requête Interaction avec les autres services Après avoir reçu et réécrit la requête de l'application cliente, le QEMS lance la localisation des chunks recherchés en invoquant le CRS. L'interaction avec le CRS se limite à la transmission de la requête et la récupération des ensembles de blocs qui peuvent contribuer à la requête localisés. Le QEMS maintient également la connexion avec l'application client et lui attribue un identifiant de session à l'aide duquel le contexte d'interrogation est sauvegardé. L'application client est informée du statut de l'exécution de la requête via des notifications émises par le QEMS au cours de l'exécution. En cas de perte de connexion l'exécution de la dernière requête soumise est menée à bien et les données de la session maintenues pendant un délai fixe. Chaque requête soumise au QEMS est ainsi exécutée dans son contexte indépendant. Après avoir construit un plan d'exécution distribué pour la requête le QEMS va lancer et gérer son exécution. Le QEMS sollicite alors directement les services d'accès aux données et de calcul et les surveille à l'aide des mécanismes de notification ou de surveillance de l'intergiciel de grille. L'interaction du QEMS avec ces services nécessite une certaine orchestration des services de grille. Nous allons dans la section 2 exposer les constellations de services de l'architecture GIROLAP pertinentes pour le déploiement d'un entrepôt de données réparti. 1.8 Interface client OLAP L'interrogation de l'entrepôt réparti fourni par l'architecture GIROLAP nécessite une interface client interactive. La solution que nous employons pour la navigation à travers les hypercubes est constituée de l'application web JPivot (JPivot, 2008) qui présente une vue dite de «table de pivot», permettant à l'utilisateur de visualiser et de naviguer à travers plusieurs dimensions à l'aide d'une simple table. Figure 6.7 : Interface graphique JPivot avec table de pivot montrant un hypercube de l'entrepôt GGM Pascal Wehrle/Thèse en informatique/2009/institut national des sciences appliquées de Lyon 135