COMPARAISON DES SYSTEMES DE TRAITEMENT DES EVENEMENTS COMPLEXES ET PROPOSITION D’UNE ARCHITECTURE

COMPARAISON DES SYSTEMES DE TRAITEMENT
DES EVENEMENTS COMPLEXES ET PROPOSITION
D’UNE ARCHITECTURE

Evènements Complexes 

L’objectif de ce chapitre est de se familiariser avec les notions de base sur les ux de données et le traitement des évènements complexes. Il est composé de trois sections : la première présente brièvement les ux de données, la deuxième présente les concepts de base du traitement des évènements complexes et la troisième section s’intéresse aux techniques et aux domaines d’application du traitement des évènements complexes.

Présentation des ux de données

Aujourd’hui, le monde connaît une augmentation impressionnante du nombre d’objets connectées. Il existe actuellement plusieurs applications qui génèrent des informations en très grande quantité. Ces applications sont issues de domaines variés tels que les transports, l’agriculture, les réseaux de télécommunication, etc. Ceci à pour principale conséquence la multiplication quasi exponentielle du nombre de données générées dans le monde. Lorsque le volume de données augmente, il devient très coûteux de stocker toutes les données avant de les analyser. Il est dès lors judicieux de faire des traitements à la volée sur ces informations. Ce besoin à donc confronté la communauté scientique à de nouveaux challenges dont le principal est celui du traitement des ux de données. Qu’entend-t-on par ux de données ? quelles en sont les spécicités ? Ces interrogations trouveront réponse tout au long de cette section.

Définition 

Selon [10] un ux de données est une séquence de données ou d’évènements structurés que l’on peut considérer comme une innité d’éléments générés de façon continue à un rythme rapide et parfois variable ; la distribution des données pouvant changer au cours du temps. Pour [19], il est impossible de contrôler l’ordre dans lequel les événements ou les données au sein d’un 3 ux arrivent, ni de stocker localement le ux dans son intégralité. De manière plus explicite, les requêtes sur ces ux s’exécutent continuellement sur une période donnée et retournent à chaque fois un résultat diérent selon qu’une nouvelle donnée est reçue. La structure d’un ux de données peut être plus ou moins complexe selon la nature de celui-ci. Généralement les ux de données ou d’évènements sont caractérisés par : • L’identiant de l’objet ayant émis l’événement ; • L’indice temporel de l’événement

 Description d’un ux de données

 Les ux de données sont assimilés à des n-uplets où chaque élément du n-uplet porte une information à exploiter. Un ux de données peut ainsi être caractérisé par plusieurs éléments parmi lesquels : • la distribution ; • La volumétrie ; • la rapidité. Ces éléments sont importants dans leurs études et dans le choix du domaine d’application, car chaque domaine à une certaine spécicité. Parlant des domaines d’applications (Finance, télécommunications, etc.), Il est important de noter que les ux de données jouent des rôles bien dénis. La structure de données au sein des ux de données est un élément fondamental dans le processus de traitement de ceux-ci. Au sein des ux, la lecture des données pour l’analyse ne peut se faire qu’une seule fois, car à chaque instant, le ux est mis à jour par l’arrivée de nouvelles données et la perte des anciennes. Il faut dire que l’analyse sur des ux de données est largement diérente de celle sur les données conventionnelles. Selon [9] la diérence fondamentale entre les ux de données et les données relationnelles conventionnelles tourne autour des points suivants : • Les ux de données se traitent en temps réel ; • Le système n’a pas de contrôle sur l’ordre dans lequel les éléments arrivent ; • Les ux n’ont pas de taille xe ; • une fois qu’un élément a été lu, il est supprimé ou alors archivé. Selon que la donnée est structurée ou non, le processus de traitement du ux peut être diérent. On distingue ainsi trois diérentes catégories de structures de données : les données structurées, les données semi-structurées et les données non structurées. Flux de données structurées : dans ce type de ux, les données arrivent sous forme d’enregistrements respectant ainsi une structure ou alors un schéma bien déni. Ils possèdent ainsi le nom des diérents champs ainsi que leurs types. Flux de données semi-structurées : les données d’un ux de données semi-structurées arrivent sous forme de balise XML qui est devenue l’un des formats standards pour l’échange de données sur le web. 4 Flux de données non structurées : dans ce type de ux, les données sont représentées ou stockées sans format prédéni. Elles sont généralement constituées de documents textes ou multimédias, mais peuvent également contenir autres types de données. Très souvent le traitement de ces types de données est plus complexe que les autres à cause de cette absence de format prédéni. Comme pour les données conventionnelles, il existe également des systèmes de gestion de ux de données. La prochaine section présentera comment fonctionne ce type de système. 

