TIMESTAMP BY (Azure Stream Analytics)

Artikel
07/12/2023

Aan alle gegevensstroom-gebeurtenissen is een tijdstempel gekoppeld. Gebeurtenissen van Event Hub en IoT Hub krijgen standaard een tijdstempel op basis van wanneer de gebeurtenis is ontvangen door de Event Hub of IoT Hub. Gebeurtenissen uit Blob Storage krijgen een tijdstempel op basis van de laatste wijzigingstijd van de blob. De tijdstempel van een gebeurtenis verandert niet als u de taak opnieuw start of uitvoert.

Veel streamingtoepassingen vereisen dat de exacte tijdstempel van een gebeurtenis wordt gebruikt in plaats van de aankomsttijd. In een Point-of-Sales-toepassing heeft u bijvoorbeeld mogelijk gebeurtenistijdstempels nodig die overeenkomen met het tijdstip waarop een betaling is geregistreerd, in plaats van het tijdstip waarop een betalingsgebeurtenis de service voor gebeurtenisopname bereikt. Daarnaast kunnen geografisch gedistribueerde systemen en netwerklatenties bijdragen aan onvoorspelbare aankomsttijden, waardoor het gebruik van een toepassingstijd betrouwbaarder wordt in een streamingtoepassing. Voor deze gevallen kunt u met de component TIMESTAMP BY aangepaste tijdstempelwaarden opgeven. De waarde kan elk veld zijn uit de nettolading van de gebeurtenis of expressie van het type DATETIME. Tekenreekswaarden die voldoen aan een van de ISO 8601-indelingen worden ook ondersteund.

Houd er rekening mee dat het gebruik van een aangepaste tijdstempel (TIMESTAMP BY-component) ertoe kan leiden dat Azure Stream Analytics gebeurtenissen niet op volgorde opneemt met betrekking tot hun tijdstempels om twee redenen:

Individuele gebeurtenisproducenten kunnen verschillende (en scheve) systeemklokken hebben.
Gebeurtenissen van individuele gebeurtenisproducenten kunnen tijdens de doorvoer worden vertraagd, bijvoorbeeld doordat het netwerk niet beschikbaar is op de locatie van de producent.

Hoewel de stoornis tussen gebeurtenisproducenten groot kan zijn, is de stoornis binnen de gebeurtenissen van één producent over het algemeen klein of zelfs niet aanwezig. Als een query alleen gegevens van elke gebeurtenisproducent afzonderlijk verwerkt, is het efficiënter om gebeurtenissen van elke producent in een eigen tijdlijn te verwerken dan het beheren van tijdsverschil tussen producenten. Azure Stream Analytics ondersteunt substromen door de subcomponent OVER <over spec> op te geven om de verwerking van gebeurtenissen in onafhankelijke tijdlijnen mogelijk te maken. Zie 'OVER-component communiceert met gebeurtenisvolgorde' voor de impact die het gebruik van de COMPONENT OVER heeft op de verwerking van de taak.

Syntaxis

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

Opmerkingen

Tijdstempel van gebeurtenis ophalen

Tijdstempel van gebeurtenissen kan worden opgehaald in de SELECT-instructie in elk deel van de query met behulp van de eigenschap System.Timestamp().

OVER-component communiceert met gebeurtenisvolgorde

Wanneer de COMPONENT OVER wordt gebruikt, worden verschillende aspecten van gebeurtenisverwerking door Azure Stream Analytics gewijzigd:

Maximale out-of-order tolerantie wordt toegepast binnen een tuple van één waarde van <over spec>. Dat wil dus dat een gebeurtenis alleen als buiten orde wordt beschouwd als deze te veel in de juiste volgorde aankomt ten opzichte van andere gebeurtenissen van dezelfde gebeurtenisproducent.

Een waarde van '0' kan bijvoorbeeld worden gebruikt als gebeurtenissen van dezelfde gebeurtenisproducent altijd worden besteld en leiden tot onmiddellijke verwerking. Aan de andere kant leidt het gebruik van grote waarden tot vertragingen in de verwerking, terwijl wordt gewacht tot de out-of-order-gebeurtenissen zijn geassembleerd.
De maximale tolerantie voor late aankomst wordt globaal toegepast (alsof OVER niet is gebruikt). Dat wil dat een gebeurtenis als laat binnenkomt wordt beschouwd als de gekozen tijdstempel (in de TIMESTAMP BY-component) te ver terug ligt van de aankomsttijd.

