Partager via

Stratégies d’asymétrie temporelle (Azure Stream Analytics)

  • Article

Dans Stream Analytics, un horodatage est associé à tous les événements de flux de données. Les utilisateurs peuvent utiliser le mot clé TIMESTAMP BY pour choisir entre l’une de ces deux heures différentes :

  • Heure de l’application, c’est-à-dire l’heure à laquelle les événements sont produits (comme indiqué par l’application/l’appareil qui génère les événements). Lorsque vous utilisez l’heure de l’application, vous pouvez traiter tous les événements à l’aide d’une chronologie globale ou analyser chaque appareil/partition à l’aide de ses propres chronologie à l’aide de sous-flux ;
  • Heure d’arrivée, heure à laquelle l’événement a atteint le cloud (par exemple, l’heure d’arrivée dans IoT Hub ou Event Hub).

En plus du choix de l’horodatage, les utilisateurs peuvent avoir besoin de définir une stratégie d’arrivée tardive et de désordre en raison des problèmes suivants :

  • Les producteurs des événements ont des asymétries d’horloge. Cela est courant lorsque les producteurs proviennent de machines différentes, de sorte qu’ils ont des horloges différentes.
  • En raison de la latence du réseau, les événements proviennent de la même horloge peuvent arriver à Event Hub ou IoT Hub dans un ordre différent de leur origine
  • Décalages d’horloge entre les partitions. Lorsque vous utilisez des requêtes non partitionnée, les événements de toutes les partitions sont fusionnés par l’horodatage du choix de l’utilisateur. Les décalages d’horloge entre les partitions peuvent entraîner un retard de traitement, car la fusion doit attendre la partition la plus lente.

Les flux d’entrée qui ne sont pas dans l’ordre peuvent être :

  • Trié (et donc différé).
  • Ajustés par le système, en fonction de la stratégie spécifiée par l’utilisateur.

Stream Analytics tolère les événements tardifs et en désordre lors du traitement selon l’heure de l’application.

Stratégie d’désordre

Il est très important de disposer d’événements classés par heure dans l’analytique de streaming. Toutefois, en raison des 3 problèmes mentionnés ci-dessus, il est souvent le cas qu’ils sont reçus dans le désordre, ce qui peut affecter les résultats de nos requêtes. La stratégie d’désordre permet de réorganiser les événements par horodatage lorsqu’ils arrivent dans la fenêtre de tolérance définie. Les événements qui arrivent après la tolérance sont supprimés ou ajustés, selon le paramètre que vous choisissez.

  • Ajustés : les événements sont ajustés de façon à ce qu’ils semblent arrivés à l’heure la plus récente acceptable.
  • Supprimés : ignorés.

Ce paramètre peut être ajusté dans le Portail Azure (sous l’onglet « Ordre des événements » d’un travail). Pour plus d’informations, reportez-vous à la page considérations relatives à l’ordre des événements.

Lors de la définition d’une stratégie d’désordre supérieure à 0, Stream Analytics met en mémoire tampon les événements jusqu’à cette fenêtre et les réorganise à l’aide de l’horodatage défini par l’utilisateur avant d’appliquer la transformation temporelle. En règle générale, commencer par une fenêtre de 3 secondes est une bonne pratique, puis régler la valeur pour réduire le nombre d’événements dont le temps est ajusté. Notez qu’en raison de la mise en mémoire tampon, l’effet secondaire est que la sortie est retardée du même temps. Par conséquent, vous devez régler la valeur pour réduire le nombre d’événements hors service et maintenir une latence faible.

Tolérance d’arrivée tardive

La fenêtre de tolérance d’arrivée tardive est utilisée pour tenir compte du retard dans les événements atteignant la source d’entrée pour diverses raisons décrites ci-dessus. En bref, la plage d’arrivée tardive correspond au délai maximal entre la génération de l’événement et la réception de l’événement au niveau de la source d’entrée. Un ajustement en fonction de la tolérance d’arrivée tardive est effectué en premier, puis un ajustement en fonction des événements en désordre. L’horodatage final est affecté à la colonne System.Timestamp() à l’événement.

Ce paramètre est applicable uniquement lors d’un traitement par heure de l’application, sinon il est ignoré. Il peut également être défini dans le Portail Azure (sous l’onglet « Ordre des événements » d’un travail). Pour plus d’informations, reportez-vous à la page considérations relatives à l’ordre des événements.

Lorsqu’un événement est en retard, son horodatage est ajusté à l’heure de mise en file d’attente actuelle au niveau de la source d’entrée moins la fenêtre de tolérance d’arrivée tardive (ou supprimée, selon l’action choisie). Lorsque plusieurs partitions du même flux d’entrée ou de plusieurs flux d’entrée sont combinées, la tolérance d’arrivée tardive correspond au délai d’attente maximal des nouvelles données pour chaque partition.

Tolérance d’arrivée tardive et événements partiellement alloués

La stratégie d’arrivée tardive permet à Stream Analytics de faire avancer le temps et de générer une sortie plus rapide en l’absence d’événements d’entrée. Cela est très utile lorsque les événements d’entrée sont partiellement alloués (ou ne sont pas reçus du tout dans certaines partitions Event Hub).

Par exemple, les événements d’entrée sont générés une fois par minute pour une requête select*. Sans utiliser cette stratégie, Stream Analytics ne peut pas générer de résultats de sortie tant que les événements n’arrivent pas sur toutes les partitions Event Hub (pour avancer l’heure). Cela peut signifier 16 minutes si le hub d’événements a 16 partitions et que chaque événement est remis à une partition différente. Avec la stratégie de 5 secondes par défaut, l’horloge avance de 5 secondes après le premier événement, de sorte que l’événement de sortie est généré 5 secondes après le premier événement.

Voir aussi

Gestion du temps (Azure Stream Analytics)
System.Timestamp() (Stream Analytics)
TIMESTAMP BY (Azure Stream Analytics)
Considérations relatives à l’ordre des événements