Entreposage et analyse en ligne dans les nuages avec Pig

Transcription

1 Entreposage et analyse en ligne dans les nuages avec Pig Laurent d Orazio* Sandro Bimonte** * Clermont Université Université Blaise Pascal, LIMOS UMR 6158 CNRS ISIMA, Campus des Cézeaux F Aubière cedex laurent.dorazio@isima.fr ** Cemagref, UR TSCF 24 Avenue des Landais F Clermont-Ferrand sandro.bimonte@cemagref.fr RÉSUMÉ Les entrepôts de données et les systèmes OLAP permettent d analyser à la volée de gros volumes de données. L informatique dans les nuages vise à proposer des capacités de calcul et de stockage virtuellement infinies. Considérer l analyse et l entreposage de données au sein des nuages informatiques devient alors un enjeu majeur. Les problèmes à aborder sont ceux classiques des systèmes largement distribués, mais sous un nouvel angle prenant en compte les spécificités de ce paradigme : facturation à l utilisation, élasticité et facilité d utilisation. Cet article aborde dans un premier temps les règles de facturation à l utilisation pour le stockage des entrepôts de données. Nous proposons d utiliser pour les nuages des techniques de stockage à base de tableaux multidimensionnels. Ensuite, nous nous intéressons à l analyse OLAP en proposant de nouveaux opérateurs et des règles d optimisation, dont l intérêt est mis en avant par de premières expérimentations. Enfin, nous listons des perspectives de recherche pour la définition d un cadre théorique et pratique pour l entreposage et l analyse en ligne dans les nuages. ABSTRACT. Data warehouses and OLAP systems are decision support technologies for online analysis of large volumes of data. Cloud computing aims at supplying virtually infinite computing and storage resources. Considering OLAP analysis and data warehousing in the cloud becomes a major issue. The problems to be considered are those of conventional large scale distributed systems, but from a new point of view that takes into account the specificities of this paradigm: pay as you go model, elasticity and user-friendliness. This paper initially investigates data warehouse storage issues. We propose to use multidimensional arrays for the storage of cloud-based data warehouses. Then, we focus on OLAP analysis by proposing new operators and optimization rules, whose relevance is shown by initial experiments. Finally, we list research perspectives on the definition of a theoretical framework and implementation for multidimensional storage and online analysis in the clouds. MOTS-CLÉS : entrepôts de données, OLAP, Cloud, Pig. KEY-WORDS: data warehouses, OLAP, Cloud, Pig. DOI: /ISI Lavoisier, Paris RSTI - ISI 16/2011. Qualité des entrepôts de données, pages 141 à 164

2 142 RSTI - ISI 16/2011. Qualité des entrepôts de données 1. Introduction Les entrepôts de données et les systèmes OLAP (On-Line Analytical Processing) représentent des technologies d aide à la décision qui permettent l analyse en ligne de gros volumes de données (Inmon, 1996). Dans une architecture Relational OLAP (ROLAP), les systèmes OLAP sont déployés en utilisant des systèmes de gestion de bases de données relationnels pour stocker et analyser les données. Quand les données sont denses, l approche Multidimensional OLAP (MOLAP) peut être utilisée (Zhao et al., 1997). L architecture MOLAP stocke les données à l aide de structures multidimensionnelles ad hoc, telles que des tableaux multidimensionnels, afin de réduire la taille des données stockées. Enfin, il existe une autre typologie qui combine les deux technologies : Hybrid OLAP (HOLAP). Selon cette approche, une partie des données est stockée en relationnel et l autre en utilisant des techniques multidimensionnelles. Les architectures hautes performances visent à faire face aux besoins croissants en termes de calcul et de stockage des applications scientifiques et industrielles (Armbrust et al., 2009). Parmi ces architectures, les nuages informatiques (cloud computing) sous l impulsion d entreprises telles que Google, Microsoft et Amazon suscitent actuellement une attention particulière. Les entrepôts de données et les systèmes OLAP dans les nuages soulèvent différents problèmes liés à la performance du stockage et de l interrogation (Ordonez et al., 2010). Les problèmes à aborder sont ceux classiques des systèmes distribués à grande échelle (interrogation de gros volumes de données, hétérogénéité sémantique et structurelle, variabilité, etc.), notamment abordés par les travaux autour des entrepôts de données sur grilles, (Gorawski et al., 2006 ; Mahboubi et al., 2009), mais qui doivent être considérés d un nouveau point de vue qui prend en compte les caractéristiques particulières de ces architectures : facturation à l utilisation, élasticité et facilité d utilisation (Armbrust et al., 2009). Certains travaux récents s intéressent aux technologies des bases de données et d aide à la décision dans les nuages sur différents aspects. Par exemple, différents travaux investiguent la possibilité de stocker et d interroger les données structurées (Chatziantoniou et al., 2009) et complexes (comme spatiales (Zhang et al., 2009), textuelles (Lin et al., 2010), graphes (Ravindra et al., 2010), etc.) en utilisant les technologies des nuages informatiques qui supportent les opérations d analyse comme l agrégation (Condie et al., 2010). Du point de vue des performances des requêtes OLAP, l introduction des index est par exemple abordée par la définition d une structure de données distribuée au dessus du moteur d exécution parallèle Hadoop (Konstantinou et al., 2010). L optimisation des requêtes qui utilisent les jointures a également été abordée (Sridhar et al., 2009), tout comme le calcul des cuboids OLAP à l aide de l environnement d exécution MapReduce (Kuznecov et al., 2010). Néanmoins, à notre connaissance, aucun travail ne définit un modèle de données pour le stockage de données multidimensionnelles dans les nuages considérant la