Les systèmes de gestion de ux de données

 Le caractère spécique des ux de données fait en sorte qu’il est impossible de les traiter en utilisant les systèmes de gestion de données conventionnelles. C’est pour cette raison que de nouveaux systèmes spécialisés dans la gestion de ux de données (SGFD) ont vu le jour. Dans les SGFD, les ux sont assimilés à une séquence innie de données structurées sous forme d’enregistrements arrivant de manière continue et ordonnée. L’ordre étant généralement déni par rapport au temps. Contrairement aux systèmes conventionnels de gestion de données, les données ne sont pas disponibles par accès sur disque, ce sont au contraire des ux transitoires temporairement stockés dans la mémoire centrale, en général dans une structure de le d’attente limitant ainsi la taille des données. Une fois consultée, la donnée est éliminée ou archivée. Avec les SGFD il est alors possible de formuler des requêtes continues qui s’évaluent au fur et à mesure sur un ux ou sur des fenêtres. Fifigure 1.1  Traitement de ux de données vs traitement de données conventionnelles [30] Comme le présente la figure 1.1, le traitement des ux de données doit se faire rapidement, car en fonction de la vitesse du ux un traitement inadéquat pourrait entraîner la perte d’informations. Comme nous pouvons le voir, l’ensemble des données du ux sont stockées en mémoire centrale et le traitement se fait au niveau de cette mémoire là. Des requêtes continues sont donc nécessaires pour gérer le changement rapide des données contenues dans le ux. Plusieurs types de systèmes de gestion de ux de données ont donc été proposés allant des 5 SGFD génériques aux SGFD spéciques ayant des domaines d’applications particuliers (réseau de capteurs, réseau de trac sur internet). 

LIRE AUSSI :  Modèle acoustique en téléphonie

 Les SGFD génériques 

Les SGFD génériques traitent des ux quelques soient leurs structures. Parmi ces systèmes, nous pouvons citer : • STREAM : C’est un SGFD développé à l’université de Stanford. Il est muni d’une interface graphique. Sa syntaxe est basée sur CQL (Continuous Query Langage) an de formuler des requêtes continues [28]. • TelegraphCQ : Il est développé à l’université de Berkeley. Après une première tentative infructueuse qui consistait à implémenter un système de gestion de ux de données en Java, l’équipe du projet TelegraphCQ s’est orientée vers le développement d’une extension du SGBD open source postgreSQL [28]. 

Les SGFD spéciques 

Les systèmes de gestion de ux de données spéciques traitent des données pour la résolution de problèmes particuliers à un domaine. Parmi ces systèmes, nous pouvons citer : • Gigascope et Hancock : C’est un système propriétaire AT&T orienté gestion de réseaux ( analyse de trac, détection d’intrusion, analyse de conguration des routeurs, etc) [28]. • NiagaraCQ : Développé à l’Université de Wisconsin-Madison, NiagaraCQ est un système de gestion de plans de requêtes continues sur des bases de données de l’Internet. L’objectif est de gérer un grand nombre de requêtes, de manière dynamique (les requêtes sont ajoutées et puis éliminées continuellement) [28]. Les systèmes de gestion des ux de données bien qu’ils permettent de gérer en temps réel les ux de données, sont limités face à certains cas d’applications tels que la supervision des réseaux de capteurs, des marchés boursiers ou la surveillance des équipements (réseaux ou industriels) qui doivent réagir à des situations (catastrophes naturelles, une hausse d’une action boursière, etc) qui se produisent. Pour répondre à ce besoin un autre paradigme de traitement des ux de données appelé traitement des évènements complexes est utilisé.

Concepts du traitement des évènements complexes 

Plusieurs concepts sont utilisés en traitement des évènements complexes. Une liste non exhaustive de ceux-ci est présentée dans cette section.

Définition d’un évènement 

Un évènement selon [26] est tout ce qui se produit ou tout ce qui est envisagé comme se produisant. Il est à distinguer de la notion d’évènement utilisée pour faire référence à un objet évènement qui désigne un objet représentant, encodant ou enregistrant un évènement, généralement à des ns de traitement informatique [26]. Selon les auteurs [31], lorsque quelque chose se produit dans le monde matériel, elle peut être détectée par des capteurs mécaniques, électriques ou humains qui émettent des ux d’observations. Un motif particulier d’observation est alors détecté par un système de traitement d’événements qui déclenche la création d’un objet événement reétant et/ou décrivant l’événement réel, comme l’illustre la figure 1.2. Comme Fifigure 1.2  Un objet événement compilé à partir d’observations de capteurs et d’autres sources de données [31] exemple d’évènement, nous pouvons citer : • un bogue dans un système ; • un compte bancaire débité ou crédité ; • l’émission d’une lecture par un capteur ; • une éruption volcanique. Les évènements comme toutes entités possèdent des caractéristiques qu’il est nécessaire de connaître pour mieux les détecter.

