Ventetid i aktivator

Fabric Activator kører regler mod data i realtid. Resultaterne er næsten øjeblikkelige, men forskellige faktorer kan introducere latenstid. I de fleste tilfælde bemærker du ikke denne latenstid, men i nogle tilfælde kan den være op til 10 minutter. Det er vigtigt at modtage nøjagtige og rettidige oplysninger, når du opretter og modtager regler. Denne artikel gennemgår processerne og indstillingerne, der bestemmer balancen mellem inkludering af begivenheder og regelstruktur, samt hvor hurtigt Activator sender en aktivering. For eksempel, bør Activator tillade flere data at ankomme og blive inkluderet, eller skal Activator sikre, at modtagerne modtager deres advarsler på et bestemt tidspunkt? Og hvordan påvirker regelstrukturen hastigheden, hvormed Activator sender en aktivering til modtagerne?

Tre vigtige faktorer påvirker regelaktiveringslatens:

• Tolerance for sen ankomst.
• Backend-behandlingslatens.
• Aggregeringslatens.

Tolerance for sen ankomst

I streamingdata ankommer begivenhederne ikke altid i rækkefølge eller til tiden. En begivenheds begivenhedstid (hvornår den skete) kan falde inden for en regels tidsvindue, men dens ankomsttid (da Activator modtog den) kan falde uden for det vindue – hvilket gør begivenheden forsinket. Som standard fjerner Activator sene begivenheder fra regelevaluering.

Indstillingen ventetid for sent ankommende begivenheder styrer, hvor længe Activator venter, før evalueringsvinduet lukkes, hvilket giver sene begivenheder en chance for at ankomme. Denne indstilling findes i afsnittet Avancerede indstillinger på regeldefinitionsskærmen . For at lære at konfigurere det, se indstillingen for tolerance for sen ankomst.

Ventetid for behandling af backend

Aktivator kan være nødt til at behandle en regel, før den aktiveres, hvilket kan give en forsinkelse på op til et minut. For eksempel, hvis reglen sammenligner med et tidligere sæt begivenheder, henter Activator de tidligere data, foretager sammenligningen og beregner resultatet. Som et andet eksempel, hvis reglen kører mod 10 millioner rækker af data, introducerer Activators behandling af det volumen også latenstid.

Ventetid for sammenlægning

Hvis der bruges en sammenlægning i regeldefinitionen, aktiveres reglen kun, når den fuldfører de angivne klokkeslætsvinduer. For eksempel, lad os sige, at en regel er bygget til at gennemsnitlige data over fire timer. Hvis en begivenhed, der opfylder regelbetingelserne, indskrives kl. 12, udløses reglen kl. 16. Latenstiden skyldes aggregeringsindstillingerne. Selv når en regel indeholder en simpel aggregering, f.eks . gennemsnit, kan Aktivator ikke sende en aktivering, før Aktivator kører sammenlægningen på tværs af de indgående hændelsesdata.

Begreber i baggrundstid

For bedre at indramme diskussionen, lad os definere nogle begreber for baggrundstid.

• Hændelsestidspunkt: Det tidspunkt, hvor den oprindelige hændelse fandt sted. Det er en del af hændelsens nyttedata. For eksempel er det øjeblik, hvor en sensor registrerer en bil, der nærmer sig en betalingsstation, begivenhedstidspunktet.
• Behandlingstid: Det tidspunkt, hvor behandlingssystemet modtager og observerer begivenheden. For eksempel, efter at betalingsstationens sensor har set bilen, er det tidspunkt, hvor computersystemet modtager og behandler sensorens information, behandlingstiden.
• Ankomsttidspunkt (vandmærke eller indtagelsestid): En markør, der angiver, hvornår hændelsesdataene når Udløsningsenheden. Af naturen af streams stopper de indgående hændelsesdata aldrig, så ankomsttiderne angiver status for Aktivator til et bestemt punkt i streamen. Det er på dette tidspunkt, at Aktivator kan producere komplette, korrekte og gentagelige resultater, der ikke behøver at blive trukket tilbage. Og det er på dette tidspunkt, at Aktivator kan begynde at behandle dataene. Aktivator behandler data på en forudsigelig og gentagelig måde. For eksempel, hvis Activator skal genoptælle data for fejlhåndtering, kan den bruge ankomsttider som sikre start- og slutpunkter. For eksempel, når betalingsstationssystemet har modtaget alle bilregistreringer op til kl. 9:05, rykker ankomsttidspunktet frem til kl. 9:05. Alle registreringer, der ankommer efter det tidspunkt — selv hvis deres eventtid var før kl. 9:05 — er forsinkede.

