Concepts du serveur StreamInsight

Cette rubrique décrit la manière dont les données sont représentées, traitées, envoyées et transférées hors du serveur StreamInsight. Elle est conçue pour vous permettre de vous familiariser avec les concepts de base associés au traitement des événements complexes dans Microsoft StreamInsight. La rubrique commence par décrire des structures de données, puis décrit les composants du serveur StreamInsight qui agissent sur les données ou les traitent.

Flux de données

Toutes les données dans StreamInsight sont organisées en flux de données. Chaque flux de données décrit une collection de données potentiellement infinie qui change dans le temps. Par exemple, un flux de données de codes de titres boursiers fournit le cours des différentes actions échangées en bourse au fur et à mesure qu'il change, et un flux de données de capteur de température fournit des valeurs de température signalées au fil du temps par le capteur.

Imaginons un scénario d'analyse de l'alimentation dans lequel l'objectif est d'analyser une collection de jauges d'alimentation qui mesurent la consommation d'énergie de différents périphériques. Périodiquement, ces jauges d'alimentation transmettent des données qui incluent leur consommation d'énergie en dixième de watt et un horodatage associé de la lecture. Le tableau suivant affiche les lectures de 3 jauges d'alimentation et suppose que chacune d'elles émet une lecture d'alimentation chaque seconde.

Étant donné que ces informations peuvent être représentées sous forme de valeurs qui changent dans le temps, les données peuvent être représentées dans un flux de données. Les données étant fournies dans ce flux de données, une requête dans ce flux de données pourrait retourner l'analyse avec les valeurs de consommation les plus élevées ou les plus basses sur une période donnée, ou la requête pourrait retourner la liste des 10 premières analyses avec la consommation d'énergie la plus élevée.

Événements

Les données sous-jacentes représentées dans le flux de données sont empaquetées dans des événements. Un événement est l'unité de données de base traitée par le serveur StreamInsight. Chaque événement est composé des éléments suivants :

• En-tête. Un en-tête d'événement contient des métadonnées qui définissent le type d'événement et un ou plusieurs horodateurs qui définissent l'intervalle de temps pour l'événement. Les horodateurs sont basés sur une application et fournis par la source de données et non pas sur une heure système fournie par le serveur StreamInsight. Notez que les horodateurs utilisent le type de données DateTimeOffset, qui prend en charge les fuseaux horaires et se présente au format 24 heures. Le serveur StreamInsight normalise toutes les heures au format de date et d'heure UTC et vérifie en entrée que l'indicateur UTC est défini dans les champs d'horodateur.

• Charge utile. Structure de données .NET qui conserve les données associées à l'événement. Les champs définis dans la charge utile sont définis par l'utilisateur. Leurs types sont basés sur le système de type .NET.

Les événements du flux dont les horodatages d'application correspondent à leur ordre d'arrivée dans la requête sont dits « ordonnés ». Dans le cas contraire, on parle d'événements « non ordonnés ». Le serveur StreamInsight garantit que si des événements arrivent dans le désordre, la sortie de la requête est la même que si les événements arrivent dans l'ordre, à moins que le générateur de requêtes ne le spécifie explicitement. Dans un flux de données, les modèles d'arrivée des événements par défaut sont les suivants :

• Un taux stable, tel que les enregistrements de fichiers ou tables.

• Un taux intermittent et aléatoire, tel que les données d'un scanneur de code-barres en version commerciale.

• Un taux intermittent avec des rafales soudaines, telles que des clics sur le Web ou télémesures météorologiques.

En-tête d'événement

L'en-tête d'un événement définit le type d'événement ainsi que les propriétés temporelles de l'événement.

Type d'événement

Le type d'événement indique si l'événement est un nouvel événement dans le flux de données ou il déclare l'achèvement des événements existants dans le flux de données. StreamInsight prend en charge deux types d'événements : INSERT et CTI (incrément de temps réel).

Le type d'événement INSERT ajoute un événement avec sa charge utile dans le flux d'événements. Outre la charge utile, l'en-tête de l'événement INSERT identifie les heures de début et de fin de l'événement. Le diagramme suivant montre la disposition d'un type d'événement INSERT.

Le type d'événement CTI est un événement de ponctuation spécial qui indique l'achèvement des événements existant dans le flux. La structure de l'événement CTI consiste en un champ unique qui fournit un horodateur actuel. Un événement CTI sert deux objectifs :