Houd er rekening mee dat het gebruik van grote waarden hier geen verwerkingsvertragingen veroorzaakt en dat gebeurtenissen nog steeds onmiddellijk worden verwerkt (of volgens de maximale out-of-order-tolerantie). Een waarde van meerdere dagen is niet onredelijk. Het gebruik van uitzonderlijk lange waarden kan echter van invloed zijn op de hoeveelheid geheugen die nodig is om de taak te verwerken.
Uitvoergebeurtenissen voor elke gebeurtenisproducent worden gegenereerd terwijl ze worden berekend, wat betekent dat de uitvoergebeurtenissen tijdstempels kunnen hebben die niet op volgorde zijn; Ze zijn echter op volgorde binnen een tuple van één waarde van <over spec>.

Beperkingen en beperkingen

De component TIMESTAMP BY OVER heeft de volgende gebruiksbeperkingen:

DE TIMESTAMP BY OVER-component moet worden gebruikt voor alle invoer van de query of niet voor een van deze items.
De component TIMESTAMP BY OVER wordt alleen ondersteund met volledig parallelle taken of taken met één partitie.
Als de invoerstroom meer dan één partitie heeft, moet de component OVER samen met de component PARTITION BY worden gebruikt. De kolom PartitionId moet worden opgegeven als onderdeel van de kolommen TIMESTAMP BY OVER.
Als de TIMESTAMP BY OVER-component wordt gebruikt, moeten kolomnamen uit de component worden gebruikt als groeperingssleutel in GROUP BY-instructies en in alle JOIN-predicaten bij het samenvoegen tussen streams.
Kolommen die zijn gemaakt in een SELECT-instructie of in andere querycomponenten, kunnen niet worden gebruikt in de component TIMESTAMP BY. Er moet een veld uit de nettolading van de invoer worden gebruikt. Het resultaat van een CROSS APPLY kan bijvoorbeeld niet worden gebruikt als de doelwaarde van de TIMESTAMP BY. U kunt echter één Azure Stream Analytics-taak gebruiken waarmee cross apply wordt uitgevoerd en een tweede taak gebruiken om de TIJDSTEMPEL BY uit te voeren.
System.Timestamp() kan niet worden gebruikt in TIMESTAMP BY, omdat TIMESTAMP BY de waarde van System.Timestamp() bepaalt.

Voorbeelden

Voorbeeld 1: een tijdstempelveld openen vanuit de nettolading

Veld uit de nettolading gebruiken EntryTime als tijdstempel voor gebeurtenissen

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime

Voorbeeld 2: UNIX-tijd uit de nettolading gebruiken als tijdstempel van gebeurtenissen

UNIX-systemen gebruiken vaak POSIX-tijd (of Epoch) die is gedefinieerd als het aantal milliseconden dat is verstreken sinds 00:00:00 Coordinated Universal Time (UTC), donderdag 1 januari 1970.

In dit voorbeeld ziet u hoe u een numeriek veld 'epochtime' gebruikt met Epoch-tijd als tijdstempel voor gebeurtenissen.

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

Voorbeeld 3: Heterogene tijdstempels

Stel dat u heterogene gegevensstromen verwerkt die twee typen gebeurtenissen 'A' en 'B' bevatten. Gebeurtenissen 'A' hebben tijdstempelgegevens in het veld 'timestampA' en gebeurtenissen 'B' hebben tijdstempel in het veld 'timestampB'.

In dit voorbeeld ziet u hoe u TIMESTAMP BY schrijft om te kunnen werken met beide typen gebeurtenissen/tijdstempels.

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

Voorbeeld 4: meerdere tijdlijnen in een gepartitioneerde query verwerken

Gegevens van verschillende afzenders (tolstations) verwerken zonder tijdbeleid toe te passen op verschillende tolstation-id's. De invoergegevens worden gepartitioneerd op basis van TollId.

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

Zie ook

System.Timestamp()
Belijd voor tijd scheeftrekken
Inzicht in tijdafhandeling in Azure Stream Analytics
Unix-tijd