TIMESTAMP BY (Azure Stream Analytics)
Un horodatage est associé à tous les événements de flux de données. Par défaut, les événements d’Event Hub et de IoT Hub sont horodatés en fonction du moment où l’événement a été reçu par le hub d’événements ou IoT Hub ; les événements du stockage Blob sont horodatés par l’heure de la 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 auquel un événement s’est produit, plutôt que l’heure d’arrivée. Par exemple, dans une application Point of Sales, il peut être nécessaire d’horodatages d’événements correspondant à l’heure à laquelle un paiement a été enregistré, plutôt qu’à l’heure à laquelle un événement de paiement atteint le service d’ingestion d’événement. En outre, les systèmes géodistribués et les latences réseau peuvent contribuer à des heures d’arrivée imprévisibles, ce qui rend l’utilisation d’une heure d’application plus fiable dans une application de streaming. 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 ou de l’expression d’événement 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 amener Azure Stream Analytics à ingérer des événements dans le désordre 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 en raison de l’indisponibilité du réseau sur le site du producteur.
Bien que le désordre entre les producteurs d’événements puisse être important, le désordre au sein des événements d’un seul producteur est généralement faible, voire 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 son 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 <over spec> sous-clause pour activer le traitement des événements dans des chronologies indépendantes. Consultez « La clause OVER interagit avec l’ordre des événements » pour connaître l’impact de l’utilisation de la clause OVER sur le traitement du travail.
Syntaxe
TIMESTAMP BY scalar_expression [OVER <over spec> ]
<over spec> ::=
{ column_name | expression } [,...n ]
Notes
Récupération de l’horodatage de l’événement
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 d’désordre est appliquée dans un tuple de valeur unique de plus de <spécifications>. Autrement dit, un événement n’est considéré comme non conforme que s’il arrive trop en désordre par rapport à d’autres événements du même producteur d’événements.
Par instance, la valeur « 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. D’autre part, l’utilisation de valeurs élevées ici introduit des retards de traitement, tout en attendant que les événements hors ordre s’assemblent.
La tolérance maximale d’arrivée tardive est appliquée globalement (comme si OVER n’était pas utilisé). Autrement dit, un événement est considéré comme arrivant en retard si son horodatage choisi (dans la clause TIMESTAMP BY) est trop éloigné de son heure d’arrivée.
Notez que l’utilisation de valeurs élevées ici n’entraîne pas de retards de traitement et que les événements sont toujours traités immédiatement (ou en fonction de la tolérance maximale d’désordre). 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 en désordre ; toutefois, ils seront dans l’ordre dans un tuple de valeur unique de plus de <spécification>.
Limitations et restrictions
La clause TIMESTAMP BY OVER présente les limitations d’utilisation suivantes :
La clause TIMESTAMP BY OVER doit être utilisée pour toutes les entrées de la requête ou ne doit pas être utilisée pour l’une d’entre elles.
La clause TIMESTAMP BY OVER est uniquement prise en charge avec des travaux entièrement parallèles ou des travaux à partition unique.
Si le flux d’entrée comporte 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 jointure entre des 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’un CROSS APPLY ne peut pas être utilisé comme valeur cible du TIMESTAMP BY. Toutefois, vous pouvez utiliser un travail Azure Stream Analytics qui effectue la commande CROSS APPLY et un deuxième travail pour effectuer l’opération TIMESTAMP BY.
System.Timestamp() ne peut pas être utilisé dans TIMESTAMP BY, car TIMESTAMP BY est ce qui établit la valeur de System.Timestamp().
Exemples
Exemple 1 : accéder à un champ timestamp à 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 qui se sont écoulées depuis 00:00:00 UTC (Temps universel coordonné), jeudi 1er janvier 1970.
Cet exemple montre comment utiliser un champ numérique « epochtime » contenant l’heure d’époque comme 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és 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
Voir aussi
System.Timestamp()
Stratégies d’asymétrie temporelle
Comprendre la gestion du temps dans Azure Stream Analytics
Heure Unix