• Aucun résultat trouvé

Entreposage et analyse en ligne dans les nuages avec Pig

N/A
N/A
Protected

Academic year: 2022

Partager "Entreposage et analyse en ligne dans les nuages avec Pig"

Copied!
24
0
0

Texte intégral

(1)

RSTI - ISI – 16/2011. Qualité des entrepôts de données, pages 141 à 164

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-63172 Aubière cedex laurent.dorazio@isima.fr

** Cemagref, UR TSCF 24 Avenue des Landais F-63172 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: datawarehouses,OLAP, Cloud, Pig.

DOI:10.3166/ISI.16.6.141-164 © 2011 Lavoisier, Paris

(2)

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)

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.

2.1. 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

2010 1-2010 01-1-2010 France Auvergne Puy-de-Dôme 2000

2010 1-2010 01-1-2010 Italie Campanie Naples 3000

2009 1-2009 01-1-2009 France Auvergne Puy-de-Dôme 1800

2009 1-2009 01-1-2009 Italie Campanie Naples 3100

Tableau 1. Données des ventes

(4)

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, Nk les membres de la k-éme dimension, alors la position de la mesure dans un tableau à une dimension est :

p(i1,  ...,  id)  =  Πdj=1  (ij    *    Π  dk  =  j  +  1  Nk)  

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)

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 2000 2010 Italie 3000 2009 France 1800 2009 Italie 3100 All France 3800 All Italie 6100 2010 All 5000 2009 All 4900 All All 97000

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).

2.3. 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)

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 sous- jacent 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)

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)

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).

2.5. 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)

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.

3.1. 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)

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)

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 2000-01-01

2000-01-02 ...

2010-04-10

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 2000-01-01 (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;2000 2000;01;01;France;Auvergne;Allier;500

...

2010;04;20;Italie;Campanie;Naples;2500

(12)

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).

3.3. 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) ; 3.3.1. 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)

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 ; 3.3.2. 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)

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)

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 0.8.1 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 bi- pro avec hyperthreading activé, en dehors du cluster DRS, possédant 16 cœurs logiques à 2.526 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.

4.1. 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)

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)

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.

4.3. 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 2010. La taille de cette source est d’environ 700 000 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 1911-2010, 2001-2010, 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)

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)

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)

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.

(21)

7) ETL des données avec Pig Latin. Dans la construction des entrepôts de données, les outils ETL jouent en rôle fondamental car ils permettent l’intégration et l’uniformisation des différentes sources des données hétérogènes. Récemment, Thomsen et al. (2009) ont montré comment la définition du processus d’ETL est plus facile avec un langage de programmation. Nous proposons donc d’étendre Pig Latin avec des fonctionnalités des ETL pour les données structurées (numériques, spatiales, etc.), semi-structurées (XML, etc.), et non-structurées (texte, etc.) pour deux raisons : implémentation de MapReduce et approche procédurale.

6. Conclusions

Cet article présente un système d’entreposage et d’analyse de données sur nuages basé sur Pig. Tout d’abord nous avons proposé l’intégration des tableaux multidimensionnels dans Pig afin de réduire les coûts de stockage. En particulier, nous avons présenté un algorithme permettant de convertir les données stockées dans les tableaux multidimensionnels en données basées sur le modèle Pig. Nous avons ensuite proposé une optimisation simple et intuitive des requêtes OLAP en ordonnant les instructions Pig Latin. Des expérimentations en local sur des données simulées ont illustré la pertinence de nos solutions. Les résultats montrent en effet clairement que nos propositions permettent de réduire la consommation d’espace de stockage et ainsi de diminuer les coûts des utilisateurs de nuages, en utilisant un algorithme de conversion dont le coût est négligeable par rapport aux coûts de l’analyse décisionnelle. Elles illustrent également l’intérêt du réordonnancement des instructions. Nous avons ensuite proposé une extension du langage Pig en proposant au sein d’une API Java les opérateurs CUBE, ROLLUP et RANK. Finalement, nous avons listé des perspectives de recherche devant être considérées afin d’intégrer efficacement au sein des nuages informatiques les requêtes OLAP et des entrepôts de données. Actuellement, nous travaillons sur la parallélisation de la conversion à l’aide du paradigme MapReduce afin d’exploiter la puissance de calcul des infrastructures, ainsi que sur l’évaluation de performance de notre proposition sur des centres de données mis à disposition par les fournisseurs de nuages.

Remerciements

