TIMESTAMP BY

✅ Azure Stream Analytics

Tous les événements de flux de données ont un horodatage associé. Par défaut, les événements d’Event Hub et d’IoT Hub sont horodatés en fonction du moment où l’événement a été reçu par event Hub ou IoT Hub ; les événements du stockage Blob sont horodatés par l’heure de dernière modification de l’objet blob. L’horodatage d’un événement ne change pas si vous relancez ou réexécutez votre travail.

De nombreuses applications de diffusion en continu nécessitent l’utilisation de l’horodatage exact qu’un événement s’est produit, plutôt que l’heure d’arrivée. Par exemple, dans une application point de vente, un horodatage d’événements peut nécessiter des horodatages d’événements correspondant au moment où un paiement a été enregistré, plutôt que le moment où un événement de paiement atteint le service d’ingestion d’événement. En outre, les systèmes géo-distribués et les latences réseau peuvent contribuer aux heures d’arrivée imprévisibles, ce qui rend l’utilisation d’une heure d’application plus fiable dans une application de diffusion en continu. Dans ce cas, la clause TIMESTAMP BY permet de spécifier des valeurs d’horodatage personnalisées. La valeur peut être n’importe quel champ de la charge utile d’événement ou de l’expression de type DATETIME. Les valeurs de chaîne conformes à l’un des formats ISO 8601 sont également prises en charge.

Notez que l’utilisation d’un horodatage personnalisé (clause TIMESTAMP BY) peut entraîner l’ingestion d’événements par Azure Stream Analytics par rapport à leurs horodatages pour deux raisons :

Les producteurs d’événements individuels peuvent avoir des horloges système différentes (et asymétriques).
Les événements des producteurs d’événements individuels peuvent être retardés en transit, par exemple par indisponibilité du réseau sur le site du producteur.

Bien que le trouble entre les producteurs d’événements puisse être important, le trouble dans les événements d’un seul producteur est généralement petit ou même inexistant. Si une requête traite uniquement les données de chaque producteur d’événements indépendamment, la gestion des événements de chaque producteur dans sa propre chronologie est plus efficace que la gestion des asymétries temporelles entre les producteurs. Azure Stream Analytics prend en charge les sous-flux en spécifiant OVER <sur la sous-clause de spécification> pour permettre le traitement des événements dans des chronologies indépendantes. Consultez « OVER clause interagit avec l’ordre des événements » pour l’impact de l’utilisation de la clause OVER sur le traitement du travail.

Syntax

TIMESTAMP BY scalar_expression [OVER <over spec> ]  
      
<over spec> ::= 
      { column_name | expression } [,...n ]

Remarks

Récupération de l’horodatage d’événements

L’horodatage d’événement peut être récupéré dans l’instruction SELECT dans n’importe quelle partie de la requête à l’aide de la propriété System.Timestamp().

La clause OVER interagit avec l’ordre des événements

Lorsque la clause OVER est utilisée, plusieurs aspects du traitement des événements par Azure Stream Analytics sont modifiés :

La tolérance maximale hors ordre est appliquée dans un tuple de valeur unique de <surspec>. Autrement dit, un événement est considéré comme hors de commande uniquement s’il arrive trop d’ordre par rapport à d’autres événements du même producteur d’événements.

Par exemple, une valeur de « 0 » peut être utilisée si les événements du même producteur d’événements sont toujours ordonnés et entraînent un traitement immédiat. En revanche, l’utilisation de valeurs volumineuses ici introduit des retards de traitement, tout en attendant que les événements hors commande s’assemblent.
La tolérance maximale d’arrivée tardive est appliquée globalement (comme si OVER n’a pas été utilisé). Autrement dit, un événement est considéré comme arrivant en retard si son horodatage choisi (dans la clause TIMESTAMP BY) est trop loin de son heure d’arrivée.

