Latentie in Activator

Fabric Activator voert regels uit op realtime gegevens. Resultaten zijn bijna onmiddellijk, maar verschillende factoren kunnen latentie veroorzaken. In de meeste gevallen ziet u deze latentie niet, maar in sommige gevallen kan het maximaal tien minuten duren. Het ontvangen van nauwkeurige en tijdige informatie is een belangrijke overweging bij het maken en ontvangen van regels. In dit artikel worden de processen en instellingen besproken die de balans bepalen tussen de opname van gebeurtenissen en regelstructuur en hoe snel Activator een activering verzendt. Moet Activator bijvoorbeeld toestaan dat er meer gegevens binnenkomen en worden opgenomen, of moet Activator ervoor zorgen dat ontvangers hun waarschuwingen op een bepaald tijdstip ontvangen? En, hoe beïnvloedt de regelstructuur de snelheid waarmee Activator een activering naar ontvangers verzendt?

Drie belangrijke factoren zijn van invloed op de activeringslatentie van regels:

• Tolerantie voor late aankomst.
• Latentie van back-endverwerking.
• Aggregatielatentie.

Tolerantie voor late aankomst

In streaminggegevens komen gebeurtenissen niet altijd op volgorde of op tijd aan. De tijd van een gebeurtenis (wanneer het gebeurde) valt mogelijk binnen het tijdvenster van een regel, maar de aankomsttijd (wanneer Activator het heeft ontvangen) kan buiten dat venster vallen, waardoor de gebeurtenis te laat komt. Activator verwijdert standaard late gebeurtenissen uit de evaluatie van regels.

De wachttijd voor late binnenkomende gebeurtenissen bepaalt hoe lang Activator wacht voordat het evaluatievenster wordt gesloten, zodat late gebeurtenissen een kans krijgen om aan te komen. Deze instelling bevindt zich in de sectie Geavanceerde instellingen van het scherm Definitie van regel. Zie Instelling voor tolerantie voor late aankomst voor meer informatie over het configureren ervan.

Latentie voor back-endverwerking

Activator moet mogelijk een regel verwerken voordat deze wordt geactiveerd, wat een vertraging van maximaal één minuut kan veroorzaken. Als de regel bijvoorbeeld vergelijkt met een eerdere set gebeurtenissen, haalt Activator de vorige gegevens op, maakt de vergelijking en berekent het resultaat. Als bijvoorbeeld de regel wordt uitgevoerd op 10 miljoen rijen gegevens, dan introduceert de verwerking van dat volume door Activator ook latentie.

Aggregatielatentie

Als een aggregatie wordt gebruikt in de regeldefinitie, wordt de regel alleen geactiveerd wanneer de opgegeven tijdvensters zijn voltooid. Stel dat een regel is gebouwd om het gemiddelde van de gegevens over vier uur te berekenen. Als een gebeurtenis die voldoet aan de regelvoorwaarden om 12:00 uur wordt opgenomen, wordt de regel om 14:00 uur geactiveerd. De latentie is het resultaat van de aggregatie-instellingen. Zelfs wanneer een regel een eenvoudige aggregatie bevat, zoals gemiddeld, kan Activator geen activering verzenden totdat Activator de aggregatie uitvoert over de binnenkomende gebeurtenisgegevens.

Concepten van achtergrondtijd

Om de discussie beter te kaderen, gaan we enkele achtergrondtijdconcepten definiëren.

• Gebeurtenistijd: het tijdstip waarop de oorspronkelijke gebeurtenis is opgetreden. Het maakt deel uit van de payload van het evenement. Het moment dat een sensor bijvoorbeeld een auto detecteert die een tolcel nadert, is de gebeurtenistijd.
• Verwerkingstijd: het tijdstip waarop het verwerkingssysteem de gebeurtenis ontvangt en bekijkt. Nadat de tolcelsensor bijvoorbeeld de auto ziet, is het tijdstip waarop het computersysteem de informatie van de sensor ontvangt en verwerkt, de verwerkingstijd.
• Aankomsttijd (watermerk of opnametijd): een markering die aangeeft wanneer de gebeurtenisgegevens Activator bereiken. Vanwege de aard van streams stoppen de binnenkomende gebeurtenisdata nooit, dus aankomsttijden geven de voortgang van Activator aan op een bepaald punt in de stream. Op dit moment kan Activator volledige, correcte en herhaalbare resultaten produceren die niet hoeven te worden ingetrokken. En op dit moment kan Activator beginnen met het verwerken van de gegevens. Activator verwerkt gegevens op een voorspelbare en herhaalbare manier. Als Activator bijvoorbeeld gegevens moet tellen voor foutafhandeling, kan deze de aankomsttijden gebruiken als veilige begin- en eindpunten. Zodra het tolhuissysteem bijvoorbeeld alle autodetecties tot 9:05 uur heeft ontvangen, gaat de markering van de aankomsttijd naar 9:05 uur. Detecties die na dat punt aankomen, zelfs als hun gebeurtenistijd vóór 9:05 uur was, zijn te laat.