3 Entreposage et analyse en ligne dans les nuages avec Pig 143 facturation à la demande, et un langage d interrogation OLAP facile d accès basé sur Pig Latin pour des utilisateurs non experts des systèmes de gestion de données. Cet article présente une première avancée vers l implémentation d une architecture OLAP dans les nuages afin de réduire les coûts de stockage des données. En particulier, nous présentons un algorithme qui transforme les données stockées sous forme de tableaux multidimensionnels suivant le modèle de données Pig (Olston et al., 2008). Ceci permet d exécuter les requêtes OLAP en utilisant le paradigme MapReduce (Dean et al., 2008) et de réduire grandement les coûts de stockage. De plus, nous proposons une extension et une optimisation du langage Pig Latin pour les requêtes OLAP, ainsi que les opérateurs CUBE, ROLLUP et RANK au sein du langage considéré. Cet article liste ensuite des perspectives de recherche pour l analyse de données sur nuages informatiques. Cet article est organisé de la manière suivante. La section 2 présente le contexte et les motivations de ce travail. La section 3 introduit la proposition de stockage de tableaux multidimensionnels pour les nuages, et notre extension de Pig Latin pour l OLAP. La section 4 présente les expérimentations qui valident notre approche. La section 5 liste des pistes de recherche. Enfin, la section 6 conclut cet article. 2. Contexte et motivations Dans cette section nous présentons les concepts principaux des entrepôts de données et l analyse en ligne, et une infrastructure typique pour le stockage et l interrogation de données dans les nuages Cas d étude Afin de présenter notre travail, nous nous basons sur un cas d étude simulé portant sur l analyse des ventes de magasins d une chaîne internationale d approvisionnement. L utilisateur veut analyser la moyenne du profit des ventes pour chaque jour, mois et année en fonction du pays, du département, ou de la région. Le tableau 1 propose un exemple de jeu de données qui sera utilisé dans les exemples suivants. Année Mois Jour Pays Région Département Profit France Auvergne Puy-de-Dôme Italie Campanie Naples France Auvergne Puy-de-Dôme Italie Campanie Naples 3100 Tableau 1. Données des ventes

4 144 RSTI - ISI 16/2011. Qualité des entrepôts de données 2.2. Entrepôts de données et OLAP Les entrepôts de données représentent les données selon le modèle multidimensionnel. Celui-ci définit les concepts de dimension et de mesure. Une dimension est composée de hiérarchies et représente l axe d analyse. Une hiérarchie organise les données (membres) dans une structure hiérarchique permettant aux décideurs d analyser les mesures à différentes granularités. Les mesures correspondent à des indicateurs numériques décrivant le sujet d analyse (fait). Les opérateurs OLAP tels que roll-up et drill-down permettent de naviguer au sein de hiérarchies synthétisant les données à l aide des fonctions d agrégation SQL (Inmon, 1996). D autres opérateurs ont été définis pour la sélection d une partie de l entrepôt de données et la permutation des dimensions (Rafanelli, 2003). L application considérée dans la sous-section précédente présente deux dimensions : une dimension spatiale regroupant les départements en régions et pays et une dimension temporelle avec une hiérarchie jour, mois et année, tandis que la mesure est le profit. Les architectures MOLAP utilisent des structures de données multidimensionnelles telles que les tableaux multidimensionnels construits à partir des données originales, qui sont en général stockées dans des bases de données relationnelles. Les architectures MOLAP permettent d optimiser le stockage pour les entrepôts de données denses à l aide de ce modèle de stockage de données particulier (Zhao et al., 1997). En effet, les tableaux multidimensionnels permettent de stocker uniquement les mesures car elles sont indexées à l aide des positions des membres des dimensions. Par exemple, la valeur de la mesure à la position tab[2][3][4] est associée au second membre de la première dimension, au troisième membre de la deuxième dimension et au quatrième membre de la troisième dimension. Il est important de noter qu il est possible de passer d un tableau multidimensionnel à un tableau uni-dimensionnel avec la formule suivante : Soit d dimensions, N k les membres de la k-éme dimension, alors la position de la mesure dans un tableau à une dimension est : p(i 1,..., i d) = Π d j=1 (i j * Π d k = j + 1 N k) L interrogation des entrepôts de données se base essentiellement sur deux langages : MultiDimensional expression language (MDX) et/ou SQL. MDX (Mdx, 2010) est un langage qui définit l ensemble des dimensions et mesures qui doivent être affichées sous forme de table pivot (tableau multidimensionnel). Les opérations OLAP sont donc définies implicitement par l interaction avec la table pivot. MDX est indépendant de l architecture OLAP utilisée, ce qui signifie que dans le cadre d une architecture ROLAP, les requêtes MDX doivent être traduites en SQL. D un autre côté, une extension de SQL pour les opérateurs OLAP d agrégation qui produisent des totaux et sous-totaux a été définie (Gray et al., 1996) et implémentée dans la majorité des SGBD existants. Elle introduit l operateur ROLLUP et l opérateur CUBE. La différence entre les deux opérateurs est que CUBE crée tous

