Fördröjning i Activator

Fabric Activator tillämpar regler på realtidsdata. Resultaten är nästan omedelbara, men olika faktorer kan leda till svarstid. I de flesta fall märker du inte den här svarstiden, men i vissa fall kan det ta upp till 10 minuter. Att få korrekt och snabb information är ett viktigt övervägande när du skapar och tar emot regler. Den här artikeln granskar de processer och inställningar som avgör balansen mellan inkludering av händelser och regelstruktur och hur snabbt Activator skickar en aktivering. Ska Till exempel Activator tillåta att fler data tas emot och inkluderas, eller ska Activator se till att mottagarna får sina aviseringar vid en viss tidpunkt? Och hur påverkar regelstrukturen den hastighet med vilken Activator skickar en aktivering till mottagarna?

Tre viktiga faktorer påverkar svarstiden för regelaktivering:

• Tolerans för sen ankomst.
• Fördröjning vid serverbackendbearbetning.
• Fördröjning vid aggregation.

Tolerans för sen ankomst

I strömmande data kommer händelser inte alltid i ordning eller i tid. En händelses händelsetid (när det hände) kan falla inom en regels tidsfönster, men dess ankomsttid (när Activator tog emot den) kan falla utanför det fönstret , vilket gör händelsen sen. Som standard släpper Activator sena händelser från regelutvärderingen.

Inställningen Väntetid för händelser som inkommer sent styr hur länge Activator väntar innan utvärderingsfönstret stängs, vilket ger sena händelser en chans att komma fram. Den här inställningen finns i avsnittet Avancerade inställningar på skärmen Regeldefinition . Information om hur du konfigurerar det finns i Inställningen för tolerans för sena ankomster.

Fördröjning vid bakgrundsbehandling

Aktivatorn kan behöva bearbeta en regel innan den aktiveras, vilket kan medföra en fördröjning på upp till en minut. Om regeln till exempel jämförs med en tidigare uppsättning händelser hämtar Activator tidigare data, gör jämförelsen och beräknar resultatet. Som ett annat exempel, om regeln körs mot 10 miljoner rader med data, introducerar Activators bearbetning av volymen också svarstid.

Fördröjning vid aggregering

Om en aggregering används i regeldefinitionen aktiveras regeln endast när den har slutfört de angivna tidsfönstren. Anta till exempel att en regel är byggd för att genomsnittligt bestämma data över fyra timmar. Om en händelse som uppfyller regelvillkoren matas in kl. 12.00 utlöses regeln kl. 16.00. Svarstiden är resultatet av aggregeringsinställningarna. Även om en regel innehåller en enkel aggregering, till exempel medelvärde, kan Activator inte skicka en aktivering förrän Activator kör aggregeringen över inkommande händelsedata.

Begrepp för bakgrundstid

För att bättre rama in diskussionen ska vi definiera några bakgrundstidsbegrepp.

• Händelsetid: Den tid då den ursprungliga händelsen inträffade. Det är en del av händelsenyttolasten. Till exempel är händelsetiden det ögonblick då en sensor upptäcker en bil som närmar sig en vägtullstation.
• Bearbetningstid: Den tid då bearbetningssystemet tar emot och observerar händelsen. När till exempel vägtullssensorn ser bilen är den tid då datorsystemet tar emot och bearbetar sensorns information bearbetningstiden.
• Ankomsttid (vattenstämpel eller inmatningstid): En markör som anger när händelsedata når Activator. På grund av strömmars natur slutar aldrig inkommande händelsedata, så anger ankomsttiderna hur långt Activator har kommit till en viss punkt i strömmen. Det är i det här läget som Activator kan generera fullständiga, korrekta och repeterbara resultat som inte behöver återkallas. Och det är just nu som Activator kan börja bearbeta data. Aktivator bearbetar data på ett förutsägbart och repeterbart sätt. Om Activator till exempel behöver räkna om data för felhantering kan den använda ankomsttider som säkra start- och slutpunkter. När t.ex. vägtullsystemet har tagit emot alla bilidentifieringar fram till 09:05 går tidsmarkören för ankomst fram till 09:05. Alla identifieringar som kommer efter den tidpunkten – även om deras händelsetid var före 09:05 – är sena.

