See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/322930759

Répartition d'un Big Data Warehouse Via l'algorithme BEA

Article  in  Techniques et Sciences Informatiques · January 2018

CITATIONS READS

0 415

3 authors:

Mourad Ghorbel Karima Tekaya

University of Tunis El Manar ESSEC - Ecole Supérieur des Sciences Economiques et Commerciales
6 PUBLICATIONS   7 CITATIONS    8 PUBLICATIONS   14 CITATIONS   

SEE PROFILE SEE PROFILE

Abdelaziz Abdellatif
University of Tunis El Manar
60 PUBLICATIONS   451 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Data warehouse design, implementation and optimization View project

Multidatabase interoparbility View project

All content following this page was uploaded by Mourad Ghorbel on 05 February 2018.

The user has requested enhancement of the downloaded file.

Répartition d’un Big Data Warehouse Via
l’algorithme BEA
Répartition d’un Big Data Warehouse Via BEA

Mourad Ghorbel1, Karima Tekaya2, Abdelaziz Abdellatif3

1. LIMTIC, Université de Tunis El Manar
Faculté des Sciences de Tunis, El Manar 2092, Tunisie
ghorbel.fst@gmail.com
2. Université de Tunis
Ecole Supérieure des Sciences Economiques et Commerciales de Tunis,
Montfleury 1089, Tunisie
Karima.tekaya@gmail.com
3. LIPAH, Université de Tunis El Manar
Faculté des Sciences de Tunis, El Manar 2092, Tunisie
abdelaziz.abdellatif@fst.rnu.tn

RÉSUMÉ. Dans le domaine des entrepôts de données (ED), la plupart des approches de
répartition se basent essentiellement sur les techniques de fragmentation et d’allocation des
tables. Ces approches exploitent communément en entrée les prédicats extraits des requêtes
les plus utilisées dans le processus de partitionnement. Etant donné que la charge
d’informations s’accroît sans cesse dans n’importe quelle société, et vu l’impact négatif
qu’engendre l’augmentation des besoins des utilisateurs de cet entrepôt, il devient intéressant
de le répartir. Dans cet article, nous proposons une solution basée sur un algorithme de Bond
Energy Algorithm (BEA) permettant de classifier les prédicats pour les approches de
répartition des Big Data Warehouse. La solution proposée englobe quatre phases: une phase
d’utilisation des prédicats, une phase de codification des prédicats sous forme de matrices
binaires, une phase de classification de ces prédicats par l’algorithme BEA et une phase
finale pour la répartition. Nous avons validé notre solution sur un Big Data Warehouse réel
issu du benchmark Transaction Processing Performance Council (TPC-DS).
ABSTRACT. In the field of Data Warehousing (DW), most distribution approaches rely mainly
on fragmentation and allocation techniques. These approaches commonly use as input the
predicates extracted from the queries most used in the partitioning process. Since the
information burden is constantly increasing in any company, and given the negative impact of
the increased needs of the users of this warehouse, it becomes interesting to distribute it. In
this article, we propose a solution based on a Bond Energy Algorithm (BEA) algorithm to
classify predicates for Big Data Warehouse distribution approaches. The proposed solution
encompasses four phases: a phase of use of the predicates, a predicate coding phase in the

Nom entier de la revue – n° 1/2012, 1-5 AR_pied-page1

2 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

form of binary matrices, a phase of classification of these predicates by the BEA algorithm
and a final phase for the distribution. We validated our solution on a real Big Data
Warehouse from the Transaction Processing Performance Council (TPC-DS) benchmark.
MOTS-CLÉS : ED, BEA, Big Data Warehouse, répartition

KEYWORDS: DW, BEA, Big Data Warehouse, distribution

DOI:10.3199/JESA.45.1-n © Lavoisier 2012 AR_DOI

1. Introduction

Face à la mondialisation et à la concurrence grandissante, la prise de

décision est devenue cruciale pour les dirigeants d’entreprises (au sens large du
terme, entreprises privées, publiques, institutions, organisations...). L’efficacité de
cette prise de décision repose sur la mise à disposition d’informations pertinentes et
d’outils d’analyse adaptés. L’objectif des entreprises est de pouvoir exploiter
efficacement d’importants volumes d’informations, provenant soit de leurs systèmes
opérationnels, soit de leur environnement extérieur, pour l’aide à la décision.

L’informatique décisionnelle a connu et connaît aujourd’hui encore un essor

important. Elle permet l’exploitation des données d’une organisation dans le but de
faciliter la prise de décision. A l’heure actuelle, la majorité des gros entrepôts de
données (ED) souffrent de problèmes de performance causant des problèmes aux
usagers, les administrateurs et les développeurs du data Warehouse (DW). Il n’y a
pas de recettes magiques qui résolvent en un seul coup tous ces problèmes. Il faut
quasiment les étudier un par un. Par contre, ils sont pratiquement communs à des ED
différents. Ils ne s’appliquent pas à un domaine bien spécifique.

Ces charges de travail volumineuses peuvent dégrader les performances du

système de gestion des bases de données (SGBD), et ainsi, ralentir les applications
et augmenter ainsi le temps de réponse au client, souvent exigeant dans les délais, en
particulier lorsqu’il s’agit d’un décideur.
Pour y remédier, diverses techniques d’optimisation ont été proposées, entre autres
la fragmentation horizontale. La sélection d’un schéma de fragmentation horizontale
(FH) est un problème NP-complet (Boukhalfa, 2009). Des algorithmes heuristiques
ont été proposés afin de définir automatiquement le meilleur schéma de
fragmentation.

La répartition des bases de données (BD) classiques se base sur la

fragmentation (généralement horizontale) et l’allocation de ces fragments.
Cependant, cette technique nécessite une adaptation aux aspects fondamentaux des
ED. Faisant face aux contraintes de chargement et aux spécificités de la
modélisation multidimensionnelle, leur application demeure inadéquate. Malgré
l’insuffisance de ces techniques, elles nécessitent une réévaluation dans le contexte
réparti.
 Répartition d’un Big Data Warehouse Via BEA 3

En effet, très peu de travaux ont considéré le problème de la répartition des ED.
Malgré son importance, nous considérons que la répartition des ED n’a pas eu
l’attention qu’elle mérite.

Le Big Data couvre trois dimensions : volume, vitesse et variété.