5 Entreposage et analyse en ligne dans les nuages avec Pig 145 les agrégats possibles, et ROLLUP crée seulement un sous-ensemble de CUBE correspondant aux hiérarchies des colonnes. Par exemple en utilisant les données du tableau 1, le résultat de l application de l opérateur CUBE sur les niveaux Année et Pays en utilisant la SUM est illustré par le tableau 2. Année Pays Profit 2010 France Italie France Italie 3100 All France 3800 All Italie All All 4900 All All Tableau 2. Résultat de l operateur Cube D autres opérateurs OLAP ont été développés tels que l opérateur RANK (Oracle, 2011) qui retourne le rang de chaque ligne au sein de la partition d un ensemble de résultats permettant de répondre aux requêtes de type top-k (Stupar et al., 2010) (par exemple les trois meilleurs profits par pays et par année) Gestion des données dans les nuages La gestion de données sur nuages se base généralement sur une architecture en couches, illustrée par la figure 1. Figure 1. Architecture de la gestion de données sur nuages

6 146 RSTI - ISI 16/2011. Qualité des entrepôts de données Le premier niveau correspond à l infrastructure. En général, ce niveau est composé d un ou plusieurs centres numériques ou centres de données (data centers), utilisé(s) pour l analyse de gros volumes de données et mis à disposition par les fournisseurs de nuages. Microsoft Azure (Microsoft, 2010) et Amazon EC2 (Amazon, 2010) sont des exemples de telles infrastructures. La principale caractéristique de ce niveau est son association au modèle de facturation à l utilisation, où les utilisateurs ne payent que pour les ressources utilisées. Le stockage repose sur Google File System (GFS) (Ghemawat et al., 2003), un système de fichiers distribués passant à l échelle, dédié aux applications de traitement intensif de masses de données. Au sein de GFS, les fichiers sont divisés en blocs d une taille fixe stockés sur les disques locaux de différents serveurs, chaque segment étant répliqué sur plusieurs serveurs (trois copies par défaut). Afin de fournir un débit élevé, GFS sépare les flux de contrôle, qui passent par une entité centralisée, et les flux de données, qui traversent les serveurs stockant les données. GFS aborde également le problème de la tolérance aux fautes via une surveillance constante et une restauration rapide et automatique. L environnement d exécution MapReduce (Dean et al., 2008) est un modèle de programmation et une instance associée pour le traitement et la génération de grands volumes de données. Les développeurs spécifient deux fonctions : (1) une fonction map qui traite des paires (clé k1, valeur v1) afin de générer un ensemble de paires intermédiaires (clé k2, valeur v2) (cette fonction peut être considérée comme un groupement) ; (2) une fonction reduce qui synthétise toutes les valeurs intermédiaires associées à une même clé intermédiaire (cette fonction pouvant être considérée comme une agrégation). Les programmes écrits selon ce paradigme sont automatiquement parallélisés et exécutés sur des grappes (ou des grilles). Le système d exécution sousjacent permet alors le parallélisme en partitionnant les données d entrée, l exécution se faisant sur les nœuds par traitements simultanés des partitions différentes. Ce système gère également la tolérance aux fautes et assure la communication entre nœuds. La figure 2 illustre l exécution globale du processus MapReduce, répartie sur plusieurs nœuds. (1) Le programme utilisateur fractionne les fichiers d entrée en morceaux M (le numéro M dépend de la taille de l entrée et la taille des segments). Le programme est ensuite exécuté sur une grappe de serveurs. (2) Un de ces serveurs joue un rôle particulier, celui de maître, consistant à assigner les tâches map et reduce sur les autres serveurs inactifs. Les morceaux sont ensuite traités par la fonction map définie par l utilisateur en parallèle par différents nœuds qui sont affectés à une tâche map. (3) Les résultats intermédiaires produits sont placés en mémoire tampon. (4) Périodiquement, ces résultats sont écrits sur le disque local, divisés en R régions par une fonction de partitionnement (par exemple une fonction de hachage). Le nombre de partitions et de la fonction de partitionnement sont spécifiés par

7 Entreposage et analyse en ligne dans les nuages avec Pig 147 l utilisateur. L emplacement de ces partitions est donné au nœud maître, qui transmet cette information aux nœuds en charge d une tâche de reduce. (5) Un nœud de type reduce utilise ensuite des appels de procédure à distance pour lire les résultats intermédiaires des disques des map. Lorsque tous ces résultats intermédiaires ont été lus, ils sont triés à l aide de leur clé intermédiaire, afin que les résultats obtenus ayant la même clé soient regroupés. (6) La fonction reduce itère sur les résultats intermédiaires et pour chaque clé intermédiaire rencontrée, passe la clé et l ensemble des valeurs intermédiaires associé à la fonction reduce définie par l utilisateur. La sortie de cette fonction est insérée dans un fichier de sortie final pour cette partition. Lorsque toutes les tâches map et reduce sont terminées, le nœud maître finalise le programme de l utilisateur. La sortie de l exécution de MapReduce est disponible dans les R fichiers de sortie. Figure 2. Exécution d une application via MapReduce La dernière couche offre un langage d interrogation de haut niveau. Une telle couche a pour objectif de proposer une certaine facilité d utilisation et une totale transparence des autres couches de l architecture, tout en permettant le parallélisme de l exécution. Différents langages d interrogation ont été proposés dans la littérature, tels que Hive de Facebook (Thusoo et al., 2009), Scope de Microsoft (Chaiken et al., 2008), Sawzall de Google (Pike et al., 2005) ou encore Map- Reduce-Merge (Yang et al., 2007), qui sont basés sur des modèles de données particuliers comme le modèle orienté colonne (Stonebraker et al., 2008) ou des modèles étendant le modèle relationnel (Olston et al., 2008). Dans cet article nous nous intéresserons au système Pig.

