Latence dans Activator

Fabric Activator exécute des règles sur des données en temps réel. Les résultats sont quasi instantanés, mais différents facteurs peuvent introduire une latence. Dans la plupart des cas, vous ne remarquez pas cette latence, mais dans certains cas, cela peut être jusqu’à 10 minutes. La réception d’informations précises et opportunes est une considération importante dans la création et la réception des règles. Cet article passe en revue les processus et les paramètres qui déterminent l’équilibre entre l’inclusion d’événements et la structure de règles, ainsi que la rapidité avec laquelle Activateor envoie une activation. Par exemple, l’activateur doit-il autoriser l’arrivée et l’inclusion de données, ou l’activateur doit-il s’assurer que les destinataires reçoivent leurs alertes à un moment donné ? Et comment la structure des règles affecte-t-elle la vitesse à laquelle activateur envoie une activation aux destinataires ?

Trois facteurs importants affectent la latence d’activation des règles :

• Tolérance d’arrivée tardive.
• Latence de traitement du back-end.
• Latence d’agrégation.

Tolérance d’arrivée tardive

Dans les données de streaming, les événements n’arrivent pas toujours dans l’ordre ou à l’heure. L’heure d’événement d’un événement (lorsqu’il s’est produit) peut se trouver dans la fenêtre de temps d’une règle, mais son heure d’arrivée (lorsque l’activateur l’a reçu) peut se trouver en dehors de cette fenêtre, ce qui rend l’événement en retard. Par défaut, l'Activateur supprime les événements en retard de l’évaluation des règles.

Le temps d’attente pour les événements arrivés en retard contrôle la durée d’attente de l’activateur avant de fermer la fenêtre d’évaluation, ce qui donne aux événements en retard une chance d’arriver. Ce paramètre se trouve dans la section Paramètres avancés de l’écran Définition de règle. Pour savoir comment le configurer, consultez le paramètre de tolérance d’arrivée tardive.

Latence du traitement en arrière-plan

L’activateur peut avoir besoin de traiter une règle avant de l’activer, ce qui peut introduire un délai d’une minute maximum. Par exemple, si la règle se compare à un ensemble d’événements précédent, Activateur récupère les données précédentes, effectue la comparaison et calcule le résultat. Dans un autre exemple, si la règle s’exécute sur 10 millions de lignes de données, le traitement de ce volume par Activator introduit également une latence.

Latence d’agrégation

Si une agrégation est utilisée dans la définition de règle, la règle s’active uniquement lorsqu’elle termine la tâche liée aux fenêtres de temps spécifiées. Par exemple, supposons qu’une règle est générée pour moyenner les données sur quatre heures. Si un événement qui répond aux conditions de la règle est ingéré à 12 h, la règle se déclenche à 14 h. La latence est le résultat des paramètres d’agrégation. Même lorsqu’une règle inclut une simple agrégation, telle que moyenne, Activator ne peut pas envoyer d’activation tant qu’il n’a pas exécuté l’agrégation sur les données d’événement entrantes.

Concepts de base en matière de temps

Pour mieux cadrer la discussion, nous allons définir des concepts de temps en arrière-plan.

