Beleid voor tijdsafwijking

✅ Azure Stream Analytics

Aan alle gegevensstroom-gebeurtenissen 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 gemarkeerd 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/elke partitie analyseren met behulp van een eigen tijdlijn met behulp van substromen;
• Aankomsttijd, het tijdstip waarop de gebeurtenis de cloud heeft bereikt (bijvoorbeeld de aankomsttijd in IoT Hub of Event Hub).

Naast de keuze van de tijdstempel moeten gebruikers mogelijk beleid voor late aankomst en niet-uitgevoerde volgorde definiëren vanwege de volgende problemen:

• Producenten van de gebeurtenissen hebben scheeftrekken van de klok. Dit komt vaak voor wanneer producenten afkomstig zijn van verschillende machines, zodat ze verschillende klokken hebben.
• Vanwege netwerklatentie kunnen gebeurtenissen afkomstig zijn van dezelfde klok in Event Hub of IoT Hub in een andere volgorde dan wanneer ze afkomstig zijn
• Klok scheeftrekken tussen partities. Wanneer u niet-gepartitioneerde query's gebruikt, worden gebeurtenissen van alle partities samengevoegd door de tijdstempel van de keuze van de gebruiker. Klokverschil tussen de partities kan leiden tot vertraging van de verwerking, omdat de fusie moet wachten op de langzaamste partitie.

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

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

Stream Analytics tolereert late en out-of-order-gebeurtenissen wanneer deze worden verwerkt op toepassingstijd.

Beleid buiten orde

Het is erg belangrijk om gebeurtenissen op tijd te orden in streaminganalyses. Vanwege de drie hierboven genoemde problemen is het echter vaak het geval dat ze buiten orde worden ontvangen, wat van invloed kan zijn op de resultaten van onze query's. Met het beleid Buiten bestelling kunt u gebeurtenissen opnieuw ordenen op tijdstempel wanneer ze binnenkomen in het gedefinieerde tolerantievenster. Gebeurtenissen die later binnenkomen dan 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.
• Dropped: Discarded.

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

Bij het instellen van een out-of-orderbeleid dat groter is dan 0, buffert Stream Analytics gebeurtenissen tot dat venster en rangschikt deze met behulp van de door de gebruiker gedefinieerde tijdstempel voordat de tijdelijke transformatie wordt toegepast. Over het algemeen is beginnen met een eerste venster van 3 seconden een goede procedure en vervolgens de waarde af te stemmen om het aantal gebeurtenissen dat wordt aangepast, te verminderen. Houd er rekening mee dat vanwege de buffering het neveneffect de uitvoer met dezelfde tijd wordt vertraagd. Als gevolg hiervan moet u de waarde afstemmen om het aantal gebeurtenissen buiten de volgorde te verminderen en de latentie laag te houden.

Tolerantie voor late aankomst

Het venster voor tolerantie voor late aankomst wordt gebruikt om rekening te houden met vertraging in gebeurtenissen die de invoerbron bereiken vanwege verschillende redenen die hierboven worden beschreven. Kort gezegd is het venster voor late aankomst de maximale vertraging tussen het genereren van gebeurtenissen en het ontvangen van de gebeurtenis bij de invoerbron. Aanpassing op basis van tolerantie voor late aankomst wordt eerst uitgevoerd en de volgende stap wordt niet op volgorde uitgevoerd. De kolom System.Timestamp() heeft de laatste tijdstempel toegewezen aan de gebeurtenis.

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

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

Tolerantie voor late aankomst en Sparse-gebeurtenissen

Met beleid voor late aankomst kan Stream Analytics de tijd vooruit verplaatsen en uitvoer genereren op een timeliere manier bij afwezigheid van invoerevenementen. Dit is erg handig wanneer invoergebeurtenissen sparse zijn (of helemaal niet worden ontvangen in sommige Event Hub-partities).

Invoerevenementen worden bijvoorbeeld eenmaal per minuut gegenereerd voor een select*-query. Zonder dit beleid te gebruiken, 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 vooruitgezet, zodat de uitvoer gebeurtenis 5 seconden na de eerste gebeurtenis wordt gegenereerd.

See Also

Time Management
System.Timestamp() (Stream Analytics)
TIMESTAMP BY
Overwegingen voor gebeurtenisorders