8 148 RSTI - ISI 16/2011. Qualité des entrepôts de données 2.4. Gestion de données avec Pig Le système Pig a été proposé pour offrir un compromis entre un langage déclaratif de type SQL et le style procédural bas niveau de MapReduce. L implémentation Pig se compose d un langage, Pig Latin, permettant l expression de requêtes d interrogation de données, suivant un modèle de données spécifique, et d un moteur d exécution, Pig Engine, permettant le déploiement sur des environnements parallèles. Le modèle de données Pig se compose de quatre types : atom, tuple, bag et map. Chacun de ces types est explicité à l aide de l exemple suivant. Exemple 1. Types de données Pig Atom: Bimonte Tuple:( Bimonte, Cemagref ) Bag:( Bimonte, Cemagref ) ( d Orazio,( LIMOS, UMR 6158 CNRS )) Map:[ author -> d Orazio affiliation -> ( CNRS ) ( Clermont-Université )] Un atom représente une valeur atomique telle qu un nombre ou une chaîne de caractères. Un tuple correspond à une séquence de champs, chacun d eux pouvant être de n importe quel type de données. Il est à noter que les tuples peuvent être imbriqués, comme l illustre l exemple choisi. Un bag est une collection de tuples. Une telle structure autorise la duplication et l hétérogénéité des tuples. Enfin, une map est une collection d éléments, où chaque élément est associé à une clé à l aide de laquelle il est accessible. Tout comme un bag, cette structure est flexible, les données pouvant être de différents types. Néanmoins, la clé doit dans tous les cas être un atom. Le langage Pig Latin propose des opérateurs de type SQL tels que la sélection, la projection, la jointure ou encore l union. Ces opérateurs peuvent également être complétés par des opérations plus spécifiques à l aide d UDF (User Defined Functions ou fonctions définies par l utilisateur) Motivations Conformément au principe de facturation à l utilisation, les utilisateurs ne paient que pour les ressources (cycle processeur, consommation de bande passante et stockage) qu ils utilisent. Par exemple, sur Microsoft Azure (Microsoft, 2010) le coût CPU pour une heure d exécution est 0,12 $, le stockage revient à 0,15 $ par Go et par mois, alors que la consommation de bande passante est facturée par Go 0,10 $ en chargement et 0,15 $ en téléchargement.

9 Entreposage et analyse en ligne dans les nuages avec Pig 149 Ces langages d interrogation de données sur nuages d une part, ne permettent qu indirectement la formulation de requêtes OLAP, puisqu aucun opérateur pour le calcul des totaux et sous-totaux (Gray et al., 1996) ad hoc n a été proposé, et, d autre part, aucun modèle de données associé ne fournit un stockage ad hoc pour les données multidimensionnelles. C est pourquoi notre travail vise à proposer une organisation spécifique des données multidimensionnelles pour les nuages informatiques afin de réduire les coûts de stockage et de calcul pour les requêtes OLAP en accord avec la contrainte des nuages informatiques de facturation à l utilisation. De plus, nous proposons une extension du langage Pig Latin avec les opérateurs CUBE, ROLLUP et RANK comme définis en SQL. Enfin, l analyse en ligne dans les nuages est un domaine de recherche vraiment nouveau. En effet, si d un côté l Université de Californie (Armbrust et al., 2009) a identifié des axes de recherches pour nuages (disponibilité et qualité de service, sécurité, etc.), de l autre côté, peu de travaux de recherche à notre connaissance ont exploré les différentes pistes de recherche pour l OLAP dans les nuages, et quelques produits commerciaux (GoodData, 2010 ; Pentaho, 2010) ayant fait leur apparition rapidement et récemment, ne fournissant que peu d informations à leur sujet. Dans cet article nous détaillons des perspectives portant sur les performances, la modélisation multidimensionnelle et l analyse en ligne sur les nuages. 3. Tableaux multidimensionnels dans les nuages et opérateurs OLAP Dans cette section, nous introduisons un aperçu du processus d interrogation de tableaux multidimensionnels sur nuages (section 3.1) et le stockage et le traitement des données plus en détails (section 3.2). Ensuite nous présentons une proposition d optimisation des requêtes multidimensionnelles avec l operateur GROUP de Pig Latin (section 3.3). Puis, en utilisant cet opérateur nous définissons au sein de Pig Latin les opérateurs CUBE, ROLLUP et RANK Processus d interrogation Le processus d interrogation, illustré par la figure 3 peut être décomposé en deux étapes : 1. les données sont stockées dans des fichiers textes sous forme de tableaux multidimensionnels. Ceci permet de réduire la taille des fichiers stockés et, par conséquent, le prix à payer par les clients. Quand une requête est posée, les tableaux sont transformés dans des fichiers temporaires en données suivant le modèle Pig, à l aide de l algorithme présenté en section 3.2. Ces fichiers peuvent ensuite être supprimés une fois l analyse terminée ; 2. les requêtes OLAP sont formulées et optimisées afin d aboutir à un plan d exécution performant d instructions en Pig Latin. Il est à noter que ces requêtes