Table des matières

Introduction générale
1 Evènements Complexes
1.1 Présentation des flux de données
1.1.1 Définition
1.1.2 Description d’un flux de données
1.1.3 Les systèmes de gestion de flux de données
1.1.3.1 Les SGFD génériques
1.1.3.2 Les SGFD spécifiques
1.2 Concepts du traitement des évènements complexes
1.2.1 Définition d’un évènement
1.2.2 Caractéristique d’un évènement
1.2.3 Complexité des évènements
1.2.3.1 Abstraction
1.2.3.2 Evènement simple
1.2.3.3 Evènement complexe
1.2.3.4 Evènement composite
1.2.4 Flux d’évènements
1.2.5 Nuage d’évènements
1.2.6 Gabarit d’évènement
1.2.7 Motif d’évènement
1.2.8 Instance de motif d’évènement
1.2.9 Exemple récapitulatif
1.3 Traitement des évènements complexes
1.3.1 Techniques de traitement des évènements complexes
1.3.2 Systèmes de traitement des évènements complexes
1.3.3 Application du traitement des évènements complexes
2 Traitement des évènements complexes : Etat de l’art
2.1 Système de traitement des évènements complexes basés sur des règles de détection prédéfinies
2.1.1 Langage de traitement des évènements
2.1.1.1 SASE+
2.1.1.2 ETALIS
2.1.1.3 Siddhi
2.1.1.4 PipeFlow
2.1.2 Modèles d’exécution des règles de détection des évènements complexes
2.1.2.1 SASE+
2.1.2.2 ETALIS
2.1.2.3 Siddhi
2.1.2.4 PIPEFLOW
2.1.3 Architecture des systèmes CEP
2.1.3.1 Architecture centralisée
2.1.3.2 Architecture distribuée
2.2 Systèmes de traitement des évènements complexes basés sur des techniques de data mining
2.2.1 iCEP
2.2.2 AutoCEP
2.2.2.1 Première phase
2.2.2.2 Seconde phase
3 Comparaison des systèmes de traitement des évènements complexes
3.1 Critères d’évaluation
3.1.1 Expressivité
3.1.2 Extensibilité
3.1.3 Capacité à gérer plusieurs sources de données
3.1.4 Hiérarchisation des évènements
3.1.5 Traitement distribué
3.1.6 Haute disponibilité
3.1.7 Tolérance aux pannes
3.1.8 Passage à l’échelle
3.2 Comparaison des systèmes de traitement des évènements complexes
3.2.1 SASE+
3.2.1.1 Expressivité
3.2.1.2 Extensibilité
3.2.1.3 Capacité à gérer plusieurs sources de données
3.2.1.4 Hiérarchisation des évènements
3.2.1.5 Traitement distribué
3.2.1.6 Haute disponibilité
3.2.1.7 Tolérance aux pannes
3.2.1.8 Passage à l’échelle
3.2.2 ETALIS
3.2.2.1 Expressivité
3.2.2.2 Extensibilité
3.2.2.3 Capacité à gérer plusieurs sources de données
3.2.2.4 Hiérarchisation des évènements
3.2.2.5 Traitement distribué
3.2.2.6 Haute disponibilité
3.2.2.7 Tolérance aux pannes
3.2.2.8 Passage à l’échelle
3.2.3 WSO2 CEP
3.2.3.1 Expressivité
3.2.3.2 Extensibilité
3.2.3.3 Capacité à gérer plusieurs sources de données
3.2.3.4 Hiérarchisation des évènements
3.2.3.5 Traitement distribué
3.2.3.6 Haute disponibilité
3.2.3.7 Tolérance aux pannes
3.2.3.8 Passage à l’échelle
3.2.4 PipeFlow
3.2.4.1 Expressivité
3.2.4.2 Extensibilité
3.2.4.3 Capacité à gérer plusieurs sources de données
3.2.4.4 Hiérarchisation des évènements
3.2.4.5 Traitement distribué
3.2.4.6 Haute disponibilité
3.2.4.7 Tolérance aux pannes
3.2.4.8 Passage à l’échelle
3.3 Discussion
3.4 Proposition d’un système CEP
Conclusion générale et perspectives
Bibliographie

 

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *