DISIC : Metacomputing PeerOLAP 1 An Adaptive Peer-to-Peer Network for Distributed Caching of OLAP...

DISIC : Metacomputing PeerOLAP

1

An Adaptive Peer-to-Peer Network for Distributed Caching of OLAP Results

Panos Kalnis, Wee Siong Ng, Beng Chin Ooi,Dimitris Papadias, Kian-Lee Tan

2002 ACM SIGMODInternational conference on management of data

Présenté par : Anis Krichen


2

Plan

Introduction Contexte L’architecture du réseau PeerOLAP Présentation technique

Le nœud PeerOLAP Les algorithmes d’optimisation de requêtes Politique de cache

Études expérimentales et résultats Conclusion - ouvertures


3

Introduction

Importance de la prise de décision rapide et efficace Multiplication des ERP (Enterprise Resource Planing) Data warehouses (Entrepôts de données): DW OLAP (On-Line Analytical Processing)

Requêtes sur Data Warehouses

Diminuer le coût des requêtes En essayant de regrouper les utilisateurs ayant les mêmes

besoins


4

Contexte

Les DW traitent des vues multidimensionnelles de données (measures, dimensions, levels)

O(2d) requêtes group-by possibles Avec d attributs de dimensions (formant le data cube) Search Lattice : graphe orienté

Les nœuds représentent des requêtes group-by

Data cube lattice. Dimensions : Product, Supplier and Costumer


5

Contexte

Une manière intéressante d’accélérer OLAP Pré calculer quelques agrégats Les stocker comme étant des vues

Recherches sur des algorithmes Concernant le problème du choix de la vue à pré calculer Algorithmes gourmands Approche statique

approche dynamique inspirée du cache sémantique de données Au lieu de stocker des pages physiques ou des identifiants On stocke le résultat de requêtes précédentes avec leur

description sémantique


6

Contexte

Un gestionnaire de cache sémantique : WATCHMAN

Spécialement conçu pour OLAP

Le système stocke dans le cache Le résultat de la requête La requête Résolution des requêtes suivantes si correspondances

exactes entre requêtes


7

Contexte

Dynamat : un autre gestionnaire de cache OLAP

Mémorise des ‘fragments’ au lieu de résultat de requête

Fragments : agrégats de résultats de requête granularité plus fine que les vues

Sinon, même politique de cache que watchman


8

Contexte

Décomposition de l’espace multidimensionnel en chunks Le plus petit morceau d’information dans le cache

Quand une requête est lancée Le système génère le jeu de chunks requis Le partage en 2 sous ensembles selon qu’ils sont

» Disponibles sur le cache» Non disponibles

Le système demandera au DW les chunks manquants Algorithmes d’admission et de remplacement similaires à

ceux de watchman.


9

Contexte

PeerOLAP utilise aussi des résultats sous forme de ‘chunk’

Mise à part la granularité fine, 2 avantages: Uniformité des régions sémantiques

» Permet combinaisons des chunks pour répondre aux nouvelles requêtes

Bonne utilisation de l’espace» Pas d’overlapping des résultats dans le cache

Les systèmes présentés jusqu’ici Adoptent des architectures client-serveur traditionnelles Pas de coopération entre caches Pas de prise en compte du facteur réseau


10

Contexte

Proposition d’une approche middleware cache des résultats OLAP fourni par un Web proxy-server Les proxys ne gèrent pas le cache de données dynamiques

Applet pour gérer le dynamisme des données Inconvénient : proxy ne gère pas les données de 2 DW

en même temps Extension de cette idée utilisant une infrastructure

dédiée OCS (OLAP Cache Servers) Serveurs proxy optimisés pour les données OLAP Peut former un réseau et coopérer Granularité grossière (vue entière) Flou quand à la manière utilisée pour gérer plusieurs DW


11

Contexte