10 150 RSTI - ISI 16/2011. Qualité des entrepôts de données peuvent être exécutées en parallèle, à l aide du paradigme MapReduce (cf. section 2.3), permettant d obtenir une certaine élasticité. Figure 3. Aperçu du processus d interrogation 3.2. Stockage et traitement des données Cette section présente comment les tableaux multidimensionnels peuvent être utilisés comme structure de stockage pour Pig. Les données sont stockées dans des tableaux multidimensionnels logiques, stockés physiquement sous forme de tableau unidimensionnel, à l aide de la formule présentée en section 2.2. L exemple suivant illustre les tableaux multidimensionnels utilisés dans notre cas d étude. Entrèes : Fichiers de tableaux Sortie : Fichier Pig int i 1; int n; file cartprodfile; {initialisé par le produit cartésien des deux dernières dimensions} file pigfile; file mafile; array dimensions; {ensemble des dimensions} tant que(i n-1) cartprodfile produitcartesien(dimensions[i],cartprodfile);

11 Entreposage et analyse en ligne dans les nuages avec Pig 151 i i + 1; fin tant que i 0; tant que(non fin de mafile) rolapfile (produitcartesien(dimension(n),cartprodfile )+, +mafile(i)) ; i i + 1 ; fin tant que retourner pigfile; Algorithme 1. Conversion de tableaux multidimensionnels en données Pig Exemple 2. Représentation des données avec tableaux multidimensionnels France,Auvergne,Puy-de-Dôme France,Auvergne,Allier... Italie,Campanie,Naples Par exemple, le premier fait, correspondant à la première ligne de la partie mesure, correspond aux valeurs mesurées associées au membre (première ligne pour la dimension temps) et France, Auvergne, Puy-de-Dôme (première ligne de la dimension spatiale). Quand une requête est posée, les données sont converties en des données Pig dans un fichier temporaire. Chaque ligne représente un n-uplet, les valeurs d un n-uplet étant séparées par des points virgules. La conversion des données considérées dans notre cas d étude est présentée par l exemple suivant. Exemple 3. Représentation des données avec Pig 2000;01;01;France;Auvergne;Puy-de-Dôme; ;01;01;France;Auvergne;Allier; ;04;20;Italie;Campanie;Naples;2500

12 152 RSTI - ISI 16/2011. Qualité des entrepôts de données La conversion des tableaux multidimensionnels en données Pig est faite via l algorithme 1. Les entrées de cet algorithme sont les fichiers stockant les tableaux des dimensions et les mesures (voir Exemple 2). La sortie correspond à un fichier représentant l entrepôt de données basé sur le modèle de données Pig (cf. Exemple 3). Le principe de cet algorithme est de construire le produit cartésien de n 1 dimensions. Un produit cartésien est alors réalisé entre ce résultat produit, la dimension n et les valeurs mesurées sont ajoutées pour générer les n-uplets de la manière suivante : le i-eme n-uplet avec la i-eme valeur du tableau. Quand le processus d analyse est terminé, le fichier temporaire est supprimé afin de réduire les coûts d utilisation de l infrastructure (le coût de cette transformation notamment en termes de cycles de calculs étant considéré comme inférieur au coût de stockage de la matérialisation des données dans le format Pig) Requêtes OLAP Une requête OLAP classique sur ces données est : «Quel est le profit total pour chaque région entre 2000 et 2001?». Une telle requête peut facilement être exprimée à l aide d instructions Pig Latin, comme l illustre l exemple 4. Ainsi, une requête OLAP en Pig se traduit en utilisant trois instructions. La première sélectionne les membres des dimensions (2000 et 2001 sur notre exemple). Une autre permet de regrouper les données (regroupement par année et région pour cet exemple), alors qu une dernière réalise la tâche d agrégation (une somme dans notre cas particulier). Exemple 4. Requête OLAP avec Pig Latin : FILTER et (GROUP, Agrégation) s0001 = FILTER sales BY years=2000 or years=2001 ; groups = GROUP s0001 BY year, region ; results = FOREACH groups GENERATE s0001.region, SUM(profit) ; Optimisation requêtes Contrairement à celles écrites en SQL pour lesquelles le système de gestion de bases de données choisit un plan d exécution à partir d éléments d optimisation, les requêtes en langage Pig Latin correspondent à un ensemble d instructions dont l ordre a un impact direct sur les performances de traitement de la demande. En effet, l implémentation de Pig dans sa version actuelle ne gère que deux optimisations : (1) un pipeline des séquences d enregistrements et (2) l utilisation des propriétés algébriques et distributives de certaines fonctions d agrégation (compte, somme, moyenne) ou de fonctions utilisateurs pour le calcul d agrégations partielles dès que possible. D autres optimisations à base de règles (Rule Based Optimizer ou RBO) ont été envisagées, permettant par exemple des opérations de type projection au plus tôt (Gates et al., 2009). Dans la même idée, nous avons proposé une optimisation simple mais efficace des requêtes OLAP en réécrivant les

