Beleid voor tijdsverschil (Azure Stream Analytics)

Aan alle gebeurtenissen in Stream Analytics is een tijdstempel gekoppeld. Gebruikers kunnen het trefwoord TIMESTAMP BY gebruiken om te kiezen tussen een van deze twee verschillende tijden:

• Toepassingstijd, dat wil zeggen de tijd waarop de gebeurtenissen worden geproduceerd (zoals aangegeven door de toepassing/het apparaat dat de gebeurtenissen genereert). Wanneer u toepassingstijd gebruikt, kunt u alle gebeurtenissen verwerken met behulp van een globale tijdlijn of elk apparaat/partitie analyseren met behulp van een eigen tijdlijn met behulp van substreams;
• Aankomsttijd, het tijdstip waarop het evenement de cloud heeft bereikt (bijvoorbeeld aankomsttijd in IoT Hub of Event Hub).

Naast de keuze van tijdstempels moeten gebruikers mogelijk het beleid voor late aankomst en niet-order definiëren vanwege de volgende problemen:

• Producenten van de gebeurtenissen hebben een asymmetrische klok. Dit is gebruikelijk wanneer producenten van verschillende machines zijn, dus ze hebben verschillende klokken.
• Vanwege netwerklatentie kunnen gebeurtenissen die afkomstig zijn van dezelfde klok, in Event Hub aankomen of IoT Hub in een andere volgorde dan wanneer ze zijn ontstaan
• Klokscheefheid tussen partities. Wanneer u niet-gepartitioneerde query's gebruikt, worden gebeurtenissen van alle partities samengevoegd door de tijdstempel van de keuze van de gebruiker. Scheeftrekken van de klok tussen de partities kunnen leiden tot vertraging van de verwerking, omdat de fusie moet wachten op de langzaamste partitie.

Invoerstromen die niet in de volgorde staan, kunnen een van de volgende zijn:

• Gesorteerd (en dus vertraagd).
• Aangepast door het systeem, volgens het door de gebruiker opgegeven beleid.

Stream Analytics tolereert gebeurtenissen die te laat en niet op volgorde zijn bij het verwerken per toepassingstijd.

Beleid voor niet-order

Het is erg belangrijk om gebeurtenissen op tijd te laten sorteren in streaminganalyses. Vanwege de drie hierboven genoemde problemen is het echter vaak zo dat ze niet op volgorde worden ontvangen, wat van invloed kan zijn op de resultaten van onze query's. Met het beleid voor niet-uitgevoerde bestellingen kunnen gebeurtenissen opnieuw worden gerangschikt op tijdstempel wanneer ze binnenkomen binnen het gedefinieerde tolerantievenster. Gebeurtenissen die later binnenkomen dan de tolerantie, worden verwijderd of aangepast, afhankelijk van de instelling die u kiest.

• Aangepast: aangepast om te lijken te zijn aangekomen op het laatste acceptabele tijdstip.
• Verwijderd: verwijderd.

Deze instelling kan worden aangepast in de Azure Portal (op het tabblad 'Gebeurtenisvolgorde' van een taak). Raadpleeg de pagina overwegingen voor gebeurtenisvolgorde voor meer informatie.

Bij het instellen van een niet-op-volgordebeleid groter dan 0, buffert Stream Analytics gebeurtenissen tot aan dat venster en rangschikt ze opnieuw met behulp van de door de gebruiker gedefinieerde tijdstempel voordat de tijdelijke transformatie wordt toegepast. Over het algemeen is het een goed idee om eerst te beginnen met een venster van 3 seconden en vervolgens de waarde af te stemmen om het aantal gebeurtenissen te verminderen dat de tijd wordt aangepast. Houd er rekening mee dat vanwege de buffering het neveneffect is dat de uitvoer met dezelfde hoeveelheid tijd wordt vertraagd. Als gevolg hiervan moet u de waarde afstemmen om het aantal niet-op-volgorde-gebeurtenissen te verminderen en de latentie laag te houden.

Tolerantie voor late aankomst

Het tolerantievenster voor late aankomst wordt gebruikt om rekening te houden met vertraging in gebeurtenissen die de invoerbron bereiken om verschillende redenen die hierboven worden beschreven. Kortom, het venster late aankomst is de maximale vertraging tussen het genereren en ontvangen van de gebeurtenis bij de invoerbron. Aanpassing op basis van tolerantie voor late aankomst wordt eerst uitgevoerd en vervolgens buiten de volgorde. Aan de kolom System.Timestamp() wordt de uiteindelijke tijdstempel toegewezen aan de gebeurtenis.

Deze instelling is alleen van toepassing bij verwerking door toepassingstijd, anders wordt deze genegeerd. Het kan ook worden ingesteld in de Azure Portal (op het tabblad 'Gebeurtenisvolgorde' van een taak). Raadpleeg de pagina overwegingen voor gebeurtenisvolgorde voor meer informatie.

Wanneer een gebeurtenis te laat is, wordt het tijdstempel aangepast aan de huidige tijd in de wachtrij bij de invoerbron minus het tolerantievenster voor late aankomst (of verwijderd, afhankelijk van de gekozen actie). Wanneer meerdere partities uit dezelfde invoerstroom of meerdere invoerstromen worden gecombineerd, is tolerantie voor late aankomst de maximale hoeveelheid tijd die elke partitie wacht op nieuwe gegevens.

Tolerantie voor late aankomst en Sparse-gebeurtenissen

Met het beleid voor late aankomst kan Stream Analytics de tijd vooruit verplaatsen en op een tijdige manier uitvoer genereren zonder invoer gebeurtenissen. Dit is zeer handig wanneer invoergebeurtenissen schaars zijn (of helemaal niet worden ontvangen in sommige Van de Event Hub-partities).

Invoer gebeurtenissen worden bijvoorbeeld eenmaal per minuut gegenereerd voor een select*-query. Zonder dit beleid kan Stream Analytics geen uitvoerresultaten genereren totdat gebeurtenissen bij alle Event Hub-partities aankomen (om de tijd vooruit te verplaatsen). Dit kan 16 minuten betekenen als de Event Hub 16 partities heeft en dat elke gebeurtenis wordt geleverd aan een andere partitie. Met het standaardbeleid van 5 seconden wordt de klok 5 seconden na de eerste gebeurtenis naar voren verplaatst, zodat de uitvoer-gebeurtenis 5 seconden na de eerste gebeurtenis wordt gegenereerd.

Zie ook

Tijdbeheer (Azure Stream Analytics)
System.Timestamp() (Stream Analytics)
TIMESTAMP BY (Azure Stream Analytics)
Overweging van gebeurtenisvolgorde