PeerOLAP diffère sur plusieurs aspects: Pas d’infrastructure mid-tier pour le cache de OLAP Le réseau PeerOLAP est dynamique (≠ OCS) Granularité plus fine de cache (permet réponses partielles

de plusieurs nœuds) PeerOLAP peut ‘cacher’ des données issues de plusieurs

DW en même temps

Les attentes du systèmes PeerOLAP correspondent bien aux caractéristiques offertes par la technologie P2P


12

Contexte

Piazza : premier système traitant des problèmes de gestion de base de données en environnement P2P

Chaque nœud peut remplir les 4 rôles suivants: Data origin : fournit le contenu original Storage provider : stocke les vues Query evaluator : utilise sa ressource CPU pour évaluer une

requête Query initiator : lance les nouvelles requêtes au système

Piazza s’occupe essentiellement du problème du placement des données Sphères de coopération Publicité : flooding des vues


13

Contexte

Pour PeerOLAP: Une granularité plus fine pose des problèmes de surcharge

aux protocoles de publicité. PeerOLAP étant un système de cache, il ne peut réutiliser

que les données qui ont déjà été demandées PeerOLAP adapte dynamiquement son comportement et sa

structure de réseau pour s’aligner sur la charge de travail. Puisque PeerOLAP se concentre sur les requêtes OLAP

» Possibilité de faire plusieurs optimisations qui ne seraient pas applicables sur d’autres systèmes.


14

Architecture du réseau PeerOLAP

Le réseau PeerOLAP est constitué de nœuds Qui accèdent aux DW Et posent leurs requêtes

Chaque nœud Pi a un cache local et implémente des mécanismes Pour publier le contenu de son cache Pour mettre à disposition ses capacités de calcul

Les autres nœuds peuvent se connecter à Pi pour une requête Pi peut répondre (localement) à la requête (ou une partie)

Sinon il diffuse la requête à ses voisins


15


Dans les deux cas le résultats revient directement au nœud initiateur de la requête

Le but de PeerOLAP est d’agir comme un grand cache où tous les nœuds offrent la possibilité de réduire le coût des requêtes

Un réseau PeerOLAP typique


16


Nombre max de hop : pour éviter le flooding Une requête au DW ne peut être initiée que par le nœud

à l’origine de la requête Évite de surcharger le DW avec le même message

P2 ne sait pas combien de nœuds vont répondre Attends tous les chunks ou l’expiration d’un timer Les chunks manquant seront demandés au DW (last option)

P2 décide ensuite quels chunks garder dans son cache Utilisation des location independant global name lookup

(LIGLO) servers Maintient d’une liste des nœuds (DW, location, speed..) contacte LIGLO pour avoir une liste de voisins potentiels


17


Les nœuds voisins initiaux ne sont pas optimaux Chaque nœud implémente un mécanisme de contrôle

des voisins actuels Le but est d’assurer les coûts les plus bas

Les nœuds ayant des requêtes similaires devraient être voisins

Paramètre système k : maximum de voisins Optimisation du problème des voisins par un cache de

second niveau Suite : composants de l’architecture, traitement des

requêtes, algorithmes de cache et de reconfiguraton de réseau


18

Le nœud PeerOLAP

2 couches: Apllication Cache

La couche application Connaît la structure du DW Et la sémantiques des données

Dans cette implémentation cette couche Est construite comme un agent java envoyé par le DW Cet agent mobile se connecte ensuite à la couche du cache Et envoie à travers cette dernière toutes les requêtes de

données


19

Le nœud PeerOLAP

PeerOLAP fournit un environnement où Plusieurs agents mobiles différents peuvent cohabiter Et effectuer leurs tâches sur le même nœud

Cette polyvalence le rend très extensible et puissant Ceci dit, pas obligé d’avoir un agent mobile si l’utilisateur

est un habitué Application cliente constamment installée


20

Le nœud PeerOLAP

La couche cache: 3 modules Cache local : organisé comme un fichier de chunks Module de contrôle de cache : qui implémente les algorithmes

d’admission et de remplacement dans le cache La plate-forme P2P : communication bas niveau, responsable