Volume : les entreprises sont submergées de volumes de données croissants de tous
types, qui se comptent en téraoctets, voir en pétaoctets.
Vitesse : parfois, 2 minutes c'est trop. Pour les processus chrono sensibles tels que la
détection de fraudes, le Big Data doit être utilisé au fil de l'eau, à mesure que les
données sont collectées par votre entreprise afin d'en tirer le maximum de valeur.
Variété : le Big Data se présente sous la forme de données structurées ou non
structurées (texte, données de capteurs, son, vidéo, données sur le parcours, fichiers
journaux, etc.). De nouvelles connaissances sont issues de l’analyse collective de ces
données.

Outre l'introduction et la conclusion, le présent article comporte trois sections:

dans la première section, nous présentons un tour d'horizon sur l’état de l’art
comportant une variété de travaux reliés à la fragmentation des ED. Dans la
deuxième section, nous décrivons les différentes phases de notre approche de
répartition du Big Data Warehouse par le Bond Energy Algorithm (BEA). Dans la
troisième section, notre approche est concrétisée à travers son application sur un Big
Data Warehouse réel issu du benchmark TPC-DS (Pilho, 2014).

2. Etat de l’art

Les vertus de la fragmentation dans les ED ont été prouvées durant la

dernière décennie. En favorisant un accès plus rapide aux données pertinentes et un
maximum de parallélisme intra-requête, elle permet de réduire le temps d'exécution
des requêtes OLAP (On-Line Analysis Process). Combinée avec d’autres techniques
d’optimisation (index, vues matérialisées, etc.), son utilisation est devenue une
solution souvent adoptée dans le domaine des systèmes d’information décisionnels
(SID). Plusieurs solutions ont été proposées pour la fragmentation des ED
relationnels. Ces techniques exploitent communément la liste des prédicats comme
base de travail.
Dans ce qui suit, nous présentons un tour d’horizon sur les approches de
fragmentation les plus connues dans l'état de l'art et nous montrons que la plupart
des solutions s’orientent vers la technique de fragmentation sans tenir compte de
l'impact de l'évolution des données sur l’efficacité de la solution.

(Nehme et Valduriez, 2011) ont défini une technique de Branch and Bound
pour l’exécution des requêtes parallèles. C’est une stratégie de partitionnement de
données qui minimise le coût coûteux des transferts de données. Cette solution
présente comme avantage de trouver le meilleur partitionnement dans des
environnements distribués mais reste le délai d’attente pour l’optimiseur qui
présente le seul inconvénient. (Bouchakri et Bellatreche, 2012) ont proposé
d’effectuer une sélection d’un schéma de fragmentation dite incrémentale basée sur
4 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

les algorithmes génétiques et permettre l’optimisation de l’exécution de la charge de

requêtes décisionnelles et l’adaptation du schéma de fragmentation aux changements
de la charge. Cette solution présente l’avantage de prendre en considération les
changements au niveau des requêtes mais cela entraîne l’augmentation du temps de
mise à jour. (Barr, 2013) a résolu un problème de la sélection de la FH tout en
considérant à la fois le nombre de I / O entre la mémoire et le disque. Il a pris les
requêtes décisionnelles et le nombre de fragments, comme deux fonctions objectives
à minimiser. Cette solution a permis la réduction du temps de réponse lors de la
manipulation des requêtes et la réduction des fragments. Cependant ce travail peut
être élargi pour prendre en charge d’autres préférences de l’administrateur.
(Elmansouri et al., 2013) ont défini une nouvelle technique (ACP) pour la
fragmentation des ED. C’est une technique de description et de réduction des
données. Elle comporte une série de décisions critiques portant sur les propriétés des
variables soumises à l’analyse, les propriétés de la matrice d’intercorrélation et le
nombre de composantes à extraire. Cette solution a comme avantage de mettre en
évidence les fragments horizontaux supplémentaires mais cette solution n’est pas
encore testé sur ED. (Ettaoufik et al., 2013) proposent une approche de FH des ED
en se basant sur la technologie des services web. C’est un service qui est décrit
comme un ensemble de fonctionnalités accomplissant des tâches spécifiques,
accessible par un réseau informatique. Le Web Service est un composant logiciel
identifié par une URL. Il s’agit donc d’un ensemble de fonctionnalités exposées sur
internet ou sur un intranet, par et pour des applications ou machines, sans
intervention humaine, et en temps réel. Leur travail présente une amélioration des
ED au niveau des fragmentations mais reste à ajouter d’autre préférence pour
l’administrateur. (Boufares et al., 2012), dans leur travail, assurent une meilleure
qualité pour les données résultantes. Ils proposent un algorithme séquentiel pour
l’élimination des données similaires. Actuellement, un grand nombre d’applications
utilisent des données hétérogènes et distribuées de qualité variable. Le besoin
d’intégration de données et d’évaluation de la qualité des données se fait de plus en
plus ressentir. De nouvelles méthodes de calculs de distance de similarité pour
des types de données complexes sont à développer ainsi que l’automatisation du
choix entre elles. (Kerkad et al., 2012) proposent d’étudier conjointement le
problème de gestion de tampon (BMP) et le problème d’ordonnancement de
requêtes (QSP). Les SGBD manipulant des bases de données volumineuses comme
les ED stockent souvent les données sur le disque. En conséquence, l’interrogation
nécessite un transfert des données du disque vers
la mémoire centrale via le tampon. Un nombre important de travaux sur la gestion
de tampon ont été proposés. Malheureusement, ils supposent que les requêtes soient
ordonnées. Dans le contexte des ED, les requêtes interagissent du fait qu’elles
utilisent la table des faits. Cette interaction pourrait impacter la gestion de cache et
offrir un bon ordonnancement de requêtes. (Perriot et al., 2013) proposent de
nouveaux modèles de coût intégrant le paiement à la demande en vigueur dans les
nuages. Ils définissent un problème d’optimisation consistant à sélectionner, parmi
des vues candidates, celles à matérialiser pour minimiser le coût d’interrogation
et de maintenance, ainsi que le temps de réponse pour une charge de requêtes
donnée. Leur but est d’optimiser les deux critères séparément: le temps est optimisé
 Répartition d’un Big Data Warehouse Via BEA 5

sous contrainte de coût et vice versa. La performance des ED est classiquement