Late aankomst treedt op wanneer een regel een tijdparameter heeft en de gebeurtenistijd binnen die tijdparameter valt, maar de aankomsttijd valt er buiten. Met behulp van het voorbeeld van de tolcel: de sensor detecteert de auto en de tijd van de gebeurtenis bevindt zich binnen het tijdvenster van de regel. Als de sensor echter te lang duurt om de detectie te verzenden, bijvoorbeeld vanwege netwerkcongestie, komt de gebeurtenis bij Activator aan nadat het venster is gesloten. Activator beschouwt die gebeurtenis te laat. Als u wilt dat late aankomsten worden opgenomen, stelt u de wachttijd in voor late aankomst gebeurtenissen in geavanceerde instellingen.

Zie voor meer informatie over dit onderwerp de blogposts van Tyler Akidau Streaming 101 en Streaming 102.

Instelling voor tolerantie voor late aankomst

U kunt de instelling voor tolerantie voor late aankomst configureren. De standaardwaarde is twee minuten. Deze instelling draagt bij aan latentie. Regels die u met een wachttijd maakt, hebben een minimale latentie die gelijk is aan de geconfigureerde duur. Wanneer u een regel maakt, moet u beslissen of u de standaardregel wilt gebruiken of deze wilt wijzigen. De instelling zorgt ervoor dat late gebeurtenissen en out-of-order-gebeurtenissen de mogelijkheid hebben om te worden opgenomen in de regelevaluatie. Als een gebeurtenis buiten de geconfigureerde tolerantie voor late aankomst valt, houdt Activator er geen rekening mee. Gebeurtenissen met een aankomsttijd na die drempelwaarde worden niet meegerekend.

Over het algemeen moet u overwegen of het belangrijker is om:

• Wacht op de late gegevenspunten of
• Voer de regel uit op mogelijk onvolledige gegevens, zodat de regel sneller wordt geactiveerd. 

In dit voorbeeld worden gegevenspunten gemeten in stappen van 15 minuten. De eerste drie punten, die blauw zijn, halen het in het tijdvenster. De vierde stip, die oranje is, doet dat niet. De tijd van de gebeurtenis valt binnen het interval van 15 minuten, maar de gebeurtenis wordt niet opgenomen door Activator binnen het interval van 15 minuten. Activator evalueert alleen de regel over gegevens met een aankomsttijd binnen een tijdsbestek van 15 minuten. Tenzij u de tolerantie voor late aankomst verhoogt, worden er geen gegevenspunten opgenomen die na het sluiten van het venster binnenkomen.

Activator kan geen rekening houden met vertragingen van uw gegevensbronnen. U hebt bijvoorbeeld IoT-sensoren die één uur offline zijn. Zodra ze weer online zijn, kan Activator de gegevens ontvangen, maar de gegevens zijn één uur vertraagd vanaf die offlinestatus, wat buiten Activator gebeurt.

Hier volgt nog een voorbeeld.

U maakt een regel waarmee de gemiddelde temperatuur in minuten wordt berekend. De wachttijd voor gebeurtenissen die te laat binnenkomen , is ingesteld op de standaardwaarde van twee minuten. Activator omvat temperatuurwaarden 20 en 30 en berekent een gemiddelde van 25. Activator neemt echter pas de late binnenkomende gebeurtenis van 40 graden op totdat de volgende regel wordt geactiveerd.

Regels die zijn gebouwd op Power BI-visuals

De ingebouwde latentie verschilt per service. Latentie voor eventstreams verschilt van latentie voor Power BI visuals. Twee factoren zijn van invloed op latentie voor regels die zijn gebouwd op Power BI visuals: de frequentie van het uitvoeren van query's op Power BI visuals die zijn ingebouwd in het systeem en een vertraging die de back-end van Activator kan veroorzaken.

Power BI-regels worden geëvalueerd wanneer nieuwe gegevens binnenkomen in Activator. Activator voert standaard één keer per uur query's uit Power BI, wat betekent dat gebeurtenissen die voldoen aan de regelvoorwaarde, een activering activeren op maximaal één uur nadat de gebeurtenis plaatsvindt. U kunt deze frequentie wijzigen in de instellingen voor de gegevensbron. Zie Queryfrequentie voor querygegevensbronnen en Maak Power BI waarschuwingen en verfijn ze in Fabric Activator voor meer informatie.