Merci à Boussad Mebarki, Ilyas Brahmia, Abdelaziz Merabet, Julien Bourgeois, Kenza Adanfari, Wiam Ben Mahmoud, Riad Bouchakour Errahmani, Hamid Kacem, Lu Xu, ainsi qu’aux membres du LIMOS et de l’équipe COPAIN du Cemagref pour les discussions sur la gestion à grande échelle de données spatiotemporelle sur grille.

(22)

7. Bibliographie

Amazon, Amazon EC2, 2010. http ://aws.amazon.com/ec2/

Agrawal P., Kifer D., Olston C., “Scheduling shared scans of large data files”, PVLDB, vol. 1, n° 1, 2008, p. 958-969.

Aouiche K., Darmont J., “Data mining-based materialized view and index selection in data warehouses”, Journal of Intelligent Information Systems, vol. 33, n° 1, 2009, p. 65-93.

Armbrust M., Fox A., Griffith R., Katz A. D. J. R. H., Konwinski A., Lee G., Patterson D. A., Rabkin A., Stoica I., Zaharia, M., Above the Clouds : A Berkeley View of Cloud Computing, Technical Report n° UCB/EECS-2009-28, Berkeley, 2009.

Chaiken R., Jenkins B., Larson P.-Å., Ramsey B., Shakib D., Weaver S., Zhou J., “SCOPE:

easy and efficient parallel processing of massive data sets”, PVLDB, vol. 1, n° 2, 2008, p. 1265-1276.

Chatziantoniou D., Tzortzakakis E., “ASSET queries: a declarative alternative to MapReduce”, SIGMOD Record, vol. 38, n° 2, 2009, p. 35-41.

Condie T., Conway N., Alvaro P., Hellerstein J., Gerth J., Talbot J., Elmeleegy K., Sears R.,

“Online aggregation and continuous query support in MapReduce”, SIGMOD Conference 2010, ACM Press, 2010, p. 1115-1118.

Dar S., Franklin M. J., Jonsson B. T., Srivastava D., Tan M., “Semantic Data Caching and Replacement”, Very Large Data Bases, 1996, p. 330-341.

Dean J., Ghemawat S., “MapReduce: simplified data processing on large clusters”, Communications of the ACM, vol. 51, n° 1, 2008, p. 107-113.

Gates A., Natkovich O., Chopra S., Kamath P., Narayanam S., Olston C., Reed B., Srinivasan S., Srivastava U., “Building a HighLevel Dataflow System on top of MapReduce: The Pig Experience”, PVLDB, vol. 2, n° 2, 2009, p. 1414-1425.

Ghemawat S., Gobioff H., Leung S.-T., “The Google file system”, ACM Symposium on Operating Systems Principles, Bolton Landing, USA, ACM Press, 2003, p. 29-43.

GoodData, GoodData, 2010. http ://www.gooddata.com/products/technology/cloud-bi-platform/

Gorawski M., Malczok R., “Materialized ar-tree in distributed spatial data warehouse, Intelligent Data Analysis”, IOS Press,vol. 10, n° 4, 2006, p. 361-377.

Gray J., Bosworth A., Layman A., Pirahesh H., “Data Cube : A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Total”, International Conference on Data Engineering, New Orleans, USA, IEEE, 1996, p. 152-159.

Inmon W.H., Building the Data Warehouse, Wiley, New York, 1996.

Keller A. M., Basu J., “A predicate-based caching scheme for client-server database architectures”, The Very Large Data Bases Journal, vol. 5, n° 1, 1996, p. 35-47.

Kim S., Han H., Jung H., Eom H., Yeom H., “Harnessing input redundancy in a MapReduce framework”, SAC 2010, ACM Press, 2010, p. 362-366.

(23)

Kimball R., The data warehouse toolkit: practical techniques for building dimensional data warehouses, John Wiley & Sons, Inc, 1996.

Konstantinou K., Angelou E., Tsoumakos D., Koziris N., “Distributed Indexing of Web Scale Datasets for the Cloud”, International Workshop on Massive Data Analytics over the Cloud Raleigh, ACM Press, 2010.

Kuznecov S., Kudryavcev Y. “Applying map-reduce paradigm for parallel closed cube computation”, International Conference on Advances in Databases, Knowledge, and Data Applications, IEEE, 2009, p. 62 - 67

Lin J., Dyer C., Data-Intensive Text Processing with MapReduce, Morgan & Claypool Publishers, 2010.

Mahboubi H., Darmont J., “Enhancing XML data warehouse query performance by fragmentation”, ACM Symposium on Applied Computing, Honolulu, USA, New York, ACM Press, 2009, p. 1555-1562.