assurée grâce à des structures comme les index ou les vues matérialisées. Dans ce
contexte, des modèles de coût permettent de sélectionner un ensemble pertinent de
ce type de structures. Toutefois, cette sélection devient plus complexe dans les
nuages informatiques. (Favre, 2007), dans sa thèse, présente une solution à la
personnalisation des analyses dans les ED. Cette solution se base sur une évolution
du schéma de l’entrepôt guidée par les utilisateurs. Il s’agit en effet de recueillir les
connaissances de l’utilisateur et de les intégrer dans l’ED afin de créer de nouveaux
axes d’analyse. Cette solution présente comme avantage une évaluation de la
performance du modèle proposé mais présente aussi des inconvénients lors
des mises à jour, maintenance…
(Kerkad et al., 2013) ont proposé une optimisation dans RDW (datawarehouse
relationnelle) par HDP (Horizontal Data Partitioning) en considérant l’interaction de
la requête. Ils réalisent un codage incrémental pour représenter les schémas de
fragmentation et utilisent des prédicats d’élagage et de direction HDP par des
requêtes élus. La principale caractéristique des requêtes définies sur un ED
relationnel est le fait que leurs jointures passent systématiquement par la table des
faits. (Dehdouh et al., 2013), démontrent que la construction d’un cube OLAP est
plus performante lorsque l’ED est stocké en colonnes que lorsqu’il est stocké en
lignes. Cependant, en absence d’opérateurs d’analyse en ligne, le seul moyen, très
coûteux, qui existe pour construire des cubes OLAP consiste à utiliser l’opérateur
UNION sur des requêtes de regroupement afin d’obtenir l’ensemble des Group By
nécessaires au calcul de cube OLAP.
(Bentayeb et Rakotoarivelo, 2007) proposent un nouvel opérateur qui permet
d’ajouter de nouveaux niveaux d’analyse intéressants dans la hiérarchie d’une
dimension dans le but d’augmenter le périmètre d’analyse avec de nouveaux axes
permettant de détecter rapidement des similarités et des tendances dans les données
entreposées. Cette intégration montre l’intérêt de combiner la fouille de données et
l’analyse multidimensionnelle pour améliorer l’évolutivité des ED. Ainsi, ils
envisagent d’exploiter des méthodes d’apprentissage supervisé pour construire des
règles d’analyse sur l’entrepôt ou pour générer des faits prévisionnels à intégrer dans
l’entrepôt. (Attasena et al., 2013) ont proposé une analyse des performances qui
montre qu’elle peut prévenir les intrusions, garantir la disponibilité des données et
leur intégrité, pour un coût réduit (stockage, transfert de données et temps de calcul)
dans le paradigme économique de paiement à la demande des nuages informatiques.
L’informatique dans le nuage peut contribuer à réduire les coûts et à augmenter la
flexibilité en permettant aux entreprises de déployer leurs applications et leurs ED.
L’avantage de cette solution est la résolution à la fois des problèmes de sécurité et
d’analyse des données. Cependant, le stockage et la gestion des données dans le
nuage posent des problèmes de sécurité. (Ouazzani et al., 2014) ont proposé dans
leur perspective un ED liées à l’environnement cloud. Ils ont proposé une solution
sur le contrôle d’accès aux ED qui a comme avantage de fonctionner d’une manière
indépendante de la plate-forme cible. Mais cette solution présente comme
inconvénient l’exigence d’un ED déjà mis en place avant.
6 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

D’autre part, nous considérons la méthode de classification par l’algorithme

k-means et BEA comme étant une méthode originale pour la fragmentation. Elle
permet de contrôler à l’avance le nombre de fragments et d’intégrer les
caractéristiques de la base et de l’utilisation des données sous un format quantitatif
dans des matrices simples à utiliser. Nous présentons dans ce qui suit, cinq travaux
utilisant la classification comme technique de fragmentation.
(Mahboubi, 2008) a proposé une solution pour la FH des ED XML afin de les
répartir sur une grille. Il a exploité l’algorithme k-means. Sa solution englobe trois
étapes : (1) codage des prédicats de sélection d’un ensemble de requêtes dans une
matrice binaire qui représente le contexte de classification. Ensuite, (2) classification
des prédicats par application de la technique des k-means qui permet de partitionner
l’ensemble des prédicats en k classes disjointes et enfin, (3) construction des
fragments. La solution proposée permet de contrôler le nombre de partitions en
fixant la valeur de k, mais ne tient pas compte de l'évolution du nombre de prédicats
et de son impact sur l’efficacité de l'ED.
Dans le même contexte, (Tekaya et al. 2012) a défini deux nouvelles notions : la
corrélation sémantique et la corrélation géographique. La corrélation sémantique
permet de fusionner par conjonction de deux prédicats inclus dans la même clause
WHERE. Une corrélation géographique est la fusion de deux prédicats
n’appartenant pas à la même requête mais sont utilisés par la même localisation
géographique. Une localisation géographique désigne le (ou les) site(s) sur lesquels
sont alloués les Magasins de Données (MD). La solution proposée intègre l’aspect
géographique dans le processus de fragmentation. Elle englobe quatre phases : (1)
détermination d’une liste de prédicats simples, (2) création de la matrice corrélation,
(3) application de l’algorithme k-means pour la classification des prédicats et (4)
génération des fragments horizontaux. Le travail proposé par (Tekaya et al. 2010)
tient compte de la réduction du nombre de prédicats par une simple application de
l'algorithme COMM_MIN (Ozsu et Valduriez, 1999). Cependant, aucune technique
spécifique n'a été proposée. Nous avons encore minimisé le nombre de prédicats
dans (Ghorbel et al. 2016).
Pour partitionner verticalement une BD, l'idée de base a été proposée par (Hoffer et
Severance, 1975) qui ont créé la notion "d'affinité des attributs" comme critère de
fragmentation. Deux attributs ont une forte affinité lorsqu'ils sont fréquemment
utilisés ensemble par les transactions. Les attributs sont ensuite regroupés selon leurs
affinités en utilisant l’algorithme BEA qui fourni en sortie des classes d'attributs.
Ces classes seront par la suite, utilisées pour générer des fragments verticaux. Sur la
base de ce principe, plusieurs travaux ont été proposés dans la littérature pour le
perfectionnement de la fragmentation verticale (FV) des BD. (Navathe et al., 1984 )
ont proposé une amélioration du travail précédent. Ils ont commencé par
l'application du BEA dans trois contextes différents et par étape. Ils l'ont
implémenté, tout d'abord, sur une BD stockée sur des périphériques d'un type
unique, ensuite, sur une BD stockée dans différents niveaux de la mémoire et enfin,
sur une BD distribuée. Comme critère de fragmentation, les auteurs utilisent la
notion d'affinité entre les attributs. L'affinité est calculée en fonction du nombre
d'accès aux disques. Ensuite, (Navathe et Ra, 1989) ont proposé un "algorithme
graphique" pour la FV.
 Répartition d’un Big Data Warehouse Via BEA 7

La diversité des solutions proposées pour la fragmentation des ED montre son