13 Entreposage et analyse en ligne dans les nuages avec Pig 153 requêtes Pig. En effet, les requêtes exprimées dans le langage Pig Latin correspondent à un ensemble d instructions. Ainsi, les requêtes OLAP peuvent être formulées de deux manières différentes : (i) FILTER et (GROUP et Agrégation) (comme illustré par l exemple 4), (ii) (GROUP et Agrégation) et FILTER (comme illustré par l exemple 5). Evidemment, une telle séquence influe grandement sur les temps de réponse. Sur un tel exemple, si la taille de la source de données est très grande, agréger tous les résultats et ensuite sélectionner les membres des dimensions peut être très coûteux. C est pourquoi, une optimisation intuitive des requêtes OLAP en Pig Latin consiste à utiliser le patron d interrogation "FILTER, GROUPE, Agrégation". Exemple 5. Requête OLAP avec Pig Latin : (GROUP, Agrégation) et FILTER groups = GROUP sales BY year, region ; avgprof = FOREACH groups GENERATE sales.region, SUM(sales.profit) ; results = FILTER avgprof BY years=2000 or years=2001 ; Opérateur CUBE, ROLLUP et RANK en Pig Latin Pig Latin est disponible comme langage natif de Pig, mais aussi via une API java. Nous avons choisi d implémenter les opérateurs SQL CUBE, ROLLUP et RANK en étendant l API Java. Cela a permis de tester la faisabilité de notre approche et en même temps de faciliter le développement d applications OLAP avec Pig Latin. Il est important de souligner que les opérateurs CUBE, ROLLUP et RANK peuvent être considérés effectivement comme une extension de l algèbre de Pig Latin car ils reçoivent en entrée une relation Pig et fournissent en sortie une autre relation Pig. Nous avons défini une méthode pour chaque opérateur. Par souci de lisibilité, nous détaillons par la suite uniquement l opérateur CUBE et donnons seulement la signature des méthodes ROLLUP et RANK. La méthode cube est définie de la manière suivante : public static void cube(pigserver pigserver, String inputtable, String argum, String agregate, String result) Elle prend en entrée le chemin d accès des données, les n niveaux de dimensions choisis pour l agrégation, la fonction d agrégation, ainsi qu une référence vers le serveur (permettant généralement une exécution parallèle sur un centre de données) de traitement de requêtes. Elle produit ensuite en sortie l ensemble des n-uplets résultats. Un exemple d application de la méthode à l entrepôt de données (ventes) du cas d étude est présenté dans l exemple 6. Exemple 6. Opérateur Cube cube(pigserver,"ventes","year,country","sum(profit )","result");

14 154 RSTI - ISI 16/2011. Qualité des entrepôts de données Le résultat pour le cas d étude considéré est le même que celui présenté précédemment dans le tableau 2. La méthode génère, pour chaque total et sous-total, une relation Pig, avec les valeurs de colonnes associées aux dimensions qui doivent être utilisées pour l agrégation, grâce à l instruction FOREACH GENERATE,,. La valeur NULL du langage Pig Latin est utilisée comme substitut de la valeur ALL de l opérateur SQL CUBE. Elle évite de définir un niveau particulier pour le regroupement sur la dimension considérée et permet alors d agréger sur tous les membres de cette dimension. Les différentes agrégations sont ensuite réalisées pour chaque groupe via les instructions FOREACH GROUP BY et agregate. Ces combinaisons de valeurs sont ensuite rassemblées grâce à l opérateur UNION. Il est à noter que nous utilisons ici la possibilité offerte par le langage Pig Latin de référencer un attribut non pas par son nom (comme présenté précédemment), mais par sa position dans le n-uplet via l opérateur $ (par exemple l expression $0 permettant d accéder au premier attribut du n-uplet, $1 au deuxième et ainsi de suite). Une telle approche facilite la réutilisation du code pour différentes requêtes d agrégation et pour toutes les sources de données. Dans notre cas, les attributs listés seront ceux utilisés pour la création des groupes de données à la base des agrégations. L ensemble des requêtes Pig Latin générées par la méthode CUBE pour l exemple précédent est illustré par l exemple 7. Exemple 7. Requêtes Pig Latin générées par l operateur CUBE a = FOREACH ventes GENERATE null,null,profit; b = GROUP a BY ($0,$1); result = FOREACH b GENERATE group,sum(a.profit); a = FOREACH ventes GENERATE null,country,profit; b = GROUP a BY ($0,$1); c = FOREACH b GENERATE group,sum(a.profit); restemp = FOREACH result GENERATE *; result = UNION c, restemp; a = FOREACH ventes GENERATE year,null,profit; b = GROUP a BY ($0,$1); c = FOREACH b GENERATE group,sum(a.profit); restemp = FOREACH result GENERATE *; result = UNION c, restemp; a = FOREACH ventes GENERATE year,country,profit; b = GROUP a BY ($0,$1); c = FOREACH b GENERATE group,sum(a.profit); restemp = FOREACH result GENERATE *; result = UNION c, restemp;