Malinowski E., Zimnyi E., Advanced Data Warehouse Design : From Conventional to Spatial and Temporal Applications (Data-Centric Systems and Applications), Springer, 2008.

Mdx, 2010. http://msdn2.microsoft.com/en-us/library/ms145595.aspx

Microsoft, 2010. Microsoft Azure. Web, http ://www.microsoft.com/windowsazure/

Olston C., Reed B., Srivastava U., Kumar R., Tomkins A., “Pig latin : a not-so-foreign language for data processing”, ACM SIGMOD International Conference on Management of Data, ACM Press, 2008, p. 1099-1110.

Ordonez C., Song I., “Relational versus Non-Relational Database Systems for Data Warehousing”, ACM DOLAP Workshop, New York, ACM Press, 2010.

Pedersen T. B., Jensen C. S., Dyreson C. E., “A foundation for capturing and querying complex multidimensional data”, Information Systems, vol. 26, n° 5, 2001, p. 383-423.

Pentaho, 2010. http ://www.pentaho.com/cloud_bi/

Pike R., Dorward S., Griesemer R., Quinlan S., “Interpreting the data: Parallel analysis with Sawzall”, Scientific Programming, vol. 13, n° 4, 2005, p. 277-298.

Rafanelli M., “Operators for Multidimensional Aggregate Data”, Multidimensional Databases: problems and solutions, Idea Group, 2003, p. 116-165.

Ravindra P., Deshpande V., Anyanwu K., “Towards Scalable RDF Graph Analytics on MapReduce”, International Workshop on Massive Data Analytics over the Cloud, Raleigh, ACM Press, 2010, p. 1-6.

Savary L., Gardarin G., Zeitouni K., “GeoCache : A Cache for GML Geographical Data”, IJDWM, vol. 3, n° 1, 2007, p. 67-88.

Sridhar R., Ravindra P., Anyanwu K., “RAPID: Enabling Scalable Ad-Hoc Analytics on the Semantic Web”, International Semantic Web Conference 2009, Springer-Verlag, 2009, p. 715-730.

(24)

Stonebraker M., Abadi D. J., Batkin A., Chen X., Cherniack M., Ferreira M., Lau E., Lin A., Madden S., O’Neil E. J., O’Neil P. E., Rasin A., Tran N., Zdonik S. B., C-Store: A Column-oriented DBMS, Very Large Data Bases, 2008, p. 553-564.

Stupar A., Michel S., Schenkel R., “RankReduce – Processing K-Nearest Neighbor Queries on Top of MapReduce”, Large-Scale Distributed Systems for Information Retrieval, 2010.

Thomsen C., Pedersen T.B., “pygrametl: a powerful programming framework for extract- transform-load programmers”, DOLAP 2009, ACM Press, 2009, p. 49-56.

Thusoo A., Sarma J. S., Jain N., Shao Z., Chakka P., Anthony S., Liu H., Wyckoff P., Murthy R., “Hive - A Warehousing Solution Over a Map-Reduce Framework”, PVLDB, vol. 2, n° 2, 2009, p. 1626-1629.

Yang H., Dasdan A., Hsiao R.-L., Parker D. S., “Map-reduce-merge: simplified relational data processing on large clusters”, International Conference on Management of Data, Beijing, China, ACM Press, 2007, p. 1029-1040.

Zhang S., Han J., Liu Z., Wang K., Feng S., “Spatial Queries Evaluation with MapReduce”, International Conference on Grid and Cooperative Computing, IEEE, Washington, DC, USA, 2009, p. 287-292.

Zhao Y., Deshpande P., Naughton J. F., “An Array-Based Algorithm for Simultaneous Multidimensional Aggregates”, International Conference on Management of Data, Tucson, USA, New York, ACM Press, 1997, p. 159-170.

Références

Documents relatifs

[r]

In this study, we investigated the impact of small-scale snowmelt patterns on phenological differentiation, genetic diversity and gene flow in the common long-lived arctic-alpine

L'égalité, c'est traiter tout le monde de la même manière, garantir à tous les mêmes droits et les mêmes devoirs, quelles que soient les origines... Apprendre la définition

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre

Soit le potentiel vecteur, dont seule la composante A φ (en coordonnées sphériques)

La musique est l'art consistant à arranger et ordonner sons et silences au cours du temps parfois dans l'espace (le musicien est sur scène ou dans le public) selon 4 critères :.. 

activer une coordination active avec les élus dans les instances accéder aux nouveaux lieux de pouvoir. • Relancer l’activité des

Le populisme est défini (p. 6) comme une idéologie mince (thin ideology) qui considère que la société est séparée entre deux camps à la fois homogènes et