Sen ankomst opstår, når en regel har en tidsparameter, og begivenhedstiden er inden for denne tidsparameter, men ankomsttiden ligger uden for den. Ved eksempel med betalingsboksen: sensoren registrerer bilen, og begivenhedstidspunktet er inden for reglens tidsvindue. Hvis sensoren dog tager for lang tid om at sende detekteringen — for eksempel på grund af netværksbelastning — ankommer hændelsen til Activator efter vinduet lukker. Aktivator betragter den begivenhed som sen. Hvis du vil inkludere sene ankomster, kan du sætte ventetiden for sene ankomster i Avancerede indstillinger.

Du kan finde flere ressourcer om dette emne i Tyler Akidaus blogindlæg Streaming 101 og Streaming 102.

Toleranceindstilling for sen ankomst

Du kan konfigurere indstillingen for tolerance for sen ankomst. Standardværdien er to minutter. Denne indstilling bidrager til latenstiden. Regler, du opretter med ventetid, har en minimumslatens svarende til den konfigurerede varighed. Når du opretter en regel, skal du beslutte, om du vil bruge standarden eller ændre den. Indstillingen sikrer, at sene begivenheder og ude af rækkefølge begivenheder får mulighed for at blive inkluderet i regelevalueringen. Hvis en hændelse ligger uden for den konfigurerede tolerance for sen ankomst, tager Activator det ikke i betragtning. Eventuelle begivenheder med en ankomsttid efter den tærskel er ikke medregnet.

Overvej overordnet, om det er vigtigere at:

• Vent på de forsinkede datapunkter, eller
• Kør reglen på potentielt ufuldstændige data, så reglen aktiveres tidligere. 

I dette eksempel måles datapunkter i trin på 15 minutter. De første tre prikker, som er blå, gør det i tidsvinduet. Den fjerde prik, som er orange, gør ikke. Hændelsestiden er inden for intervallet på 15 minutter, men hændelsen indtages ikke af Aktivator inden for 15-minutters intervallet. Activator evaluerer kun reglen for data med en ankomsttid inden for 15-minutters vinduet. Medmindre du øger tolerancen for sen ankomst, er datapunkter, der ankommer efter vinduet lukker, ikke inkluderet.

Aktivator kan ikke tage højde for forsinkelser fra dine datakilder. For eksempel kan du have IoT-sensorer, der er offline i en time. Når de går online igen, kan Activator modtage dataene, men dataene blev forsinket i en time fra den offline-tilstand, hvilket sker uden for Activator.

Her er et andet eksempel.

Du laver en regel, der beregner gennemsnitstemperaturen i minutintervaller. Ventetiden for sent ankommende begivenheder er sat til standarden to minutter. Aktivator inkluderer temperaturværdierne 20 og 30 og beregner et gennemsnit på 25. Dog inkluderer Activator ikke den sent ankommende 40-graders begivenhed før næste regelaktivering.

Regler, der er baseret på Power BI-visualiseringer

Indbygget ventetid varierer afhængigt af tjenesten. Latenstid for eventstreams er forskellig fra latenstid for Power BI-visualiseringer. To faktorer påvirker latenstid for regler bygget på Power BI-visualiseringer: hyppigheden af forespørgsler på Power BI-visualiseringer, der er indbygget i systemet, og en forsinkelse, som Activators backend kan introducere.

Power BI-regler evalueres, hver gang der modtages nye data i Aktivator. Som standard forespørger Activator Power BI én gang i timen, hvilket betyder, at begivenheder, der opfylder regelbetingelsen, udløser en aktivering maksimalt en time efter, at hændelsen finder sted. Du kan ændre denne frekvens i datakildeindstillingerne. For mere information, se Forespørgselsfrekvens for forespørgselsdatakilder og Opret Power BI advarsler og forfin dem i Fabric Activator.