• Heure de l’événement : heure à laquelle l’événement d’origine s’est produit. Il fait partie de la charge utile de l'événement. Par exemple, le moment où un capteur détecte une voiture qui approche d’une cabine de péage est l’heure de l’événement.
• Temps de traitement : heure à laquelle le système de traitement reçoit et observe l’événement. Par exemple, après que le capteur de cabine de péage voit la voiture, l’heure à laquelle le système informatique reçoit et traite les informations du capteur est le temps de traitement.
• Heure d’arrivée (filigrane ou heure d'ingestion) : marqueur indiquant le moment où les données de l’événement atteignent Activator. Par nature des flux, les données d’événement entrantes ne s’arrêtent jamais, de sorte que les heures d’arrivée indiquent la progression effectuée par Activator à un certain point dans le flux. C’est à ce stade que l’Activator peut produire des résultats complets, corrects et reproductibles qui n’ont pas besoin d’être rétractés. C'est également à ce stade qu’Activator peut commencer à traiter les données. L’activateur traite les données de manière prévisible et reproductible. Par exemple, si Activator doit recompter des données pour la gestion des erreurs, il peut utiliser les temps d’arrivée comme points de départ et de fin sécurisés. Par exemple, une fois que le système de cabine de péage a reçu toutes les détections de voiture jusqu’à 9 h 05, le marqueur d’heure d’arrivée avance à 9 h 05. Toutes les détections qui arrivent après ce point ( même si l’heure de l’événement était antérieure à 9 h 05 ) sont en retard.

L’arrivée tardive se produit lorsqu’une règle a un paramètre d’heure et que l’heure de l’événement se trouve dans ce paramètre de temps, mais que l’heure d’arrivée tombe en dehors de celle-ci. À l’aide de l’exemple de stand de péage : le capteur détecte la voiture et l’heure de l’événement se situe dans la plage horaire de la règle. Toutefois, si le capteur prend trop de temps pour transmettre la détection( par exemple, en raison d’une congestion du réseau), l’événement arrive à Activateor une fois la fenêtre fermée. L’activateur considère cet événement en retard. Si vous souhaitez inclure des arrivées tardives, définissez le délai d’attente pour les événements arrivant en retard dans les paramètres Avancés.

Pour en savoir plus sur la sujet, consultez les billets du blog de Tyler Akidau Streaming 101 et Streaming 102 (en anglais).

Paramètre de tolérance d’arrivée tardive

Vous pouvez configurer le paramètre de tolérance d’arrivée tardive. La valeur par défaut est de deux minutes. Ce paramètre contribue à la latence. Les règles que vous créez avec un temps d’attente ont une latence minimale égale à la durée configurée. Lors de la création d’une règle, déterminez s’il faut utiliser la valeur par défaut ou la modifier. Le paramètre garantit que les événements en retard et les événements hors ordre ont la possibilité d’être inclus dans l’évaluation des règles. Si un événement se trouve en dehors de la tolérance d’arrivée tardive configurée, activateur ne le prend pas en compte. Tous les événements avec une heure d’arrivée après ce seuil ne sont pas pris en compte.

Dans l’ensemble, déterminez s’il est plus important de :

• d’attendre les points de données tardifs, ou
• Exécutez la règle sur des données potentiellement incomplètes afin que la règle s’active plus tôt. 

Dans cet exemple, les points de données sont mesurés par incréments de 15 minutes. Les trois premiers points, qui sont bleus, se situent dans la fenêtre temporelle. Le quatrième point, qui est orange, ne le fait pas. L’heure de l’événement est comprise dans l’intervalle de 15 minutes, mais l’événement n’est pas ingéré par Activator dans ce laps de temps. Activator n'évalue la règle que sur les données dont l'heure d'arrivée se situe dans la fenêtre de 15 minutes. Sauf si vous augmentez la tolérance d’arrivée tardive, les points de données qui arrivent après la fermeture de la fenêtre ne sont pas inclus.

L’activateur ne peut pas prendre en compte les retards de vos sources de données. Par exemple, vous pouvez avoir des capteurs IoT hors connexion pendant une heure. Une fois qu’ils reviennent en ligne, Activateur peut recevoir les données, mais les données ont été retardées pendant une heure à partir de cet état hors connexion, qui se produit en dehors de l’Activateur.

Voici un autre exemple.

Vous créez une règle qui calcule la température moyenne en intervalles de minute. Le temps d’attente pour les événements arrivant en retard est défini sur la valeur par défaut de deux minutes. L’activateur inclut les valeurs de température 20 et 30, et calcule une moyenne de 25. Toutefois, Activator n’inclut pas l’événement de 40 degrés qui arrive en retard avant l’activation de la règle suivante.

Règles basées sur des visuels Power BI

La latence intégrée diffère selon le service. La latence pour les flux d’événements diffère de la latence pour les visuels Power BI. Deux facteurs affectent la latence des règles basées sur des visuels Power BI : la fréquence d'interrogation des visuels Power BI intégrés au système et un délai que le back-end d'Activateor peut introduire.

Les règles Power BI sont évaluées à chaque fois que de nouvelles données arrivent dans Activator. Par défaut, l'Activateur interroge Power BI une fois par heure, ce qui signifie que les événements qui répondent à la condition de règle déclenchent une activation au plus une heure après l’événement. Vous pouvez modifier cette fréquence dans les paramètres de la source de données. Pour plus d’informations, consultez Fréquence des requêtes pour les sources de données et Créer des alertes Power BI et les affiner dans Fabric Activator.