1. En premier lieu, il permet à une requête d'accepter et de traiter des événements dont les horodateurs d'application ne correspondent pas à leur ordre d'arrivée dans la requête. Lorsqu'un événement CTI est émis, il indique au serveur StreamInsight qu'aucun événement INSERT entrant suivant ne modifiera l'historique des événements avant l'horodateur CTI. Autrement dit, après avoir émis un événement CTI, aucun événement INSERT ne peut avoir une heure de début antérieure à celle de l'horodateur de l'événement CTI. Cette indication d'« achèvement » d'un flux d'événements permet au serveur StreamInsight de diffuser les résultats des opérateurs de fenêtrage ou d'autres opérateurs d'agrégation qui ont accumulé l'état, ce qui permet de s'assurer que les événements se déroulent de manière efficace dans le système.

2. Le deuxième objectif des événements CTI est de conserver la faible latence de la requête. Des événements CTI fréquents permettront à la requête de produire plus souvent les résultats.

Pour plus d'informations, voir Avancer le temps d'application.

Le diagramme suivant montre la composition d'un type d'événement CTI.

Modèles d'événement

Le modèle d'événement définit la forme de l'événement selon ses caractéristiques temporelles. StreamInsight prend en charge trois modèles d'événement : intervalle, point et session. Les événements intervalle peuvent être vus comme le type le plus générique, dont les événements session et point sont des cas spéciaux.

Intervalle

Le modèle d'événement intervalle représente un événement dont la charge utile est valide pour une période donnée. Il requiert qu'à la fois les heures de début et de fin de l'événement soient fournies dans les métadonnées de l'événement. Les événements intervalle sont uniquement valides pour cet intervalle de temps spécifique. Il est important de noter que les heures de début sont inclusives, alors que les heures de fin sont exclusives concernant la validité de la charge utile de l'événement.

Le diagramme suivant montre la disposition d'un modèle d'événement intervalle.

Exemples d'événements intervalle : largeur d'une impulsion électronique, durée (validité) d'une offre aux enchères ou activité de code de titre dans laquelle le prix du cours acheteur est valide pour une période spécifique. Dans l'exemple d'analyse de l'alimentation décrit ci-dessus, le flux d'événements de la jauge d'alimentation peut être représenté avec les événements intervalle suivants.

Point

Un modèle d'événement point représente une occurrence d'événement sous la forme d'un point unique dans le temps. Le modèle d'événement point requiert uniquement l'heure de début pour l'événement. Le serveur StreamInsight déduit l'heure de fin valide en ajoutant un cycle (la plus petite unité de temps dans le type de données d'heure sous-jacent) à l'heure de début pour définir l'intervalle de temps valide pour l'événement. Étant donné que les heures de fin d'événement sont exclusives, les événements point sont valides uniquement pour l'instant unique de leur heure de début.

Le diagramme suivant montre la disposition d'un modèle d'événement point.

Exemples d'événements point : lecture d'une jauge, arrivée d'un courrier électronique, clic de l'utilisateur sur le Web, code de titre ou entrée dans le Journal des événements Windows. Dans l'exemple d'analyse de l'alimentation décrit ci-dessus, le flux d'événements de la jauge d'alimentation peut être représenté avec les événements point suivants. Notez que l'heure de fin est calculée comme suit : heure de début plus 1 cycle (t).

Session

Un modèle d'événement session représente une occurrence d'événement dont la charge utile est valide pour un intervalle donné ; toutefois, seule l'heure de début est connue à l'arrivée sur le serveur StreamInsight, ainsi l'heure de fin est définie à l'heure maximum future. L'heure de fin de l'événement est connue ultérieurement et mise à jour. Ce modèle d'événement session contient deux propriétés : l'heure d'occurrence et le type de session. Ensemble, ces propriétés définissent le point de départ ou de fin de l'événement session. 

Le diagramme suivant montre la disposition d'un modèle d'événement session.

Exemples d'événements session : processus Windows, événements de trace du Suivi d'événements pour Windows, session utilisateur sur le Web ou quantification d'un signal analogique. L'intervalle de temps valide pour la charge utile d'un événement session est différent entre l'horodateur de l'événement START et l'horodateur de l'événement END. Dans le diagramme suivant, remarquez que l'événement avec une valeur de charge utile « c » n'a pas pour l'instant de date de fin connue.

L'illustration suivante montre la quantification d'un signal analogique à l'aide d'événements session selon les heures de début et de fin définies dans le tableau ci-dessus. Un tel signal continu implique que pour chaque nouvelle valeur, une session END et une session START doivent être soumises. Les sessions décrites dans l'illustration font référence à l'événement entre le temps t1 et le temps t3.

Éléments de performances à prendre en considération au moment de choisir un modèle d'événement

