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
IGURE10.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
Dans le document
Gestion de flux de données pour l'observation de systèmes
(Page 177-181)