importance. Cependant, l’efficacité de ces solutions doit évoluer au niveau des Big
Data Warehouse. D’autre part, le choix d’une solution répartie doit être, tout
d’abord, approuvé par des mesures d’efficacité. Cependant, l’évaluation des
solutions de partitionnement et/ou de répartition dans les ED n’a pas été très
sollicitée par les chercheurs. En effet, l’augmentation cruciale du flux de données
nous dirige forcement vers la répartition d’un Big Data Warehouse. Malgré l’intérêt
accordé aux techniques de fragmentation des données et la diversité des solutions
proposées, nous avons constaté que ce problème n’a pas eu l’attention qu’il mérite
en dépit de son importance. Dans ce qui suit, nous allons travailler sur un Big Data
Warehouse en couvrant deux dimensions d'un Big Data qui sont le Volume et la
Vitesse. Les données dans notre exemple sont structurées. On touchera la Variété
dans nos prochains travaux.
Les solutions existantes de fragmentation et de répartition des ED ont été étudiées
récemment. La plupart de ces solutions se limite sur les ED centralisés. Elles
prennent en considération la diminution du temps d'exécution des différentes
requêtes spécifiques et du nombre de prédicats ainsi qu'au nombre de fragments,
mais elles se bloquent par une grande complexité face au nombre de prédicats et par
le non contrôle du nombre de fragments générés qui peut dans certains cas
s'accroître. C'est pour cela la répartition des Big Data Warehouse devient une
nécessité vue le nombre des données et l'augmentation des besoins des utilisateurs.
Nous considérons la méthode de classification par l’algorithme BEA comme étant
une méthode originale pour la fragmentation. Elle permet de contrôler à l’avance le
nombre de fragments et d’intégrer les caractéristiques de la base et de l’utilisation
des données sous un format quantitatif dans des matrices simples à utiliser. Nous
nous sommes inspirés du travail réalisé par (Mahboubi, 2008) pour la conversion
des prédicats et du travail réalisé par (Tekaya, 2012) au niveau des fréquences
d’utilisation des prédicats. Ces solutions seront étendues pour résoudre ce problème
dans un contexte de Big Data Warehouse.

3. Solution proposée

Dans notre travail, nous nous sommes concentrés sur la liste initiale des
requêtes. Cette liste constitue un point d'entrée commun aux solutions de répartition
les plus connues dans l'état de l'art. Nous considérons l’augmentation des données
comme étant un problème important qu'il faut traiter par répartition. En effet, les
prédicats sont extraits à partir des requêtes les plus fréquentes dans le SID. Dans ce
qui suit, nous proposons une solution pour la répartition d’un Big Data Warehouse
suivant l’algorithme BEA. Son but est de minimiser le temps de réponse des
requêtes utilisées et le coût de chargement des données.
La solution proposée se déroule en quatre phases :
- phase d’utilisation des prédicats ;
- phase de codification ;
- phase de classification ;
- phase de répartition;
8 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

3.1. Phase d’utilisation des prédicats

P1 P2 ... P m

R1 1 1 0 0
R2 1 0 0 1
..Ru 0 1 1 0
Figure 1. MUP (Mahboubi, 2008)

Dans cette première phase, nous nous sommes inspirés du travail réalisé par
(Mahboubi, 2008) pour la conversion des prédicats en codes binaires. Il a utilisé une
Matrice d’Utilisation des Prédicats (MUP) qui englobe les utilisations des prédicats
par les requêtes. Dans la figure 1, les colonnes de la MUP englobent les prédicats les
plus utilisés. Les lignes désignent les requêtes OLAP les plus fréquentes sur le
système. Une cellule de la MUP englobe la valeur 1 si une requête donnée utilise un
prédicat donné et la valeur 0, sinon.
La phase d’utilisation des prédicats permet de produire une représentation binaire
des prédicats selon leurs utilisations par les requêtes.

3.2. Phase de codification

Dans cette deuxième phase, nous nous sommes inspirés du travail réalisé par
(Tekaya, 2012). Elle a utilisé une Matrice des Fréquences d’Utilisation (MFU) qui
englobe les fréquences d'utilisation des requêtes sur les différents sites de
l'entreprise. Elle a la même structure que la MUP. Une cellule de la MFU inclut la
fréquence d'utilisation d'une requête donnée par les utilisateurs d'un site donné.
Ci-dessous, nous présentons un exemple de la MFU en figure 2.

S1 S2 ... Sk

R1 20 1 0 0

R2 19 0 0 1
..R u 0 15 12 0

Figure 2. MFU (Tekaya, 2012)

La MFU constitue notre point d’entrée à la phase de classification des

prédicats.
 Répartition d’un Big Data Warehouse Via BEA 9

3.3. Phase de classification

Cette phase est composée de deux étapes:

La première étape est la réalisation de la Matrice d’Affinité (MA). La deuxième

étape génère la Matrice de Classification des Affinités (MCA).

3.3.1. MA

Dans cette troisième phase, nous utilisons la MUP et la MFU comme entrée
de la phase de classification (dans la partie pratique).
Nous aurons comme résultat la MA sur la figure 3.

P1 P2 ... Pk

P1 15 18 0 0
p2 16 0 0 1
..P u 10 30 1 0

Figure 3. MA

Pour chaque requête qui accède à la paire de prédicats, on somme la fréquence

d’accès à tous les sites. On aura ainsi notre matrice d’affinité.
Une cellule de la MA correspond à la somme de fréquence d’accès pour un couple
de prédicats.

3.3.2. MCA

A partir de la matrice d’affinité, on veut définir des classes de prédicats.

L’algorithme BEA possède les propriétés suivantes:
- On regroupe les ensembles de valeurs ayant une affinité élevée ;
- Ainsi que celles ayant une affinité faible ;
- Le regroupement final est indépendant de l’ordre des entrées ;
- Temps de traitement raisonnable: Ο(n²) – n avec n le nombre d’attributs.
Ci-dessous une description de l’algorithme BEA :

Algorithme 1. Algorithme BEA(Ozsu 1999)

1: generateurRepresentationEtatsActions (Entrée : MA , Sortie : MCA)

2: {
3: MCA(.,1)← MA(.,1) ;
4: MCA(.,2)← MA(.,2) ;
10 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

5: index ← 3 ;
6: n, index, loc, i, j : Entier,;
7: Tant que index<= n Faire
8: {
9: Pour i de 1 à index Faire
10: Calculer cont(Ai-1, Aindex, Ai)
11: Fin Pour
12: Calculer cont(Aindex-1, Aindex, Aindex+1)
13: loc ← Max cont ;
14: Pour j de index à loc [-1] Faire
15: MCA(.,j)← MCA(.,j-1) ;
16: Fin Pour
17: MCA(.,loc)← MA(.,index) ;
18 : index← index + 1
19: }
20: Permuter les lignes comme les colonnes résultantes
21: }