de la reconfiguration du réseau


21

Le nœud PeerOLAP

Autres avantages de la séparation en deux couches En isolant le cache de la sémantique des données

» Possibilité de stocker des données issues de plusieurs DW» Chaque chunk a un ID unique

Responsabilité de la couche application De demander le jeu de chunks correct De définir l’avantage qu’on a, à stocker un chunk

Dans un cas extrême, le nœud pourrait servir uniquement de cache à ses voisins et n’exécuter

aucune application cliente


22

Modèle de calcul de coût

Chunk c avec une taille size(c) en tuples S(c,P) le coût de calcule de c dans le nœud P

S(c,P) = a.size(c) (no aggregations of chunks)

Le coût du réseau pour Transférer c de Q à P : Où:

» Cn(P→Q) : coût d’établissement de la connexion» k : nombre de chunks envoyés» Tr(Q→P) : taux de transfert entre Q et P

Le coût total de réponse à c au nœud P en passant par le nœud Q:


23

Traitement des requêtes

Ici on se concentre sur comment Localiser, accéder et ‘cacher’ les chunks

On considère que les DW sont accédés en lecture seule Si changement du contenu du DW

Broadcast d’un message précisant le problème survenu Timer pour chaque chunk calculé

On va présenter ici deux méthodes de traitement de requêtes Eager Query Processing (EQP) Lazy Query Processing (LQP)

Ils diffèrent au niveau de l’effort fourni pour construire le plan d’exécution


24


Eager Query Processing (EQP) Un utilisateur émet une requête q au nœud P, voici comment EQP

la traite:

» q est décomposée en chunks pour former le jeu Call

» P regarde son cache local et en déduit• Clocal : les chunks présents

• Cmiss : les chunks manquant

» P envoie un message à ses voisins (Q1…Qk) leur demandant Cmiss

• Si Qi possède un sous ensemble de Cmiss

• Il calcule le coût Ct(ci, Q→P) et renvoie l’estimation à P• Si un nœud ne possède aucun des chunks, il ne répond pas

» Dans tous les cas Qi fait suivre la requête sur la totalité du Cmiss jusqu’à atteinte du nombre max de hop

Étape 3


25


EQP (suite)» P reçoit les réponses pendant un temps t

» Cpeer le sous ensembles de Cmiss trouvé dans PeerOLAP

• Sélection d’un chunk ci et du nœud Qi qui peut le fournir avec le coût le plus bas

• Sélection d’un chunk cj et du nœud Qj associé

• Si cj disponible sur Qi, on vérifie quel est le moins cher

T({ci,cj},Qi) ou T(ci,Qi) + T(cj, Qj)

• On répète la même chose pour le reste des chunks de Cpeer

» P initialise des connexion directes avec les nœuds choisis dans le plan d’exécution, ces derniers renvoient les chunks qui n’ont pas été effacés entre temps, soit Cevicted les chunks effacés

» Le jeu CDW de chunks sera demandé directement au DW

» CDW = Cmiss – (Cpeer – Cevicted)


26


EQP (suite)» P construit la réponse et la renvoie à l’utilisateur» Les nouveaux chunks sont envoyés au module de contrôle

de cache» Reconfiguration du réseau si requise


27


Lazy Query Processing (LQP) Ici on essaie de réduire le nombre de nœuds visités LQP est similaire à EQP excepté pour l’étape 3

» P envoie la requête à tous ses voisins Q1…k

» Mais ces derniers ne diffusent l’information qu’à leurs voisins les plus ‘avantageux’

» De plus si Qi peut répondre à une partie des chunks, il les retire du message diffusé

» Le processus est répété jusqu’à hmax hops

Si k voisins

» O(k.hmax) messages pour LQP

» O(khmax) messages pour EQP


28

Politique de cache

Afin de définir la politique de contrôle de cache On définit une mesure B() du Benefit ou avantage

