• Aucun résultat trouvé

Expérimentations pour la sélection du plan de requête

10.3 Intégration et Expérimentations

10.3.2 Expérimentations pour la sélection du plan de requête

Nous avons à notre disposition deux composants capables de calculer de manière

incrémentale ou non les opérateurs de préférences contextuelles. Dans cette section,

nous expérimentons pour déterminer les cas où il est préférable de sélectionner l’un

ou l’autre choix.

L’expérience a été réalisée dans un cadre applicatif financier. Ainsi, 30, 000 n-uplets

ont été collectés depuis des flux de cours d’actions

2

. Les préférences utilisées sont de

la même complexité que celles présentées en section10.2, les détails sont présents dans

notre papier [Petit 2012a]. SoitSun flux, la requête que nous analysons est la suivante :

KBest

k

(S[Nslide∆])

(a) En variant∆sur KBest (pourN

=

500) (b) En variantNsur KBest (pour∆

=

N)

F

IGURE

10.2 – Temps de calcul deCréer GP,GP Incrémentalet de la maintenance deSrc

Résultats : Les expérimentations montrent que le temps d’évaluation de KBest

est dominé par la construction-mise à jour du GP. Nous avons aussi observé que la

structure duGPd’une fenêtre à l’autre pouvait changer. La profondeur maximale du

graphe varie de 2 à 6 et le nombre de n-uplets non-dominés varie de 1 àN. Les grands

changements de structures correspondent aux pires cas de l’algorithme incrémental.

2. Fournit par le service Dukascopy’s Data Export. Disponible à http://www.dukascopy.com/ swiss/english/data_feed/csv_data_export

La figure10.2(a) montre le temps de calcul des deux algorithmes duGP : créer et

in-crémental. Elle indique aussi le temps nécessaire au calcul réduit de la maintenance de

Src, qui est directement utilisée pour l’opérateurBest.

Durant les expérimentations, nous avons utilisé plusieurs tailles de fenêtres N et

de taux∆. Nous remarquons que les changements de taux de mise à jour n’impactent

pas le temps de création duGP, tandis que l’algorithme incrémental obtient un gain de

6 pour un ration N/∆ = 10. Étonnement, les deux algorithmes duGPse comportent

de la même façon lorsque∆∼ N, ce qui correspond au cas où il n’y aurait pas ou peu

d’intersections entre les fenêtres successives. Cela indique que dans la version

incré-mentale, les suppressions dans leBTGprennent peu de temps comparé aux insertions.

Ceci est notamment dû au fait que l’insertion nécessite l’évaluation des comparaisons

(coûteuses dans notre cadre expérimental). Le coût de ces suppressions peut aussi être

augmenté dans le cas où leGPest un graphe fortement connexe, ce qui est difficile à

trouver dans la pratique.

La variation de la taille de la fenêtre (figure 10.2(b) avec ∆ = N) montre que le

comportement n’est pas impacté par le nombre de n-uplets impliqués. Comme prévu,

l’évolution semble quadratique selonN et l’approche incrémentale suit strictement la

performance de l’algorithme de création.

Nous pouvons désormais intégrer notre composant incrémental à l’intérieur

d’As-tronef par la création de la règle suivante :

1 implrules([kbest,B,[C]],

"DynamicKBest"):-2 map_get(B, "incremental", "true", "true"), % Mode incremental par defaut

3 dynamicoperator(C), !. % Si le noeud fils est aussi incremental

Pour plus de complétude, nous pourrions établir une règle disant que si nous sommes

dans le cask =−1 (i.e.Best) et que le ratio N/∆de la description de fenêtre, s’il y en

a une, est inférieur à 2 : alors nous devons utiliser l’opérateurBestnon-incrémental.

10.4 Conclusion

Pour démontrer la flexibilité de l’architecture, et pour répondre au besoin

d’intro-duire les points de vues utilisateurs dans l’observation, nous avons intégré un nouvel

opérateur de préférences dans notre solution. Cet opérateur nous a permis de

sélec-tionner les données les plus intéressantes selon le profil de l’utilisateur. Cette

intégra-tion s’est fait via la spécificaintégra-tion de cinq courtes règles ce qui valide que l’ajout de

composants soit simple.

Dans les quelques approches qui existent dans la littérature [Kontaki 2012,

Morse 2007,Mouratidis 2006], les préférences sont appliquées uniquement sur des

fe-nêtres glissantes. Or, dans notre cas, grâce à l’expressivité de notre système

d’inter-rogation, nous pouvons appliquer cette opération sur tout type de données, qu’elles

proviennent d’une base de données relationnelle ou de flux.

L’évaluation de performances nous a démontré que le choix incrémental est en