15 Entreposage et analyse en ligne dans les nuages avec Pig 155 Les méthodes des opérateurs RANK et ROLLUP sont respectivement : public static void rank(string input,string args,string arggroup,string argordre, String Ordre, String output) public static void ROLLUP(PigServer pigserver, String inputfile, String argums, String aggregation, String result) 4. Validation Notre proposition a été validée à l aide d expérimentations. L objectif principal était d illustrer la réduction des coûts de stockage obtenue à l aide de notre approche, sans détériorer les performances, en particulier en termes de temps de réponse. Ces expérimentations visaient de plus à valider les opérateurs OLAP proposés. Les données simulées utilisées représentaient des mesures denses de ventes par régions et par années. La taille de ces données était modifiée en ajoutant ou retirant des mesures par années. Les expérimentations ont été réalisées avec la version de Pig sur deux types d architecture : une machine locale et une grappe virtuelle. La machine locale possède un processeur Intel Core 2 duo à 2,2 GHz et dispose de 4 Go de RAM. La grappe virtuelle est composée de 3 machines virtuelles, chaque machine disposant de 50 Go de disque dur, 2 Go RAM et 4 vcpu. Cette grappe virtuelle est déployée sur une architecture physique composée de deux bi-pro en cluster DRS de 8x2,493 GHz et 32 Go RAM, interconnectés par un réseau 1 Gb/s cuivre et d un bipro avec hyperthreading activé, en dehors du cluster DRS, possédant 16 cœurs logiques à GHz et 72 Go de RAM utilisant un réseau 1 Gb/s cuivre. La section 4.1 s intéresse au stockage, la section 4.2 à la conversion de données, alors que la section 4.3 étudie l impact de notre optimisation sur le temps de réponse, enfin, la section 4.4 présente les premières évaluations de performances des opérateurs OLAP que nous proposons Espace stockage La figure 4 présente la consommation d espace de stockage en Go en fonction du modèle de données, les modèles étudiés étant Pig et les tableaux multidimensionnels. Les résultats montrent très clairement que les tableaux multidimensionnels permettent une réduction drastique (environ 90 %) du volume de stockage nécessaire pour la gestion des sources de données denses. Nous pouvons ainsi conclure que notre système est moins coûteux en termes de stockage. Par exemple, avec la tarification de l infrastructure Amazon EC2 (0,15$ par Go et par

16 156 RSTI - ISI 16/2011. Qualité des entrepôts de données mois) et pour une source de données d un To basée sur le modèle de données relationnel, les coûts seraient d environ 1850 $ par an, alors qu avec notre approche, la facturation serait d environ 230 $. Figure 4. Consommation d espace de stockage 4.2. Conversion de données Figure 5. Conversion des données La figure 5 présente le temps de réponse moyen, sur machine locale, du processus de conversion de tableaux multidimensionnels en données représentées selon le modèle Pig en fonction de la taille de la source de données exprimée en nombre de n- uplets. Une telle expérimentation vise à illustrer les coûts supplémentaires, en particulier en utilisation processeur, induits par notre proposition. Les résultats

17 Entreposage et analyse en ligne dans les nuages avec Pig 157 montrent que l exécution d un tel processus est inférieure à une minute pour une source de données contenant jusqu à dix millions de n-uplets. Par conséquent, ce coût additionnel peut être considéré comme négligeable. En effet, avec la tarification de l infrastructure Amazon EC2 (0,12 $ par heure d utilisation d une instance standard), un tel processus coûterait au pro-rata temporis approximativement 0,001 $ pour une source de données contenant dix millions de n-uplets Optimisation de requêtes La figure 6 représente le temps de réponse moyen, donné en secondes, d une requête OLAP de type Agrégation puis sélection et d'une requête équivalente faisant la sélection d abord, en fonction de la sélectivité, donnée en pourcents, de l interrogation par rapport à la source de données. Les données considérées correspondent aux mesures denses des ventes entre 1991 et La taille de cette source est d environ n-uplets. La requête posée vise à récupérer la moyenne des ventes par région et par année pour une période de temps donnée. La sélectivité peut ainsi être formulée via l intervalle de temps étudié. Par exemple, les périodes , , et après 2011 correspondent respectivement à une sélectivité de 100 %, 50 % et 0 %. Figure 6. Influence de l ordre des instructions Pig sur les performances Les résultats, obtenus sur une machine locale, montrent clairement que l optimisation proposée accélère globalement le processus d évaluation (jusqu à 54 % en cas de forte sélectivité). Il convient néanmoins de noter que cette amélioration des performances diminue lorsque la sélectivité augmente. Notamment, lorsque toutes les données sont concernées par l agrégation, les performances des deux requêtes sont équivalentes.

18 158 RSTI - ISI 16/2011. Qualité des entrepôts de données 4.4. Opérateurs OLAP Les figures 7, 8 et 9 présentent le temps de réponse moyen, donné en secondes, en fonction de la taille de la source de données respectivement pour les opérateurs CUBE, ROLLUP et RANK. Les résultats, obtenus sur la grappe virtuelle, montrent clairement que le temps de réponse des opérateurs augmente linéairement lorsque le volume de données à analyser est de plus en plus important. Figure 7. Performances de l opérateur CUBE D autres mesures sont actuellement en cours sur des volumes de données plus grands, mais également pour étudier l impact du nombre de machines de la grappe sollicitées sur le temps de réponse moyen. L objectif de ces expérimentations est d étudier l élasticité des opérateurs. Figure 8. Performances de l opérateur ROLLUP

