De plus, les chemins d’adaptation peuvent impliquer d’autres aspects s´emantiques tels que la qualit´e du contenu final produit. En effet, selon l’ordre des op´erations, on pourra obtenir un contenu final diff´erent, par exemple en convertissant le contenu original, on perdra en qualit´e du flux audio impliquant une baisse de la qualit´e des sous-titres produits, ce qui pourrait ˆetre ´evit´e en extrayant imm´ediatement le flux audio du contenu original. Or l’utilisateur pourra vouloir trouver un ´equilibre entre la qualit´e et le temps d’ex´ecution, ´equilibre qui d´epend des performances de l’infrastructure mat´erielle.
Ajoutons `a cela que chaque op´eration logique peut ˆetre prise en charge par diff´erents services physiques possiblement r´epliqu´es sur le r´eseau, et nous obtenons un nombre rapidement important de chemins physiques correspondant aux chemins logiques. Par exemple si nous supposons que deux services physiques peuvent fournir chaque op´eration logique, compte tenu des six chemins logiques possibles, nous obtenons 6× 28 = 1536 chemins physiques possibles. Alors que l’exemple pris n’est pas tr`es compliqu´e, on peut d´ej`a se rendre compte que ce genre de probl`eme n’est pas g´erable par des d´ecisions intuitives.
Pour conclure sur cet exemple, nous pouvons donc noter que de nombreux aspects sont impliqu´es dans la r´esolution d’un tel probl`eme.
– l’emplacement des instances des diff´erentes ressources `a composer – les caract´eristiques des donn´ees ´echang´ees
– les caract´eristiques de la portion d’infrastructure mat´erielle concern´ee – le ou les aspects `a optimiser
Lesquels aspects rel`event tantˆot de caract´eristiques des ressources, des choix et besoins utilisateur et des capacit´es de l’infrastructure mat´erielle. Ils obligent donc l’utilisateur `a faire face `a un probl`eme d’´equilibre tr`es sensible et complexe, en particulier compte-tenu du nombre de solutions possibles qui s’offrent `a lui, alors qu’il n’a ni les connaissances, ni les comp´etences pour trancher.
2.4 Probl`eme sp´ecifique de l’agr´egation dans un entrepˆot de
don-n´ees distribu´e
Les trois exemples pr´esent´es pr´ec´edemment repr´esentent les trois probl`emes classiques li´es `a la r´ e-partition de ressources. En r´ealit´e, ils ne repr´esentent que la partie commune `a (pratiquement) tous les utilisateurs. Or dans la plupart des applications de grilles, on rencontre des probl`emes tr`es sp´ecifiques qui ne rentrent pas exactement dans les trois cas sus-cit´es (malgr´e certains points communs).
Nous avons rencontr´e de nombreux exemples lors du d´eveloppement de la plateforme logicielle GGM d´ecrite Section 1.2.1. Le plus embl´ematique concerne l’entrepˆot de donn´ees distribu´es. De fa¸con grossi`ere, un entrepˆot de donn´ees est une base de donn´ees dont le sch´ema pr´evoit un niveau d’agr´egation pour chaque donn´ee : les donn´ees au niveau le plus d´etaill´e proviennent g´en´eralement directement des sources, alors que les donn´ees de plus haut niveau d’agr´egation sont des statistiques calcul´ees sur l’ensemble des donn´ees de niveau inf´erieur. L’exemple classique est celui des ventes dans une chaˆıne de magasins : au plus bas niveau, on trouve chacune des ventes unitaires par lieu et date, puis au niveau sup´erieur on trouve la somme des ventes par r´egion ou par jour, et au niveau le plus haut on trouve le total des ventes depuis leur d´ebut et sur l’ensemble des magasins.
un agr´egat, l’entrepˆot peut soit lui fournir directement s’il est d´ej`a mat´erialis´e, soit le calculer `a partir des agr´egats mat´erialis´es de niveau inf´erieur. Une hi´erarchie simple est pr´esent´ee Figure 2.9 : les agr´egats de niveau 3 (par exemple les ventes d’une ann´ee) sont calcul´es `a partir de tous les agr´egats de niveau 2 (les ventes des deux semestres de l’ann´ee) qui, eux-mˆemes, le sont `a partir des agr´egats de niveau 1 (les ventes des trimestres de l’ann´ee).
Fig. 2.9 – Exemple de hi´erarchie d’agr´egation d’entrepˆot de donn´ee
2.4.1 Pr´esentation du point de vue de l’infrastructure
La Figure 2.10 montre un exemple d’une telle situation : client1.athome.com veut recevoir l’agr´egat de niveau 3. Certains hˆotes du domaine grid.com h´ebergent une instance du service d’en-trepˆot distribu´e (not´e DDW pour Distributed DataWharehouse) lequel est capable d’effectuer des agr´egations. Les diff´erents agr´egats sont stock´es par le service de caches collaboratifs disponibles sur d’autres hˆotes. Ces agr´egats sont inclus dans des fichiers qui peuvent contenir plusieurs agr´egats non n´ecessairement continus. Ces fichiers peuvent ˆetre r´epliqu´es et les agr´egats peuvent ˆetre inclus dans plusieurs fichiers diff´erents. Ainsi, un mˆeme agr´egat peut ˆetre inclus dans deux fichiers de tailles tr`es diff´erentes. Or, la structure de ces fichiers impose que leur totalit´e soit r´ecup´er´ee avant d’extraire un agr´egat donn´e.
Fig. 2.10 – Le probl`eme sp´ecifique de l’agr´egation vu depuis l’infrastructure
L’objectif du probl`eme sp´ecifique de l’agr´egation est de d´ecider quelle(s) instance(s) du service d’entrepˆot distribu´e et quel(s) fichier(s) utiliser pour fournir l’agr´egat demand´e par l’utilisateur. Une telle d´ecision implique des choix du type : vaut-il mieux r´ecup´erer directement un agr´egat inclus dans
2.4 Probl`eme sp´ecifique de l’agr´egation dans un entrepˆot de donn´ees distribu´e 29
un fichier de grande taille sur un hˆote proche ou bien dans un fichier de faible taille mais sur un hˆote plus distant, ou encore vaut-il mieux recalculer cet agr´egat `a partir des agr´egats de niveaux inf´erieurs en fonction des fichiers dans lesquels ils sont inclus.
2.4.2 Pr´esentation du point de vue de la superstructure GGM
La Figure 2.11 illustre le probl`eme sp´ecifique de l’agr´egation vu depuis la superstructure GGM : (1) un client, qui peut ˆetre un utilisateur ou un autre composant logiciel de la superstructure, ´emet une requˆete d’entrepˆot dont le r´esultat est un agr´egat ; (2) ce dernier ´etablit la liste des diff´erentes solutions d’agr´egation en fonction de la hi´erarchie pr´esent´ee pr´ec´edemment et de l’indexation des agr´egats dans les fichiers logiques ; (3) l’emplacement des diff´erents fichiers logiques est demand´e au cache ; (4) ce dernier informe l’entrepˆot des emplacements physiques et de la taille des fichiers demand´es ; (5) l’entrepˆot ´evalue le coˆut de chacune des solutions d’agr´egation selon ses mod`eles de coˆuts propres ; (6) selon la solution retenue, il r´ecup`ere les fichiers physiques ; (7) puis en extrait les agr´egats n´ecessaires et proc`ede aux agr´egations demand´ee ; (8) enfin il renvoie l’agr´egat demand´e `a l’utilisateur.
Fig. 2.11 – Le probl`eme sp´ecifique de l’agr´egation vu depuis la superstructure GGM
On peut noter une difficult´e annexe impliqu´ee par la dissociation des informations impliqu´ee dans la d´ecision. En effet, la d´ecision ne peut ˆetre prise qu’en regroupant les informations d´etenues par l’entrepˆot distribu´e et le service caches collaboratifs. Cela implique donc un fort couplage entre ces deux composants et des probl`emes de synchronisation. Par exemple : que se passe-t-il si un fichier ait supprim´e apr`es que l’entrepˆot est construit son plan d’agr´egation ? De plus, seule une ´etroite collaboration permet `a ces deux services d’impl´ementer des strat´egies compl´ementaires en ce qui concerne le d´eploiement des fichiers et leur s´election. Par exemple, l’entrepˆot peut d´ecider de construire un fichier contenant de tr`es nombreux agr´egats compte-tenu de leurs r´eguli`eres utilisations conjointes, alors que le cache peut d´ecider de d´ecouper ce fichier afin de le stocker plus facilement selon l’espace disque disponible sur la grille. On voit ici la mise en œuvre de deux strat´egies concurrentes, ce qui risque fort de s’av´erer n´efaste pour les performances.
2.4.3 Analyse
Dans un entrepˆot classique h´eberg´e sur une unique machine, le probl`eme de d´ecider quelles donn´ees doivent ˆetre mat´erialis´ees est d´ej`a assez complexe et rel`eve d’un probl`eme d’´equilibre entre charge disque, charge de calcul et temps de r´eponse. Avec la distribution de l’entrepˆot sur plusieurs hˆotes diff´erents, non seulement ce probl`eme est exacerb´e, mais il oblige ´egalement `a g´erer la r´eplication de certaines donn´ees afin d’assurer leur disponibilit´e, ce qui renvoie aux probl´ematiques pr´esent´ees Section 2.1.
De plus lorsqu’une donn´ees et demand´ee, il ne s’agit plus simplement de savoir si elle est mat´ eria-lis´ee, car elle peut l’ˆetre mais sur un hˆote distant d´epourvu d’une bonne capacit´e de communication, alors que les donn´ees des niveaux inf´erieurs permettant son calcul sont sur des hˆotes proches, dispo-sant d’une grande capacit´e de calcul et de communication : parfois l’agr´egation sera plus efficace que le simple transfert, ce qui n’´etait pas le cas dans les entrepˆots classiques. Cette agr´egation pourra se faire `a partir de diff´erentes donn´ees r´epliqu´ees de niveaux diff´erents, pr´esentant ainsi un grand nombre de possibilit´es. On voit ici apparaˆıtre un probl`eme de d´eploiement/s´election complexe et sp´ecifique aux entrepˆots de donn´ees distribu´es.
Qui plus est, la notion de fraˆıcheur prends ici une importance cruciale : lorsqu’un agr´egat est mat´erialis´e, il doit ˆetre maintenu lors de la mise `a jour des agr´egats de plus bas niveau. Or ce processus de maintenance peut s’av´erer extrˆemement consommateur de ressource et peut prendre de longues heures. Un premier impact est que la strat´egie de r´eplication/placement des agr´egations s’en trouve complexifi´ee et doit ˆetre ´elabor´ee en cons´equence. Le second impact est que cette maintenance implique un d´ecalage de fraˆıcheur entre donn´ees agr´eg´ees et donn´ees d´etaill´ees qui doit ˆetre pris en compte lors d’une requˆete : un utilisateur pourra pr´ef´erer obtenir une r´eponse rapide au d´etriment de la fraˆıcheur, ou le contraire. Enfin, suivant la sensibilit´e de la demande de certaines agr´egations, le concepteur de l’entrepˆot pourra d´elib´er´ement d´ecider de les maintenir plus ou moins fr´equemment. On voit ici apparaˆıtre un probl`eme compl`etement nouveau et sp´ecifique `a ce contexte.
En r´esum´e, dans cet entrepˆot distribu´e on retrouve les probl`emes classiques de d´eploiement, s´ e-lection, composition de ressources, mais dans un contexte particulier soumis `a des contraintes et probl´ematiques sp´ecifiques. De plus, on voit apparaˆıtre le nouveau probl`eme de la gestion de la main-tenance des donn´ees agr´eg´ees, toujours en relation avec les probl´ematiques de r´epartition de ressources, mais sans solution disponible dans la litt´erature. Enfin, on remarque encore que les diff´erents aspects rel`event tour `a tour des choix du concepteur de l’entrepˆot, de son utilisateur, des caract´eristiques des donn´ees et des performances de l’infrastructure mat´erielle.