général meilleur que sa version statique. Toutefois, pour le cas de l’opérateur Best,

il peut être préférable de choisir la version statique si les variabilités de la relation

temporelles sont trop fortes. De travaux futurs pourraient s’intéresser à la découverte

de motifs plus précis pour affiner ce choix.

Ce travail a été présenté dans le papier [Petit 2012a], ainsi que dans les conférences

nationales avec les papiers [Roncancio 2012] et [Petit 2012b].

« Dear Princess Celestia,

Sometimes you can feel like what you have to of-fer is too little to make a difof-ference, but today, I lear-ned that everypony’s contribution is important, no matter how small. »

Fluttershy

11

Conclusion et perspectives

11.1 Rappel des objectifs . . . . 179

11.2 Contributions de cette thèse. . . . 180

11.3 Perspectives de recherches . . . . 183

La popularisation de la technologie a permis d’implanter des dispositifs et des

ap-plications de plus en plus développés à la portée d’utilisateurs non experts. Comme

les dispositifs se diversifient, des systèmes complexes, distribués et ubiquitaires se

forment. Or, en général, ces utilisateurs n’ont pas les compétences pour maîtriser ces

systèmes en cas de dysfonctionnements. Nous nous intéressons à pouvoir observer les

données de ces systèmes à distance pour aider à les comprendre et les diagnostiquer.

Les objectifs plus détaillés de la thèse sont rappelés en section11.1. La section11.2

présente l’ensemble des contributions que nous avons établies. Enfin, la section 11.3

présente les perspectives de recherches.

11.1 Rappel des objectifs

Actuellement, il existe plusieurs approches capables d’établir un tel système

d’ob-servation. Chaque approche possède un avantage propre : la collecte de données par

les systèmes d’administration, la gestion de la sémantique des données par

l’infor-matique contextuelle, l’analyse de grands volumes par les entrepôts de données, et le

traitement des données en temps réel par la gestion de flux de données. Notre

orienta-tion s’est faite vers ce dernier domaine, car elle est la seule à gérer de façon déclarative

le traitement de données en requête continue. D’une manière plus globale, cette thèse

a pour but d’enrichir nos connaissances sur la gestion de données issues de systèmes

dynamiques hétérogènes.

Nous souhaitons concevoir une solution générique d’observation de système.

Nous souhaitons résoudre deux points importants : gérer l’hétérogénéité des données

issues du système observé ; et permettre le système d’observation à s’adapter

facile-ment.

Système observé : hétérogénéité des données

Nous souhaitons pouvoir observer différents types de systèmes. Cela implique que

la description des systèmes en terme de schéma conceptuel de données est hétérogène.

Les données qui émanent du système sont de tous types et représentent différents

fragments du système. Le schéma de ces données diffère en fonction des sources de

données. Ainsi, il est nécessaire d’avoir une intégration des données et une capacité

de traitement puissante.

Le système en observation est dynamique et ses données évoluent au fur et à

me-sure du temps. Il existe deux catégories de données : les données persistantes et les

données temps réel. Ces dernières peuvent être stockées pour analyse a posteriori,

traitées en temps réel, croisées avec des données passées ou consolidées. Ainsi, il est

important de permettre d’interroger les différentes données.

Système d’observation : adaptabilité aux besoins

Le système d’observation doit être capable de s’adapter efficacement à son

envi-ronnement. Afin de fournir une solution flexible, il est préférable d’avoir un langage

déclaratif. Ce langage doit toutefois avoir un pouvoir d’expression permettant de

gé-rer l’hétérogénéité du dynamisme des données.

De plus, chaque utilisateur possède son interprétation du système, et nous devons

pouvoir faciliter cette personnalisation. Il est également important que le système

d’observation soit extensible. Par exemple, le support de l’ajout de fonctions tierces

pour les utilisateurs experts permet de fournir des capacités d’interrogation plus

spé-cialisées.

Dans cette thèse, nous avons principalement mis en avant la gestion de l’évolution

des données et l’adaptabilité grâce aux travaux sur les flux de données. La gestion de

l’hétérogénéité des schémas conceptuels est assurée par la capacité à interroger aussi

bien les données temps réel que persistantes.

11.2 Contributions de cette thèse

La contribution de cette thèse sur l’observation de systèmes se découpe en trois

parties. Premièrement, nous avons proposéune algèbrede gestion des requêtes

conti-nues et instantanées sur flux et relations. Deuxièmement, nous avons proposé un

in-tergiciel extensiblecapable d’évaluer des requêtes exprimées grâce à l’algèbre. Enfin,

nous avons présenté l’extension de cet intergiciel pour intégrer les supports persistants

dans l’expressivité des requêtes.

11.2.1 Langage de requête formel pour une interrogation généralisée