Fenêtres récurrentes
Une fenêtre récurrente définit un sous-ensemble d'événements se produisant durant une période donnée et sur lesquels vous pouvez effectuer un calcul basé sur un jeu (agrégation, par exemple). À la différence des fenêtres d'instantané et des fenêtres utilisant des nombres, les fenêtres récurrentes divisent la chronologie en intervalles réguliers, indépendamment des heures de début et de fin des événements. StreamInsight autorise le chevauchement des fenêtres récurrentes et des écarts entre des fenêtres consécutives.
Pour obtenir une description générale des fenêtres d'événement et en savoir plus sur leur mode d'implémentation et d'utilisation dans StreamInsight, consultez Utilisation de fenêtres d'événement.
Fonctionnement des fenêtres récurrentes
Les fenêtres récurrentes sont des fenêtres qui « sautent » dans le temps, par période fixe. La fenêtre est définie à l'aide de deux intervalles de temps : la taille de saut H et la taille de fenêtre S. Pour chaque unité de temps H, une nouvelle fenêtre de taille S est créée.
L'illustration suivante montre un flux contenant une série d'événements point. Les barres verticales affichent une fenêtre récurrente qui segmente la chronologie. Ici, H est égal à S. Cela représente une fenêtre récurrente ininterrompue, sans chevauchement, également appelée fenêtre bascule. Une méthode d'extension indépendante a été prévue pour ce type de fenêtre. Chaque zone orange représente le flux de données des fenêtres et les événements associés à cette fenêtre.
Pour chaque fenêtre, l'opération reposant sur un jeu s'exécute et produit un résultat, avec des horodateurs qui dépendent de la stratégie de sortie spécifiée avec la fenêtre. Pour la stratégie de sortie PointAlignToWindowEnd, le résultat se présente de la façon suivante :
Si un événement s'étend au-delà des limites d'une fenêtre, il figure dans plusieurs fenêtres. L'illustration suivante montre un flux contenant trois événements intervalle : e1, e2 et e3. Si la taille de saut H est plus petite que la taille de la fenêtre S, les fenêtres se chevauchent, de sorte que les événements inclus dans la période de chevauchement se répartissent dans plusieurs fenêtres, même s'il s'agit d'événements point qui ne couvrent pas plusieurs fenêtres.
Notez que les événements présentés dans cette illustration ont déjà été limités en vertu de la stratégie d'entrée de la fenêtre. La stratégie d'entrée, comme pour toutes les fenêtres StreamInsight, a pour fonction de faire coïncider les événements à la taille de la fenêtre. Un agrégat ou un opérateur basé sur le temps s'appliquera non plus aux durées de vie d'origine, mais aux durées de vie d'événement limitées dans les fenêtres, c'est-à-dire qu'il ne s'étendra pas au-delà de la fenêtre.
Un paramètre d'alignement peut être spécifié, le cas échéant. Par exemple, l'alignement par défaut d'une fenêtre bascule de 24 heures fait commencer et clôturer chaque fenêtre à minuit. Lorsqu'un alignement personnalisé est spécifié (par exemple, une fenêtre de vingt-quatre heures à compter de 9 heures du matin), le fenêtrage est aligné en fonction de ce point absolu dans la chronologie (dans ce cas, toute valeur datetime dont la partie heure correspond à 9 heures du matin). Le paramètre d'alignement doit être fourni en tant qu'objet DateTime de type DateTimeKind.Utc.
Lorsque vous utilisez des fenêtres récurrentes, il est important de savoir que l'opération reposant sur un jeu permet d'obtenir un résultat, même si l'entrée a changé par rapport à la fenêtre précédente. Cela s'explique par le fait que les fenêtres récurrentes divisent la chronologie en intervalles fixes. L'illustration suivante montre l'application d'une fenêtre récurrente qui est beaucoup plus longue que sa taille de saut. Le scénario suivant (« toutes les 10 secondes, calculez la moyenne de tous les événements ayant eu lieu pendant cinq minutes ») en est un exemple caractéristique.
L'illustration suivante présente le résultat d'une telle agrégation sur le flux de données de fenêtre lorsque la stratégie de sortie est PointAlignToWindowEnd.
Dans le cas d'une agrégation non basée sur le temps, telle que Sum, Avg, Count, tous les résultats de l'agrégation dans ce diagramme ont la même valeur, dans la mesure où le même jeu de charges utiles, e1 et e2 contribuent toujours aux fenêtres sous-jacentes. Ce comportement de résultats répétitifs doit être pris en compte, notamment s'il convient d'appliquer une telle fenêtre à l'intérieur d'un groupe et à une opération APPLY comportant un grand nombre de groupes. Lorsque la fréquence de fenêtre est supérieure à la fréquence d'événement d'origine (comme indiqué, par exemple, dans le diagramme précédent), le taux d'événement de sortie devient significatif. Si un résultat d'agrégation doit être obtenu uniquement en cas de changement d'entrée, il faut utiliser une fenêtre d'instantané.
Stratégies de sortie
PointAlignToWindowEnd
Cette stratégie de sortie génère un événement point dont l'heure de début correspond à l'heure de fin de la fenêtre, comme le montre le diagramme précédent. Cette nouvelle stratégie de sortie est utile lorsque vous combinez le résultat avec un autre flux de données, étant donné qu'il n'existe qu'un seul résultat valide à chaque limite dans le temps qui représente le résultat d'agrégation le plus récent à ce stade. Une fenêtre récurrente avec cette stratégie de sortie peut être combinée avec le modèle de conception point-à-signal afin de créer un flux continu de résultats d'agrégation, qui, à chaque point limite dans le temps, contient un événement intervalle avec le dernier résultat connu.
PointAlignToWindowEnd est la stratégie de sortie par défaut d'une fenêtre récurrente si aucune stratégie de sortie n'est spécifiée.
ClipToWindowEnd
Cette stratégie de sortie génère une taille de fenêtre qui correspond à la durée de vie de l'opération reposant sur un jeu, comme le montre le diagramme suivant. Notez que les implications sont différentes pour la dynamique de la requête.
Comportement CTI
Notez que les fenêtres récurrentes peuvent avoir une incidence sur les événements CTI (Current Time Increment). Lorsque la stratégie de sortie est ClipToWindowEnd, chaque événement CTI sera déplacé vers le début de la fenêtre respective. La raison à cela tient au fait que la taille de la fenêtre est affectée au résultat de l'opération en sus de la fenêtre. Par conséquent, tant que des événements sont reçus dans la fenêtre, l'intervalle de temps complet de la fenêtre est susceptible de changer. Toutefois, lorsque la stratégie de sortie est NEW_POLICY, les événements CTI sont transmis sans changement. Pour plus d'informations sur les événements CTI, consultez Avancer le temps d'application.
Définition des fenêtres récurrentes
Une fenêtre récurrente est définie en fonction de sa taille et de la taille du saut, comme illustré dans l'exemple suivant.
var hoppingAgg = from w in inputStream.HoppingWindow(TimeSpan.FromHours(1),
TimeSpan.FromMinutes(10))
select new { sum = w.Sum(e => e.i) };
L'argument de stratégie de la fenêtre récurrente dans l'exemple ci-dessus est une propriété statique qui renvoie une instance de la classe de stratégies correspondante.
Si la taille du saut et la taille de la fenêtre sont identiques, une version abrégée (appelée fenêtre bascule) peut être utilisée, comme illustré dans l'exemple suivant.
var tumblingAgg = from w in inputStream.TumblingWindow(TimeSpan.FromHours(1))
select new { sum = w.Sum(e => e.i) };
L'alignement de la fenêtre récurrente (ou bascule) est un paramètre optionnel. Dans l'exemple suivant, chaque fenêtre commence et se termine à 9 heures, heure UTC (temps universel coordonné).
var alignment = new DateTime(TimeSpan.FromHours(9).Ticks, DateTimeKind.Utc);
var snapshotAgg = from w in inputStream.TumblingWindow(
TimeSpan.FromHours(24),
alignment,
HoppingWindowOutputPolicy.ClipToWindowEnd)
select new { sum = w.Sum(e => e.i) };
Voir aussi
Concepts
Agrégats et opérateurs définis par l'utilisateur