Notez que l’utilisation de valeurs volumineuses ici n’introduit pas de retards de traitement et les événements seront toujours traités immédiatement (ou selon la tolérance maximale hors ordre). Une valeur de plusieurs jours n’est pas déraisonnable. Toutefois, l’utilisation de valeurs exceptionnellement longues peut avoir un impact sur la quantité de mémoire requise pour traiter le travail.
Les événements de sortie pour chaque producteur d’événements sont générés au fur et à mesure qu’ils sont calculés, ce qui signifie que les événements de sortie peuvent avoir des horodatages obsolètes ; toutefois, ils seront dans l’ordre dans un tuple de valeur unique de <surspec>.

Limitations et restrictions

La clause TIMESTAMP BY OVER présente les limitations suivantes de l’utilisation :

La clause TIMESTAMP BY OVER doit être utilisée pour toutes les entrées de la requête ou non utilisées pour celles-ci.
La clause TIMESTAMP BY OVER est prise en charge uniquement avec des travaux entièrement parallèles ou des travaux de partition unique.
Si le flux d’entrée a plusieurs partitions, la clause OVER doit être utilisée avec la clause PARTITION BY. La colonne PartitionId doit être spécifiée dans le cadre des colonnes TIMESTAMP BY OVER.
Si la clause TIMESTAMP BY OVER est utilisée, les noms de colonnes de la clause doivent être utilisés comme clé de regroupement dans les instructions GROUP BY et dans tous les prédicats JOIN lors de la jonction entre les flux.
Les colonnes créées dans une instruction SELECT ou dans d’autres clauses de requête ne peuvent pas être utilisées dans la clause TIMESTAMP BY, un champ de la charge utile d’entrée doit être utilisé. Par exemple, le résultat d’une application CROSS APPLY ne peut pas être utilisé comme valeur cible du TIMESTAMP BY. Toutefois, vous pouvez utiliser un travail Azure Stream Analytics qui effectue CROSS APPLY et utiliser un deuxième travail pour effectuer le TIMESTAMP BY.
System.Timestamp() ne peut pas être utilisé dans TIMESTAMP BY, car TIMESTAMP BY est ce qui établit la valeur de System.Timestamp().

Examples

Exemple 1 : accéder à un champ d’horodatage à partir de la charge utile

Utiliser EntryTime le champ de la charge utile comme horodatage d’événement

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

Exemple 2 : utiliser l’heure UNIX de la charge utile comme horodatage d’événement

Les systèmes UNIX utilisent souvent l’heure POSIX (ou époque) définie comme le nombre de millisecondes écoulées depuis 00:00:00 Temps universel coordonné (UTC), jeudi 1er janvier 1970.

Cet exemple montre comment utiliser le champ numérique « époquetime » contenant l’heure de l’époque en tant qu’horodatage d’événement.

SELECT  
      System.Timestamp(),  
      LicensePlate,  
      State  
FROM input TIMESTAMP BY DATEADD(millisecond, epochtime, '1970-01-01T00:00:00Z')

Exemple 3 : horodatages hétérogènes

Imaginez le traitement de flux hétérogènes de données contenant deux types d’événements « A » et « B ». Les événements « A » ont des données d’horodatage dans le champ « timestampA » et les événements « B » ont un horodatage dans le champ « timestampB ».

Cet exemple montre comment écrire TIMESTAMP BY pour pouvoir utiliser les deux types d’événements/horodatages.

SELECT  
      System.Timestamp(),  
      eventType,  
      eventValue,  
FROM input TIMESTAMP BY  
      (CASE eventType   
            WHEN 'A' THEN timestampA  
            WHEN 'B' THEN timestampB  
      ELSE NULL END)

Exemple 4 : gestion de plusieurs chronologies dans une requête partitionnée

Traitez les données de différents expéditeurs (stations de péage) sans appliquer de stratégies de temps sur différents ID de station de péage. Les données d’entrée sont partitionnée en fonction de TollId.

SELECT
      TollId,
      COUNT(*) AS Count
FROM input
      TIMESTAMP BY EntryTime OVER TollId, PartitionId
      PARTITION BY PartitionId
GROUP BY TUMBLINGWINDOW(minute,3), TollId, PartitionId

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-07-10