TIJDSTEMPEL PER

✅ Azure Stream Analytics ✅ Fabric Eventstream

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

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

Het gebruik van een aangepaste tijdstempel (TIMESTAMP BY-component) kan ertoe leiden dat Azure Stream Analytics om twee redenen gebeurtenissen in de volgorde opneemt met betrekking tot hun tijdstempels:

• Individuele gebeurtenisproducenten kunnen verschillende (en scheve) systeemklokken hebben.
• Gebeurtenissen van individuele gebeurtenisproducenten kunnen tijdens de overdracht worden vertraagd, bijvoorbeeld door de netwerkbeschikbaarheid 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-bestaand. Als een query alleen gegevens van elke gebeurtenisproducent onafhankelijk verwerkt, is het afhandelen van gebeurtenissen van elke producent in een eigen tijdlijn efficiënter dan het beheren van tijdsverschil tussen producenten. Azure Stream Analytics biedt ondersteuning voor substromen door OVER-subclause <> op te geven om het verwerken van gebeurtenissen in onafhankelijke tijdlijnen mogelijk te maken. Zie 'OVER-component communiceert met gebeurtenisvolgorde' voor de impact die het gebruik van de OVER-component heeft op de verwerking van de taak.

Syntax

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

Remarks

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 OVER-component wordt gebruikt, worden verschillende aspecten van gebeurtenisverwerking door Azure Stream Analytics gewijzigd:

1. De maximale out-of-ordertolerantie wordt toegepast binnen één waarde tuple van <overspecificatie>. Dat wil gezegd, een gebeurtenis wordt alleen buiten orde beschouwd als deze te veel uit orde komt ten opzichte van andere gebeurtenissen van dezelfde gebeurtenisproducent.

   Een waarde van '0' kan bijvoorbeeld worden gebruikt als gebeurtenissen van dezelfde gebeurtenisproducent altijd worden geordend en resulteert in onmiddellijke verwerking. Aan de andere kant introduceert het gebruik van grote waarden hier verwerkingsvertragingen, terwijl wordt gewacht tot de out-of-ordergebeurtenissen worden geassembleerd.

2. Maximale tolerantie voor late aankomst wordt globaal toegepast (alsof OVER niet is gebruikt). Dat wil gezegd: een gebeurtenis wordt beschouwd als laat aankomend als de gekozen tijdstempel (in de TIMESTAMP BY-component) te ver terug is van de aankomsttijd.

   Als u grote waarden hier gebruikt, worden verwerkingsvertragingen niet geïntroduceerd en worden gebeurtenissen nog steeds onmiddellijk verwerkt (of volgens de maximale out-of-ordertolerantie). Een waarde van meerdere dagen is niet onredelijk. Het gebruik van uitzonderlijk lange waarden kan echter invloed hebben op de hoeveelheid geheugen die nodig is om de taak te verwerken.

3. Uitvoergebeurtenissen voor elke gebeurtenisproducent worden gegenereerd wanneer ze worden berekend, wat betekent dat de uitvoergebeurtenissen mogelijk out-of-order timestamps hebben; ze zijn echter in volgorde binnen één waarde tuple van <overspecificatie>.

Beperkingen en beperkingen

De TIMESTAMP BY OVER-component heeft de volgende beperkingen van het gebruik:

1. De TIMESTAMP BY OVER-component moet worden gebruikt voor alle invoer van de query of niet voor een van deze invoer.

2. TIMESTAMP BY OVER-component wordt alleen ondersteund met volledig parallelle taken of taken met één partitie.

3. Als de invoerstroom meer dan één partitie heeft, moet de OVER-component samen met de PARTITION BY-component worden gebruikt. De kolom PartitionId moet worden opgegeven als onderdeel van TIMESTAMP BY OVER-kolommen.

4. 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.

5. Kolommen die zijn gemaakt in een SELECT-instructie of in andere querycomponenten, kunnen niet worden gebruikt in de TIMESTAMP BY-component. Er moet een veld van de invoerpayload 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 die de CROSS APPLY uitvoert en een tweede taak gebruiken om de TIMESTAMP BY uit te voeren.

6. System.Timestamp() kan niet worden gebruikt in TIMESTAMP BY, omdat TIMESTAMP BY de waarde van System.Timestamp() bepaalt.

Examples

Voorbeeld 1: een tijdstempelveld openen vanuit de nettolading

Veld EntryTime van de nettolading gebruiken als tijdstempel van gebeurtenissen

SELECT  
      EntryTime,  
      LicensePlate,  
      State   
FROM input TIMESTAMP BY EntryTime  

Voorbeeld 2: UNIX-tijd van 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:00 Coordinated Universal Time (UTC), donderdag 1 januari 1970.

In dit voorbeeld ziet u hoe u een numeriek epochtime veld gebruikt dat tijdsduur van epoch bevat als tijdstempel van 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 soorten 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 met beide typen gebeurtenissen/tijdstempels te kunnen werken.

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 verwerken in een gepartitioneerde query

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()
Beleid voor tijdverschil
Inzicht in de verwerking van tijd in Azure Stream Analytics
Unix-tijd