» Et ce pour chaque chunk c au nœud P Cette valeur est fonction du coût du calcul d’un résultat Ensuite on utilise une généralisation de LRU

» ClockBenefit Ici on définit le benefit d’un chunk comme suit:

H(PQ) : nombre de sauts de P à Q (a:constante de overhead)

Algorithme d’admission et de remplacement Least Benefit First (LBF) : LRU-like


29

Politique de cache

LBF


30

Politique de cache

Isolated Caching Policy (ICP) P met son cache à disposition Il utilise les algorithmes cités Il ne compte pas les requêtes venant des autres nœuds Il ne remet pas à sa valeur originale le poids d’un chunk

demandé par un voisin Même si ICP ne suit pas une logique de collaboration

» Il colle assez bien à la philosophie des systèmes P2P (les nœuds n’appartiennent pas forcément à même organisation)

» Autonomie : choix des ressources que l’on veut fournir


31

Politique de cache

Hit Aware Caching Policy (HACP) Contraire de ICP

HACP prend en compte les demandes des voisins» Afin d’assurer que les caches coopèrent» Dans le but de minimiser le coût total des requêtes

HACP augmente le poids d’un chunk demandé par un voisin» Plus de chances qu’il le garde» Et assure une disponibilité peu coûteuse à ses voisins


32

Politique de cache

Voluntary Caching Essaye d’exploiter les ressources sous utilisées Empêche toute requête fournit par DW d’être perdue Cette politique se greffe sur

» ICP : vICP» HACP : vHACP


33

Politique de cache

Reconfiguration du réseau Création d’un ensemble virtuel de nœuds voisins ayant les

mêmes caractéristiques La logique est de fournir au nœud P un ensemble de voisins

susceptibles avec une grande probabilité de lui fournir les chunks manquants.

Évite un grand parcours du réseau

Accéder à tous les nœuds serait coûteux Cas spécial de cache


34

Etudes expérimentales

2 implémentations Utilisation d’un prototype

» Un DW dans une ville A» 10 nœuds dans une ville B

Test des aspects fondamentaux et déduction de paramètres en conditions réelles

Puis utilisation de ces paramètres dans un simulateur» Comportements de PeerOLAP dans différentes situations


35


La mesure utilisée pour comparer les résultats est Le Detailed Cost Saving Ratio (DCSR)

wcost(qi) : coût total de la réponse à qi dans le pire cas cost(qi) : coût réalisé par le système

(a) PeerOLAP (b)Client-Side-Cache (c) one large cache (d) Clients sans cache


36


PeerOLAP vs Client-Side-Cache architecture


37


Une configuration plus réaliste ncmax = 4 , hmax = 3, cache size = 1%, groupes de 10 noeuds


38


Évaluation des stratégies d’optimisation de requêtes


39


Évaluation des politiques de cache


40


Effets de la réorganisation du réseau


41

Conclusion

En général les clients se connectent sur un DW et collecte leur données dans un cache

PeerOLAP propose de partager ces caches individuels, ce qui avantagerait tout le monde

Système totalement distribué PeerOLAP fait ses preuves comparés au système C-S

Techniques d’optimisations de requêtes Politiques de cache (coopération, pas de réplication inutile) Mécanismes de reconfiguration


42

Ouvertures

Essayer de trouver une possibilité de considérer des chunks avec un niveau d’aggrégation différents de celui de la requête. Trouver un résultat sur le nœud en faisant plus

d’aggrégation sur les chunks présents» Combinaisons possible augmente de façon exponentielle

Algorithme plus sophistiqués pour la reconfiguration du réseau Trouver le parfait voisinage

» On ne connaît pas tout le réseau» Connexion souvent volatiles

DISIC : Metacomputing PeerOLAP 1 An Adaptive Peer-to-Peer Network for Distributed Caching of OLAP...

Documents

Transcript of DISIC : Metacomputing PeerOLAP 1 An Adaptive Peer-to-Peer Network for Distributed Caching of OLAP...