19 Entreposage et analyse en ligne dans les nuages avec Pig 159 Figure 9. Performances de l opérateur RANK 5. Perspectives de recherche Cette section dresse une liste de perspectives de recherche que nous considérons comme particulièrement cruciales à aborder afin de fournir des requêtes OLAP, des entrepôts de données performants sur nuages, ainsi que la possibilité d offrir la navigation dans des cubes de données volumineux. 1) Introduction d optimiseurs d exécution pour les requêtes OLAP (Kuznecov et al., 2009) écrites en Pig Latin (Olston et al., 2008). En effet, comme souligné dans l article, les performances des optimisations intégrées au sein de Pig restent trop limitées. Nous pensons que des fortes possibilités d amélioration sont possibles grâce à l adaptation des optimiseurs des SGDB classiques, tels que les optimisations basées sur des règles (Rule Based Optimizer ou RBO) ou des modèles de coût (cost based optimizer ou CBO), au modèle de données de Pig ou les techniques récentes d optimisation sur les scans partagés de fichiers (Agrawal et al., 2008). De tels optimiseurs pourraient alors être intégrés au niveau du client de manière transparente pour les utilisateurs, afin de respecter la propriété de facilité d utilisation des nuages informatiques. 2) Définition d algorithmes de sélection de vues matérialisées basés sur le modèle de facturation à l utilisation. Les vues matérialisées représentent une technique fondamentale pour l optimisation des requêtes OLAP. Plusieurs travaux ont été proposés pour la sélection «intelligente» des vues matérialisées à calculer (Aouiche et al., 2009). Ces approches ne tiennent pas compte du modèle de facturation à l utilisation. Nous pensons donc à définir des techniques de matérialisation, et de «dématérialisation» qui s adaptent aux changements des requêtes des utilisateurs et des coûts de stockage et calcul des fournisseurs des nuages.

20 160 RSTI - ISI 16/2011. Qualité des entrepôts de données 3) Implémentation d index pour les entrepôts de données en utilisant le paradigme MapReduce. Les index tels que bitmap sont utilisés dans les entrepôts de données pour optimiser les opérations coûteuses comme la jointure ou l agrégation (Kimball, 1996). Par conséquent, la parallélisation de ces index à travers le paradigme de MapReduce nous semble être pertinente afin d exploiter toute la puissance des nuages. Pour cela, nous considérons comme fondamentales l extension et/ou l adaptation de l implémentation de ces index dans les architectures OLAP distribuées (Gorawski et al., 2006) en prenant en compte le paradigme MapReduce (Konstantinou et al., 2010) et les particularités des architectures sur nuages : la facilité d utilisation et l élasticité. Enfin, comme pour les vues matérialisées ces index doivent respecter un modèle de coût prenant en compte la facturation à l utilisation. 4) Intégration de caches pour l amélioration de la qualité de service et la réduction des coûts d utilisation. L utilisation de cache est cruciale pour améliorer les performances de nombreux systèmes informatiques et plus particulièrement des systèmes décisionnels (Savary et al., 2007). Notre objectif est de proposer des techniques de caches sophistiquées et plus précisément des caches sémantiques (Keller et al., 1996), (Dar et al., 1996) afin d améliorer la qualité de service (réduction des temps de réponse et augmentation de la disponibilité) et de réduire les coûts. De tels mécanismes seraient utilisés pour copier les requêtes fréquemment posées (et ainsi économiser les cycles de calcul et la consommation de bande passante). Un premier travail dans ce sens est proposé par (Kim et al., 2010) qui définit un système de cache pour réduire le coût des entrées/sorties dans MapReduce. 5) Implantation des propriétés avancées de modélisation multidimensionnelle grâce à Pig. Les applications multidimensionnelles peuvent présenter des caractéristiques de modélisation avancées, comme les relations n-n entre faits et dimensions, les mesures complexes, etc. (Pedersen et al., 2001) qui sont difficiles à implémenter dans les SGBD relationnels (Malinowski et al., 2008). L exploitation de la puissance du modèle de données de Pig (en ce qui concerne les concepts de bag, map, requêtes imbriquées, etc. (cf. section 3.2)) pour la modélisation avancée des entrepôts de données reste une piste importante. Cela peut nous permettra de définir des patrons de modélisation basés sur les performances des requêtes OLAP, et donc de définir un cadre théorique (i.e. normalisation multidimensionnelle, modèle conceptuel, etc.) et d implémentation (i.e. index de jointure, etc.) pour les entrepôts de données et l analyse en ligne avec Pig et Pig Latin. 6) Définition des opérateurs SQL pour OLAP comme opérateurs de Pig Latin. En effet, une des caractéristiques les plus importantes des nuages est la facilité d utilisation. Comme illustré dans cet article, la définition des requêtes OLAP sur Pig Latin n est pas immédiate, nous pensons donc à étendre Pig Latin avec les agrégations pour les données numériques et complexes (spatiales, etc.). Cela nous permettra d introduire des fonctionnalités typiques du serveur OLAP directement dans le gestionnaire de données sur nuages en facilitant l utilisation et la définition des systèmes pour l analyse en ligne dans les nuages.