La matrice d’affinité ordonnée est obtenue après l’application de l’algorithme

BEA sur la matrice des affinités de prédicats. Par permutation de lignes et de
colonnes, l’algorithme BEA regroupe les prédicats qui sont utilisés simultanément
en fournissant une matrice sous la forme d’un semi-bloc diagonal.
Les informations nécessaires durant la 1ère partie sont de type quantitatif. En effet,
elle s’appuie sur le comportement des applications et a pour but de placer dans une
même partition les prédicats qui sont généralement accédés ensemble. Une mesure
indiquant la proximité des prédicats est l’affinité des prédicats.
La matrice d’affinité est utilisée lors du processus de fragmentation, qui consiste
dans un premier temps à grouper l’ensemble des prédicats ayant une forte affinité, et
dans un deuxième temps à fragmenter la relation en fonction de ces groupements.

Algorithme BEA

●Entrée: matrice d’affinité

●Traitement: Permutation des colonnes et des lignes
Pour chaque nouvelle distribution de prédicats
- calculer pour chaque matrice entrée, une nouvelle valeur correspondant à la somme
des valeurs de ses voisins
- la meilleure classification donne la valeur la plus élevée

Maximiser l’affinité des attributs:

●Max MA = Σi=1..n Σi=1..n Aff(Ai,Aj)*[Aff(Ai,Aj-1) + Aff(Ai,Aj+1)]

●L’algorithme BEA fournit la matrice avec des valeurs élevées pour MA.
L’intuition est qu’on doit commencer avec les 2 premières colonnes de la matrice
d’affinité, en insérant la suivante par analyse de la meilleure configuration donnant
le meilleur BOND selon la matrice MA.
Ceci est appelé la contribution de la nouvelle colonne selon la matrice courante MA.
 Répartition d’un Big Data Warehouse Via BEA 11

Calculer le max MA:

●Considérant la matrice MA précédente. On considère les colonnes A1 et A2,

et on analyse l’effet d’insérer A3 en terme de contribution (Cont).
●Pour une composition de (A1, A3, A2), nous avons:
- Cont(A1,A3,A2) = 2BOND(A1,A3) + 2BOND(A3,A2) – 2BOND(A1,A2) où
- BOND(Ax,Ay) = Σ i,j=1..n Aff(Ai,Ax)*Aff(Aj,Ay) avec
aff(A0,Aj)=aff(Ai,A0)=aff(An+1,Aj)=aff(Ai,An+1)=0

Nous terminons par une permutation des lignes suivant la permutation des colonnes
obtenue. La figure 4 ci-dessous est un exemple de MCA :

P1 P2 ... Pk

P1 15 18 0 0
p2 16 80 0 1
..P u 1 0 1 0

Figure 4. MCA

On conclut que l’algorithme BEA est une permutation de lignes et de

colonnes pour maximiser les affinités des prédicats. On fixe au début les deux
premières colonnes puis on ajoute colonne par colonne en maximisant les affinités.
Du coût, les rangs des colonnes peuvent changer.
On aura comme résultat la matrice de classification des affinités (MCA).

3.4. Phase de répartition

P1 P2 ... Pk

P1 15 18 0 0
p2 16 80 0 1
..P u 1 0 1 0

Figure 5. MCA finale

Nous aurons donc au finale une partie de la matrice qui contient les affinités
les plus élevées des prédicats, à partir de laquelle sont réparties les données selon
cette classification.
Dans l’exemple de la figure 5, on fragmente suivant P1 et P2 qui contiennent les
affinités les plus élevées. On aura donc une classe C1= P1&P2
12 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

La solution proposée nous permet de répartir notre Big Data selon les besoins
des utilisateurs. Nous réduisons le nombre de fragments générés et nous minimisons
le temps d’exécution des requêtes ainsi que le coût de chargement des données.
Dans la section qui suit, nous présentons un exemple détaillé de notre solution, ainsi
que son application sur un Big Data réel issu du banc d’essai TPC-DS.

4. Validation expérimentale

Dans cette section nous présentons une concrétisation de notre solution.

D’abord, nous présentons l’environnement expérimental du travail. Ensuite, nous
proposons un exemple d’application détaillé des différentes étapes de l’approche
proposée. Enfin, nous exposons les résultats obtenus après son application sur un
Big Data Warehouse.

4.1. Présentation de l’environnement expérimental

Pour valider notre travail, nous avons utilisé un Big Data Warehouse réel issu
du benchmark TPC-DS (Pilho, 2014). Ce benchmark demeure le plus utilisé par les
travaux abordant le problème de la fragmentation des Big Data Warehouse que nous
considérons similaires à notre contexte de travail. Nous citons les laboratoires de
recherches comme ENSMA (Boukhalfa, 2009), ERIC (Darmont, 2006), (Arres et al,
2014). Le choix de TPC-DS nous permettra de comparer nos résultats à ces travaux
aussi bien au niveau technique que pratique de la solution. Nous avons utilisé le
TPC-DS pour valider la méthode avec un SF=1TB de données.

Sur ce Big Data Warehouse, nous avons exécuté un ensemble de 4 requêtes

réparties sur trois sites géographiquement distants. De point de vue matériel, nous
avons utilisé deux machines ayant les caractéristiques suivantes:

- machine 1 : Intel(R), Core(TM) 2 Duo, CPU 2GHz, 1,99 Go de RAM,

- machine 2 : réduction Intel(R), Core(TM) i3, CPU 2GHz, 4 Go de RAM,

Pour la répartition du Big Data Warehouse sur ces 2 machines, nous avons
utilisé un réseau privé virtuel (VPN) (Pham, 2002). Un VPN repose sur un
protocole, appelé "protocole de tunnélisation" qui permet aux données passant d'une
extrémité à l'autre du VPN d'être sécurisées par des algorithmes de cryptographie.
Pour la génération des tables du banc d'essai TPC-DS, nous avons installé Oracle
10g sur la machine 1 et Oracle 11g sur la machine 2 que nous avons trouvé les plus
adaptées aux capacités des machines.

Le TPC-DS est constitué de 24 tables : 7 tables de faits : store_sales,

store_returns, catalog_sales, catalog_returns, web_sales, web_returns et inventory,
et 17 tables de dimensions : store, call_center, catalog_page, web_site, web_page,
warehouse, customer, customer_adress, customer_demographics, date_dim,
 Répartition d’un Big Data Warehouse Via BEA 13

household_demographics, item, income_band, promotion, reason, ship_mode,