Sen ankomst inträffar när en regel har en tidsparameter och händelsetiden ligger inom den tidsparametern, men ankomsttiden faller utanför den. Med hjälp av exemplet med avgiftsbelagda bås: sensorn identifierar bilen och händelsetiden ligger inom regelns tidsfönster. Men om sensorn tar för lång tid att överföra identifieringen, till exempel på grund av nätverksbelastning, kommer händelsen till Activator när fönstret har stängts. Activator anser att händelsen är försenad. Om du vill att sena ankomster ska inkluderas anger du Väntetid för sena händelser i Avancerade inställningar.

Ytterligare resurser om detta ämne finns i Tyler Akidaus blogginlägg Streaming 101 och Streaming 102.

Inställning för tolerans för sena ankomster

Du kan konfigurera inställningen för tolerans för sena ankomster. Standardvärdet är två minuter. Den här inställningen bidrar till svarstiden. Regler som du skapar med en väntetid har en minsta svarstid som är lika med den konfigurerade varaktigheten. När du skapar en regel bestämmer du om du vill använda standardinställningen eller ändra den. Inställningen säkerställer att sena händelser och out-of-order-händelser har möjlighet att tas med i regelutvärderingen. Om en händelse faller utanför den konfigurerade toleransen för sen ankomst tar Activator inte hänsyn till den. Händelser med ankomsttid efter tröskelvärdet räknas inte in.

Överlag bör du överväga om det är viktigare att:

• Vänta på de sena datapunkterna, eller
• Kör regeln på potentiellt ofullständiga data så att regeln aktiveras tidigare. 

I det här exemplet mäts datapunkter i steg på 15 minuter. De första tre punkterna, som är blå, passar in i tidsramen. Den fjärde punkten, som är orange, gör det inte. Händelsetiden ligger inom intervallet på 15 minuter, men händelsen matas inte in av Activator inom intervallet på 15 minuter. Activator utvärderar endast regeln över data med en ankomsttid inom ett 15-minuters intervall. Om du inte ökar toleransen för sena ankomster inkluderas inte datapunkter som kommer när fönstret stängs.

Aktivator kan inte ta hänsyn till fördröjningar från dina datakällor. Du kan till exempel ha IoT-sensorer som är offline i en timme. När de är online igen kan Activator ta emot data, men data fördröjdes i en timme från det offlinetillståndet, vilket sker utanför Activator.

Här är ett annat exempel.

Du skapar en regel som beräknar medeltemperaturen i minutintervall. Väntetiden för händelser som inkommer sent är inställd på standardvärdet på två minuter. Aktivator innehåller temperaturvärdena 20 och 30 och beräknar ett genomsnitt på 25. Activator inkluderar dock inte den sena 40-gradershändelsen förrän nästa regelaktivering.

Regler som bygger på visuella Power BI-objekt

Den inbyggda svarstiden skiljer sig åt beroende på tjänst. Svarstiden för eventstreams skiljer sig från svarstiden för Power BI visuella objekt. Två faktorer påverkar svarstiden för regler som bygger på Power BI visuella objekt: frekvensen för att fråga Power BI visuella objekt som är inbyggda i systemet och en fördröjning som Activators serverdel kan medföra.

Power BI-regler utvärderas när nya data tas emot i Activator. Som standard frågar Activator Power BI en gång per timme, vilket innebär att händelser som uppfyller regelvillkoret utlöser en aktivering högst en timme efter att händelsen inträffar. Du kan ändra den här frekvensen i inställningarna för datakällan. Mer information finns i Frågefrekvens för frågedatakällor och Skapa Power BI-varningar och förbättra dem i Fabric Activator.