Il est essentiel de choisir le bon modèle d'événement pour votre problème. Par exemple, si vous avez des événements qui durent une certaine période et que votre application est capable de déterminer les heures de début et de fin de l'événement, il est préférable d'utiliser des événements intervalle pour la modélisation. Si vous rencontrez un scénario où vous ne connaissez pas la date de fin d'un événement à son arrivée, réfléchissez à la possibilité de modéliser l'événement en tant qu'événement point, d'allonger sa durée de vie, puis d'utiliser l'opération de découpage pour modifier la durée de vie lorsque la fin de cet événement sera reconnue. Une autre alternative est de modéliser ces événements en tant qu'événements session.

Si les événements session constituent un modèle très pratique, encore faut-il en connaître les implications en termes de performances. Le traitement des événements session fonctionne de façon optimale lorsque ces événements arrivent entièrement ordonnés (toutes les sessions de début ordonnées selon l'heure de début, toutes les sessions de fin selon l'heure de fin et la séquence combinée des événements également ordonnée en fonction de l'heure). Intéressons-nous par exemple à la séquence d'événements session suivante :

Cette séquence est désordonnée sur les horodatages (1, 10, 3, 6, 5, 20). Si les événements session avaient été entièrement ordonnés (ce qui aurait donné 1, 3, 5, 6, 10, 20), l'impact sur les performances aurait été moindre lors du traitement des requêtes. Obtenir que le traitement suive un tel ordre est facile à réaliser. Fractionnez le problème en deux requêtes. La première peut être une requête vide qui reçoit des événements session en entrée, les ordonne et les fournit ordonnés en sortie. La seconde peut prendre cette entrée et appliquer la logique principale. Notez qu'il est préférable de les définir comme deux requêtes distinctes, puis de les joindre en utilisant la composition de requête dynamique. Pour plus d'informations, voir Composer des requêtes pendant l'exécution.

Charge utile d'un événement

La charge utile d'un événement est une structure de données .NET qui contient les données associées à l'événement. Les champs dans la charge utile sont définis par l'utilisateur et leurs types sont basés sur le système de type .NET. La plupart des types élémentaires et scalaires CLR sont pris en charge pour les champs de charge utile. Les types imbriqués ne sont pas pris en charge.

Adaptateurs

Les adaptateurs traduisent et remettent les flux d'événements entrants et sortants vers et à partir du serveur StreamInsight. StreamInsight fournit un Kit de développement logiciel (SDK) d'adaptateur très flexible qui vous permet de générer des adaptateurs pour vos sources d'événements spécifiques au domaine et périphériques de sortie (récepteurs). Les adaptateurs sont implémentés en langage de programmation C# et stockés sous forme d'assemblys. Les classes d'adaptateur sont créées comme modèles au moment de la conception, enregistrées sur le serveur StreamInsight et instanciées au moment de l'exécution sur le serveur comme instances d'adaptateur.

Adaptateurs d'entrée

Une instance d'adaptateur d'entrée accepte des flux d'événements entrants de sources externes telles que les bases de données, fichiers, flux de codes de titres, ports réseau, capteurs, etc. L'adaptateur d'entrée lit les événements entrants dans le format dans lequel ils sont fournis et traduit ces données dans le format d'événement qui est consommable par le serveur StreamInsight.

Vous créez un adaptateur d'entrée pour gérer les sources d'événements spécifiques pour votre source de données. Si la source de l'événement produit seulement un type d'événement unique, l'adaptateur peut être typé. Autrement dit, il peut être implémenté pour émettre des événements d'un type d'événement particulier. Avec un adaptateur typé, toutes les instances de l'adaptateur génèrent le même format de charge utile fixe dans lequel le nombre de champs et leurs types sont connus d'avance. Voici quelques exemples de tels événements : données du flux de code du titre ou données de capteur émises par un périphérique spécifique. Si votre source d'événement émet des types différents dans des conditions différentes, c'est-à-dire, si les événements peuvent contenir différents formats de charge utile ou le format de charge utile ne peut pas être connu d'avance, implémentez un adaptateur non typé. Avec un adaptateur non typé (générique), le format de la charge utile de l'événement est fourni à l'adaptateur au moment de la liaison de la requête, dans le cadre d'une spécification de configuration. Les exemples de telles sources incluent des fichiers CSV qui contiennent un nombre variable de champs où le type de données stockées dans le fichier n'est pas connu jusqu'à l'instanciation de la requête, ou un adaptateur pour les tables SQL Server où les événements générés dépendent du schéma de la table vers laquelle l'utilisateur fait pointer l'instance d'adaptateur. Il est important de noter que, pendant l'exécution, une instance d'adaptateur unique, qu'elle soit typée ou non, émet toujours des événements d'un type spécifique. Les adaptateurs non typés fournissent une implémentation flexible pour accepter des types d'événements lors de la liaison de la requête, plutôt que définir le type d'événement au moment de l'implémentation de l'adaptateur.

Adaptateurs de sortie

Vous créez un modèle d'adaptateur de sortie pour recevoir les événements traités par le serveur StreamInsight, traduire les événements dans un format attendu par le périphérique de sortie (récepteur) et transmettre les données à ce périphérique. La conception et la création d'un adaptateur de sortie est semblable à la conception et la création d'un adaptateur d'entrée. Les adaptateurs de sortie typés sont conçus par rapport à une charge utile d'événement spécifique, alors que les adaptateurs de sortie non typés sont fournis avec le type d'événement uniquement pendant l'exécution, lorsque la requête est instanciée.

Pour plus d'informations, voir Création d'adaptateurs d'entrée et de sortie. L'API de l'adaptateur principal fournit la flexibilité optimale pour l'implémentation sur une source ou un récepteur d'événements. En outre, StreamInsight prend en charge les sources et récepteurs d'événements qui implémentent les interfaces IObservable ou IEnumerable à un niveau supérieur d'abstraction. Pour plus d'informations, voir Utilisation des sources et récepteurs d'événements observables et énumérables (StreamInsight).

Traitement et analyse des événements

Avec StreamInsight, le traitement des événements est organisé en requêtes selon la logique de requête que vous définissez. Ces requêtes utilisent un flux potentiellement infini de données d'entrée limitées dans le temps (enregistrées ou en temps réel), effectuent des calculs sur les données, et génèrent le résultat de façon appropriée.

Modèles de requête

Un modèle de requête est l'unité de base de composition d'une requête. Il s'agit de la structure qui définit la logique métier nécessaire pour analyser et traiter en continu des événements soumis au serveur StreamInsight à partir de l'adaptateur d'entrée et générer un flux d'événements consommé par l'adaptateur de sortie. Par exemple, vous pouvez évaluer des événements de consommation d'énergie entrants pour les valeurs maximales ou minimales sur une période donnée qui dépassent certains seuils que vous établissez.

Les modèles de requête peuvent être écrits pour effectuer des unités de travail spécifiques, puis être composés de modèles de requête plus complexes. Ils sont écrits dans LINQ associé à un langage C#. LINQ est une plateforme de langage qui vous permet d'exprimer le calcul déclaratif sur des jeux d'une manière entièrement intégrée au langage hôte. Cela vous donne la puissance nécessaire pour associer le traitement déclaratif d'événements et la flexibilité de programmation procédurale dans la même plateforme de développement, sans vous préoccuper de la non correspondance de l'impédance entre ces deux paradigmes de programmation.

Le serveur StreamInsight fournit les fonctionnalités suivantes pour écrire des requêtes expressives et une analyse :

• Calculs pour présenter des propriétés d'événement supplémentaires

  Les cas d'usage, tels que les conversions d'unité, requièrent que vous effectuiez des calculs sur les événements que vous recevez. À l'aide de l'opération de projection sur le serveur StreamInsight, vous pouvez ajouter des champs à la charge utile et effectuer des calculs sur les champs dans l'événement d'entrée. Pour plus d'informations, consultez Projection.

• Filtrage des événements

  Dans les cas d'usage, tels que les notifications d'alerte, vous pouvez vérifier si un champ de charge utile dépasse les seuils de fonctionnement pour l'appareil que vous analysez. En général, seul un sous-ensemble des événements qui satisfont certaines caractéristiques est pertinent pour ces cas d'usage. Les événements qui n'ont pas ces caractéristiques n'ont pas besoin d'être traités et peuvent être ignorés. L'opération de filtre vous permet d'exprimer des prédicats à valeurs booléennes sur la charge utile de l'événement et d'ignorer les événements qui ne satisfont pas aux prédicats. Pour plus d'informations, consultez Filtrage.

• Regroupement des événements

  Prenons un flux d'événements qui vous donne des lectures de température de tous vos capteurs de température. Si tous les événements sont fournis via un seul flux d'événements, vous pouvez partitionner les événements entrants selon l'emplacement du capteur ou l'ID de capteur. Le serveur StreamInsight fournit une opération de regroupement qui vous permet de partitionner le flux de données entrant selon des propriétés d'événement telles que l'emplacement ou l'ID, puis d'appliquer d'autres opérations ou compléter des fragments de requête à chaque groupe séparément. Pour plus d'informations, consultez Groupe et application. 

• Fenêtres dans le temps

  Le regroupement d'événements dans le temps est un concept puissant qui permet de nombreux scénarios. Par exemple, vous pouvez vérifier le nombre d'échecs qui se produisent pendant une période fixe et déclencher une alarme s'ils dépassent un seuil. Les fenêtres récurrente et défilante vous permettent de définir des fenêtres sur vos flux d'événements pour effectuer ce type d'analyse. Pour plus d'informations, consultez Utilisation de fenêtres d'événement.

• Agrégation

  Lorsque vous ne vous souciez pas de chaque événement unique, vous pouvez examiner à la place des valeurs d'agrégat telles que les moyennes, les sommes ou les nombres. Le serveur StreamInsight fournit des agrégations intégrées pour sum, count, min, max et average qui opèrent en général dans les fenêtres temps. Pour plus d'informations, consultez Agrégations.

• Identification des N candidats supérieurs

  Un type spécial d'opération d'agrégation est exigé dans les cas d'usage où vous souhaitez identifier les événements candidats qui ont un rang plus élevé selon une métrique spécifique dans un flux d'événements. Les opérations TopK vous permettent de rechercher les candidats selon un ordre que vous établissez sur les champs d'événement dans le flux de données. Pour plus d'informations, consultez TopK.

• Correspondance d'événements de flux de données différents

  Un cas d'usage courant est le besoin de raisonner à propos des événements reçus de plusieurs flux de données. Par exemple, étant donné que les sources d'événements fournissent des horodateurs dans leurs données d'événement, vous pouvez vous assurer que vous faites uniquement correspondre des événements d'un flux de données à ceux d'un deuxième flux de données s'ils sont étroitement liés dans le temps. De plus, vous pouvez avoir des contraintes supplémentaires définies sur les événements à faire correspondre et le moment de la correspondance. Le serveur StreamInsight fournit une opération de jointure puissante qui effectue les deux tâches : dans un premier temps, il fait correspondre les événements des deux sources si leurs heures se chevauchent, puis il exécute le prédicat de jointure spécifié sur les champs de charge utile. Le résultat d'une telle correspondance contient à la fois les charges utiles du premier et du deuxième événement. Pour plus d'informations, consultez Jointures.

• Combinaison d'événements de différents flux de données

  Plusieurs sources de données peuvent fournir des événements du même type que vous pouvez introduire dans la même requête. L'opération d'union fournie par le serveur StreamInsight vous permet de multiplexer plusieurs flux d'entrée dans un flux de sortie unique. Pour plus d'informations, consultez Unions.

• Extensions définies par l'utilisateur

  Les fonctionnalités de requête intégrées du serveur StreamInsight peuvent ne pas être suffisantes dans tous les cas. Pour tenir compte des extensions spécifiques au domaine, les requêtes sur le serveur StreamInsight peuvent appeler des fonctionnalités définies par l'utilisateur fournies via des assemblys .NET. En plus des fonctions définies par l'utilisateur, vous pouvez définir et implémenter des agrégations ou des opérateurs de requête personnalisés. Pour plus d'informations, voir Fonctions définies par l'utilisateur et Agrégats et opérateurs définis par l'utilisateur.

Pour plus d'informations, voir Écriture de modèles de requête dans LINQ. Pour obtenir plus de détails sur l'écriture de requêtes LINQ pour StreamInsight, voir Guide des requêtes StreamInsight.

Instances de requête

Le fait de lier un modèle de requête à des adaptateurs d'entrée et de sortie spécifiques enregistre une instance de requête sur le serveur StreamInsight. Les requêtes liées peuvent être démarrées, arrêtées et gérées dans le serveur StreamInsight. Une fois les données envoyées au serveur StreamInsight via des adaptateurs d'entrée, des calculs peuvent être effectués en continu sur les données. En d'autres termes, à mesure que des événements individuels arrivent sur le serveur, ces événements sont traités par les requêtes actives, qui émettent des événements de sortie en réponse à l'arrivée d'événements d'entrée. L'illustration suivante montre les requêtes et les adaptateurs StreamInsight pendant l'exécution. Le serveur StreamInsight consomme et traite l'événement lorsque l'instance de l'adaptateur d'entrée est liée à une instance d'une requête. Les données traitées sont ensuite envoyées à l'instance de l'adaptateur de sortie liée à la même instance de requête.

Voir aussi

Concepts

Architecture du serveur StreamInsight

Exemple StreamInsight de bout en bout