time_dim (Pilho, 2014). Le tableau 1 résume les caractéristiques de chaque table.

Tableau 1. Caractéristiques des tables du Big Data Warehouse

Taille d’un
Tables Nombre d’enregistrement enregistrement en
octets
call_center
6 305

catalog_page
11 718 139

catalog_returns
144 067 166

catalog_sales
1 441 548 226

customer
100 00 132

customer_address
50 00 110

customer_demographics 1 920 800 42

date_dim
73 049 141

household_demographics 7 200 21

income_band
20 16

inventory
11 745 000 16

item
18 000 281

promotions
300 124

reason
35 38

ship_mode
20 56

store
12 263
14 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

store_returns
287 514 134

store_sales
2 880 404 164

ime_dim
86 400 59

warehouse
5 117

web_page
60 96

web_returns
71 763 162

web_sales
719 384 226

web_site
30 292

4.2. Exemple d’application sur le benchmark TPC-DS

Nous commençons par la 1ère phase:

Comme indique la figure 6 de la MUP que chaque cellule montre qu’un prédicat
donné appartient à la requête correspondante ou non.
La requête R1 contient les prédicats P1 et P3.
La requête R2 contient les prédicats P2 et P3.
La requête R3 contient les prédicats P2 et P4.
La requête R4 contient les prédicats P3 et P4.

P1 P2 P3 P4

R1 1 0 1 0

R2 0 1 1 0

R3 0 1 0 1
R4 0 0 1 1

Figure 6. MUP

Ensuite, nous poursuivons par la phase 2.

 Répartition d’un Big Data Warehouse Via BEA 15

La figure 7 est un exemple de MFU. Chaque cellule contient la fréquence

d’utilisation d’une requête par les utilisateurs sur un site donné.
Au finale, la requête R1 est appelée 45 fois.
La requête R2 est appelée 5 fois.
La requête R3 est appelée 75 fois.
La requête R4 est appelée 3 fois.

S1 S2 S3

R1 15 20 10

R2 5 0 0

R3 25 25 25
R4 3 0 0

Figure 7. MFU

Puis, nous passons à la 3ème phase.

On a comme données pour le moment:
R1 : P1 P3 45
R2 : P2 P3 5
R3 : P2 P4 75
R4 : P3 P4 3
Nous aurons donc notre MA suivante pour la première étape :

P1 P2 P3 P4

P1 45 0 45 0

P2 0 80 5 75

P3 45 5 53 3
P4 0 75 3 78

Figure 8. MA
16 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

Après le remplissage de la Ma (Figure 8), nous appliquons l’algorithme BEA

sur cette matrice comme deuxième étape.
On fixe au début les deux premières colonnes comme données (Figure 9) puis on
calcule le BOND de chaque colonne pour avoir le maximum d’affinité des prédicats.
D’où, la 3ème colonne sera insérée soit au début, soit au milieu ou soit à la fin des 2
premières colonnes.

P1 P2 P3 P4 P1 P2 P3 P4

P1 45 0 45 0 P1 45 0

P2 0 80 5 75 P2 0 80

P3 45 5 53 3 P3 45 5
P4 0 75 3 78 P4 0 75

Figure 9. Initialisation de la MCA

On calcule maintenant l’ensemble de contribution :

Cont(A0,A3,A1) = 8820
Cont(A1,A3,A2) = 10150
Cont(A2,A3,A4) = 1780

Voici le calcul de Cont (A0,A3,A1) :

●Cont(A0,A3,A1)=2(bond(A0,A3)+bond(A3,A1)-bond(A0,A1))

●bond(A0,A3)=aff(A1,A0)*aff(A1,A3)+aff(A2,A0)*aff(A2,A3)+
aff(A3,A0)*aff(A3,A3)+aff(A4,A0)*aff(A4,A3)= 0 + 0 + 0+ 0=0

●bond(A3,A1)=aff(A1,A3)*aff(A1,A1)+aff(A2,A3)*aff(A2,A1)+
aff(A3,A3)*aff(A3,A1)+aff(A4,A3)*aff(A4,A1)=45*45+5*0+53*45+3*0=4410

●bond(A0,A1)=0

●Cont(A0,A3,A1)=2*4410=8820

On trouve que la meilleure composition est (A1,A3,A2) qui donne le maximum

d’affinité des prédicats.
Nous permutons au début la 2ème et la 3ème colonne (Figure 10).
 Répartition d’un Big Data Warehouse Via BEA 17

P1 P2 P3 P4 P1 P3 P2 P4

P1 45 0 45 0 P1 45 45 0

P2 0 80 5 75 P2 0 5 80

P3 45 5 53 3 P3 45 53 5
P4 0 75 3 78 P4 0 3 75

Figure 10. Permutation de la MCA (1ère étape)

De même pour la 4ème colonne, la contribution (A3,A2,A4) est la meilleure

composition qui donne le maximum d’affinité des prédicats. (Figure 11)

P1 P2 P3 P4 P1 P3 P2 P4

P1 45 0 45 0 P1 45 45 0 0

P2 0 80 5 75 P2 0 5 80 75

P3 45 5 53 3 P3 45 53 5 3
P4 0 75 3 78 P4 0 3 75 78

Figure 11. Permutation de la MCA (2ème étape)

De même que la permutation des colonnes, on permute les lignes.

Dans notre exemple, nous avons permuté les colonnes 2 et 3, donc on termine par
permuter les lignes 2 et 3. La figure 12 est la matrice résultante.

P1 P2 P3 P4 P1 P3 P2 P4

P1 45 0 45 0 P1 45 45 0 0

P2 0 80 5 75 P3 45 53 5 3

P3 45 5 53 3 P2 0 5 80 75
P4 0 75 3 78 P4 0 3 75 78

Figure 12. Permutation de la MCA (3ème étape)

18 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

Nous abordons la dernière phase de classification des prédicats.

Nous aurons comme résultat deux classes :

C1=P1 & P3

C2= P2 & P4

Nous fragmentons notre Big Data Warehouse selon ces deux classes (Figure 13).

P1 P3 P2 P4

P1 45 45 0 0

P3 45 53 5 3

P2 0 5 50 75
P4 0 3 75 78

Figure 13. MCA

A partir de l’ensemble des requêtes présenté en annexe, nous avons collecté 4

prédicats de sélection sur les tables de dimension. Sur ces prédicats, nous avons
appliqué les 4 phases de notre solution. Nous aurons au finale deux classes de
prédicats donc deux fragments.

4.3. Interprétation des résultats obtenus

Dans notre exemple, la dernière phase de classification a engendré 2 classes

de prédicats. Nous avons utilisé la conjonction de ces prédicats par classe pour le
partitionnement des tables sur deux fragments.
Les fragments engendrés ont été par la suite, alloués aléatoirement sur les deux
machines distantes. Pour la validation de notre solution, nous avons commencé par
mesurer les temps d’exécution des requêtes dans le cas d’un Big Data Warehouse
centralisé, ensuite, réparti en appliquant l’algorithme BEA. Les résultats obtenus
sont récapitulés dans le tableau 2.
 Répartition d’un Big Data Warehouse Via BEA 19

Tableau 2. Temps d’exécution des requêtes utilisées en (mn : s : ms)

Temps d’exécution Temps

Numéro de requête
centralisé d’exécution
réparti

1 4 : 58 : 34 1 : 22 : 10

2 6 : 46 : 01 1 : 31 : 43

3 10 : 31 : 88 5 : 04 : 16

4 15 : 39 : 08 8 : 34 : 45

Pour les requêtes numéro 1, 2, 3 et 4, les temps d’exécution ont diminué dans
le tableau 2, ce qui constitue pour nous un gain non négligeable. Le temps
d’exécution global des requêtes dans un contexte réparti a diminué de 70% par
rapport au contexte centralisé (Figure 14).
Pour la 1ère et la 2ème requête, la diminution du temps d’exécution dépasse le 2/3
jusqu’au 3/4 du temps du centralisé vers le réparti. Par contre, pour la 3ème et la 4ème
requête, le temps d’exécution diminue mais ne dépasse pas la moitié du temps
d’exécution centralisé. Cela est dû par l’augmentation du nombre de jointures pour
ces deux requêtes.

Temps d'exécution des requêtes

en minutes

16
centralisé
réparti
36

Figure 14. Temps d’exécution des requêtes.

20 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

Nous avons donc diminué le temps d’exécution des requêtes pour un Big
data Warehouse réparti avec une minimisation des fragments engendrés et
minimisation du coût de chargements des fragments. Nous avons passé de trois sites
à deux.

La répartition nous minimise le temps d’exécution des requêtes, le coût de

chargements des données, mais cela ne veut pas dire que l’augmentation des
fragments minimise encore le temps d’exécution des requêtes.
En effet, l’augmentation des jointures entre les fragments avec quelques fois des
problèmes de réseaux peuvent impliquer des inconvénients sur la répartition en
temps d’exécution des requêtes.

5. Conclusion

Dans cet article, nous nous sommes intéressés à la répartition d’un Big Data
Warehouse selon l’algorithme BEA. Nous avons proposé une solution à ce fait. Elle
repose sur quatre phases : une phase d’utilisation des prédicats, une phase de
codification, une phase de classification et une phase de répartition;

La première phase se base sur la MUP pour générer la matrice d’utilisation

des prédicats. La phase de codification consiste à produire une représentation de la
MFU selon l’utilisation des requêtes dans les différents sites. La troisième phase
utilise l’algorithme BEA pour obtenir la MCA. La phase de répartition est la phase
de la classification engendrée par BEA pour fragmenter notre Big Data Warehouse.

Pour l’évaluation de la solution proposée, nous l’avons appliquée sur un Big

Data Warehouse réel issu du banc d’essai TPC-DS que nous avons réparti selon
notre démarche de fragmentation en utilisant les différentes requêtes proposées
comme exemple d’application. Les résultats obtenus sont motivants et garantissent
une utilisation plus adéquate et plus souple des données au sein de l’entreprise.

A l’issue de ce travail, nous estimons que quelques axes de recherches restent

à étudier et à approfondir. Le premier est relatif à l’allocation (ou répartition) des
données du Big Data Warehouse en un ensemble de MD. Le problème de
l’allocation des données dans un contexte de Big data Warehouse doit tenir compte
des contraintes de répartition notamment la contrainte d’accès à un MD à partir des
sites distants, le stockage des données, le délai de réponse et la fréquence
d’utilisation de chaque MD par les différents sites de l’entreprise. Il faut aussi tenir
compte de la contrainte de chargement d’un MD dans tous les sites.

Dans la plupart des cas, la répartition d’un Big Data Warehouse est fondée
sur des critères de fragmentation (attributs, prédicats de sélection, affinité, etc.) et/ou
des critères de réplication (fréquence d’utilisation, coûts d’accès, coûts de stockage,
etc.). Ces critères évoluent selon les besoins des utilisateurs. Pour faire face aux
changements, une mise à jour périodique du schéma de répartition est nécessaire.
 Répartition d’un Big Data Warehouse Via BEA 21

Une automatisation de cette mise permettrait probablement d’améliorer l’utilisation

du Big Data Warehouse.

Bibliographie

Arres, B., N. Kabachi, F. Bentayeb et O. Boussaid (2014). Application du paradigme

MapReduce aux données ouvertes Cas: Accessibilité des personnes à mobilité réduite aux
musées nationaux. EDA.

Attasena, V., N. Harbi, et J. Darmont (2013). Sharing-based privacy and availability of cloud
data warehouses. EDA B-9, 17–32.

Barr, M. (2013). Bi-objective optimization based on compromise method for horizontal

fragmentation in relational data warehouses. International Journal of Machine Learning and
Computing 3, 250–254.

Bentayeb, F. et O. Rakotoarivelo (2007). Evolution de schéma par classification automatique

pour les entrepôts de données. EDA B-3, 99–112.

Bouchakri, R. et L. Bellatreche (2012). Sélection incrémentale d’un schéma de fragmentation

horizontale d’un entrepôt de données relationnel. In Proceedings of EDA., 2–16.

Boufares, F., A. BenSalem, et S. Correia (2012). Un algorithme de déduplication pour les

bases et entrepôts de données. INFORSID, 497–506.

Boukhalfa, K. (2009). De la conception physique aux outils d’administration et de tuning des

entrepôts de données. Thèse de doctorat, Université de Poitiers.

Darmont, J. (2006). Optimisation et évaluation de performance pour l’aide à la conception et

à l’administration des entrepôts de données complexes. Thèse de doctorat, Université
Lumière Lyon 2.

Dehdouh, K., F. Bentayeb, et N. Kabachi (2013). Performances de requêtes olap dans les
bases de données en colonnes. ASD, 439–444.

Elmansouri, R., E. Ziati, et O. Elbeqqali (2013). L’analyse en composantes principales

normée: Une nouvelle approche pour la fragmentation des entrepôts de données. ASD.

Ettaoufik, A., L. Bellatreche, M. Ouzzif, E. Ziyati, et H. Belhadaoui (2013). Service web pour
la fragmentation horizontale des entrepôts de données. ASD.

Favre, C. (2007). Évolution de schémas dans les entrepôts de données : mise à jour de
hiérarchies de dimension pour la personnalisation des analyses. Thèse de doctorat,
Université de Lyon (Lumière Lyon 2).

Ghorbel, M., K. Tekaya, et A. Abdellatif (2016). Réduction du nombre des prédicats pour les
approches de répartition des entrepôts de données. ISI.
22 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

Hoffer, J., and Severance, D. The use of cluster analysis in physical data base design. In
Proceedings of the 1st International Conference on Very Large Data Bases (1975), ACM, pp.
69_86. 32, 34

Kerkad, A., L. Bellatreche, et D. Geniet (2012). Exploitation de l’interaction des requêtes olap
pour la gestion de cache et l’ordonnancement de traitements. EDA, 154–163.

Kerkad, A., L. Bellatreche, et D. Geniet (2013). La fragmentation horizontale revisitée : Prise

en compte de l’interaction de requêtes. EDA B-9, 117–132.

Mahboubi, H. (2008). Optimisation de la performance des entrepôts de données XML par

fragmentation et répartition. Thèse de doctorat, Université Lumière Lyon 2.

Nehme, R. et P. Valduriez (2011). Automated partitioning design in parallel database

systems. SIGMOD : International Conference on Management of data, 1137–1148.

Navathe, S., Ceri, S., Wiederhold, G., and Dou, J. Vertical partitioning algorithms for
database design. ACM Transactions on Database Systems (TODS) 9, 4 (1984), 680_710. 32,
36.

Navathe, S., and Ra, M. Vertical partitioning for database design : a graphical algorithm. In
Proceedings of the 1989 ACM SIGMOD international conference on Management of data
(1989), ACM, p. 450. 19, 20, 33, 34, 48.

Ouazzani, A. E., N. Harbi, et H. Badir (2014). Contrôle d’accès aux entrepôts de données
fondé sur le profil utilisateur. ASD, 95–100.

Ozsu, T. et P. Valduriez (1999). Principes of distributed database systems. Prentice Hall, 19–
22.

Perriot, R., J. Pfeifer, L. d’Orazio, B. Bachelet, S. Bimonte, et J. Darmont (2013). Modèles de

coût pour la sélection de vues matérialisées dans le nuage, application aux services amazon
ec2 et s3. EDA B-9, 53–68.

Pham, C. (2002). Vpn et solutions pour l’entreprise. SaaS, Université de Pau et des Pays de
l’Adour.

Pilho, K. (2014). Transaction processing performance council (tpc). Guide d’installation.

Tekaya, K. (2012). Fragmentation et Allocation Dynamiques des Entrepôts de Données.

Thèse de doctorat, Facultés des sciences de Tunis.

Tekaya, K., A. Abdellatif, et H. Ounalli (2010). Data mining based fragmentation technique
for distributed data warehouses environment using predicate construction technique. In Sixth
International Conference on Networked Computing and Advanced Information Management
(NCM), 63-68.
 Répartition d’un Big Data Warehouse Via BEA 23

Annexe 1

Création des tables du Big Data Warehouse TPC-DS centralisé :

create external table catalog_page (

cp_catalog_page_sk bigint,
cp_catalog_page_id text,
cp_start_date_sk bigint,
cp_end_date_sk bigint,
cp_department text,
cp_catalog_number bigint,
cp_catalog_page_number bigint,
cp_description text,
cp_type text
)
using text with ('text.delimiter'='|') location 'hdfs://x/y/catalog_page';

create external table customer_demographics (

cd_demo_sk bigint,
cd_gender text,
cd_marital_status text,
cd_education_status text,
cd_purchase_estimate bigint,
cd_credit_rating text,
cd_dep_count bigint,
cd_dep_employed_count bigint,
cd_dep_college_count bigint
)
using text with ('text.delimiter'='|') location 'hdfs://x/y/customer_demographics';

create external table inventory (

inv_date_sk bigint,
inv_item_sk bigint,
inv_warehouse_sk bigint,
inv_quantity_on_hand bigint
)
using text with ('text.delimiter'='|') location 'hdfs://x/y/inventory';
24 Acronyme Revue. Volume 1 – n° 1/2012 AR_entetegauche

Annexe 2

Quelques requêtes utilisées:

select d_year, i_brand_id brand_id, i_brand brand, sum(ss_ext_sales_price)

sum_agg
from date_dim, store_sales, item
where d_date_sk = ss_sold_date_sk and ss_item_sk = i_item_sk and i_manufact_id
= 436 and d_moy=12
group by d_year, i_brand, i_brand_id
order by d_year, sum_agg desc, brand_id
limit 100;

select i_item_id, avg(ss_quantity) agg1, avg(ss_list_price)

agg2, avg(ss_coupon_amt) agg3, avg(ss_sales_price) agg4
from store_sales, customer_demographics, date_dim, item, promotion
where ss_sold_date_sk = d_date_sk and ss_item_sk = i_item_sk and ss_cdemo_sk =
cd_demo_sk and ss_promo_sk = p_promo_sk and
cd_gender = 'F' and cd_marital_status = 'W' and cd_education_status
= 'Primary' and
(p_channel_email = 'N' or p_channel_event = 'N') and d_year = 1998
group by i_item_id
order by i_item_id
limit 100;

select ca_zip, sum(cs_sales_price)

from catalog_sales, customer, customer_address, date_dim
where cs_bill_customer_sk = c_customer_sk and c_current_addr_sk =
ca_address_sk and
(substr(ca_zip,1,5) in ('85669', '86197','88274','83405','86475', '85392', '85460', '
80348', '81792')
or ca_state in ('CA','WA','GA') or cs_sales_price > 500) and
cs_sold_date_sk = d_date_sk and d_qoy = 2 and d_year = 2000
group by ca_zip
order by ca_zip
limit 100;

select i_brand_id brand_id, i_brand brand, i_manufact_id,

i_manufact, sum(ss_ext_sales_price) ext_price
from date_dim, store_sales, item, customer, customer_address, store
where d_date_sk = ss_sold_date_sk and ss_item_sk =
i_item_sk and i_manager_id=7 and d_moy=11 and d_year=1999 and
 Répartition d’un Big Data Warehouse Via BEA 25

ss_customer_sk = c_customer_sk and c_current_addr_sk =

ca_address_sk and substr(ca_zip,1,5) <> substr(s_zip,1,5) and
ss_store_sk = s_store_sk
group by i_brand, i_brand_id, i_manufact_id, i_manufact
order by ext_price desc, i_brand, i_brand_id, i_manufact_id, i_manufact
limit 100;

View publication stats