Ventetid i Aktivering

Stoffaktivator kjører regler mot sanntidsdata. Resultatene er nesten umiddelbare, men ulike faktorer kan føre til forsinkelse. I de fleste tilfeller merker du ikke denne forsinkelsen, men i noen tilfeller kan det være opptil 10 minutter. Å motta nøyaktig og rettidig informasjon er en viktig vurdering når du oppretter og mottar regler. Denne artikkelen gjennomgår prosessene og innstillingene som avgjør balansen mellom inkludering av hendelser og regelstruktur, og hvor raskt Activator sender en aktivering. For eksempel, bør Activator tillate at mer data kommer inn og inkluderes, eller bør Activator sørge for at mottakerne mottar varslene sine til et bestemt tidspunkt? Og hvordan påvirker regelstrukturen hastigheten Activator sender en aktivering til mottakerne med?

Tre viktige faktorer påvirker latensen for regelaktivering:

• Toleranse for sen ankomst.
• Backend-prosesseringsforsinkelse.
• Aggregeringslatens.

Toleranse for sen ankomst

I strømmedata kommer ikke hendelser alltid i rekkefølge eller i tide. En hendelses hendelsestid (når den skjedde) kan falle innenfor en regels tidsvindu, men ankomsttiden (når Activator mottok den) kan ligge utenfor det vinduet – noe som gjør hendelsen forsinket. Som standard fjerner Activator sene hendelser fra regelevaluering.

Innstillingen ventetid for sent ankommende hendelser styrer hvor lenge Activator venter før evalueringsvinduet lukkes, noe som gir sene hendelser en sjanse til å komme. Denne innstillingen finnes i Avanserte innstillinger på regeldefinisjonsskjermen . For å lære hvordan du konfigurerer det, se innstillingen for toleranse for sen ankomst.

Ventetid for serverdelbehandling

Aktivator må kanskje behandle en regel før den aktiveres, noe som kan føre til en forsinkelse på opptil ett minutt. For eksempel, hvis regelen sammenligner med et tidligere sett med hendelser, henter Activator de forrige dataene, gjør sammenligningen og beregner resultatet. Som et annet eksempel, hvis regelen kjører mot 10 millioner datarader, introduserer Activators behandling av det volumet også forsinkelse.

Ventetid for aggregasjon

Hvis en aggregasjon brukes i regeldefinisjonen, aktiveres regelen bare når den fullfører de angitte tidsvinduene. For eksempel, la oss si at en regel er laget for å gjennomsnitte dataene over fire timer. Hvis en hendelse som oppfyller regelbetingelsene inntas kl. 12, utløses regelen kl. 16. Latensen er et resultat av aggregeringsinnstillingene. Selv når en regel inneholder en enkel aggregasjon, for eksempel gjennomsnitt, kan ikke Aktivator sende en aktivering før Activator kjører aggregasjonen på tvers av innkommende hendelsesdata.

Konsepter for bakgrunnstid

For å ramme inn diskusjonen bedre, la oss definere noen konsepter for bakgrunnstid.

• Hendelsestid: Tidspunktet da den opprinnelige hendelsen skjedde. Det er en del av nyttelasten for arrangementet. For eksempel, øyeblikket en sensor oppdager en bil som nærmer seg en bomstasjon, er hendelsestidspunktet.
• Behandlingstid: Tidspunktet da behandlingssystemet mottar og observerer hendelsen. For eksempel, etter at bomstasjonssensoren har sett bilen, er tidspunktet datasystemet mottar og behandler sensorens informasjon behandlingstiden.
• Ankomsttid (vannmerke eller inntakstid): En indikator som angir når hendelsesdataene når Activator. Av typen strømmer stopper aldri innkommende hendelsesdata, så ankomsttider indikerer fremdriften som aktivatoren har gjort, til et bestemt punkt i strømmen. Det er på dette tidspunktet at Activator kan produsere fullstendige, riktige og repeterbare resultater som ikke trenger å trekkes tilbake. Og det er på dette tidspunktet at Activator kan begynne å behandle dataene. Aktivator behandler data på en forutsigbar og repeterbar måte. For eksempel, hvis Activator må telle data på nytt for feilhåndtering, kan den bruke ankomsttider som trygge start- og sluttpunkter. For eksempel, når bomstasjonssystemet har mottatt alle bilregistreringer frem til kl. 09:05, flyttes ankomsttidsmarkøren til 09:05. Alle deteksjoner som ankommer etter det punktet — selv om deres arrangementstid var før 09:05 — er forsinket.

Sen ankomst oppstår når en regel har en tidsparameter og hendelsestiden er innenfor denne tidsparameteren, men ankomsttiden faller utenfor den. Med eksempelet fra bomstasjonen: sensoren oppdager bilen og hendelsestiden er innenfor regelens tidsvindu. Men hvis sensoren bruker for lang tid på å sende deteksjonen — for eksempel på grunn av nettverksbelastning — ankommer hendelsen Activator etter at vinduet lukkes. Aktivator anser den hendelsen som sen. Hvis du vil inkludere sene ankomster, sett ventetiden for sene ankomster i Avanserte innstillinger.

Hvis du vil ha flere ressurser om dette emnet, kan du se Tyler Akidau's blogginnlegg Streaming 101 og Streaming 102.

Toleranseinnstilling for sen ankomst

Du kan konfigurere toleranseinnstillingen for sen ankomst. Standardverdien er to minutter. Denne innstillingen bidrar til latens. Regler du lager med ventetid har en minimumsforsinkelse lik den konfigurerte varigheten. Når du lager en regel, bestem om du vil bruke standarden eller endre den. Settingen sikrer at sene hendelser og hendelser utenfor rekkefølge får mulighet til å inkluderes i regelevalueringen. Hvis en hendelse faller utenfor den konfigurerte toleransen for sen ankomst, tar ikke Activator det i betraktning. Hendelser med ankomsttid etter den terskelen tas ikke med i beregningen.

Overordnet sett, vurder om det er viktigere å:

• Vent på sene datapunkter, eller
• Kjør regelen på potensielt ufullstendige data slik at regelen aktiveres tidligere. 

I dette eksemplet måles datapunkter i intervaller på 15 minutter. De tre første prikkene, som er blå, gjør det i tidsvinduet. Den fjerde prikken, som er oransje, gjør det ikke. Hendelsestiden er innenfor intervallet på 15 minutter, men hendelsen inntas ikke av Activator innen intervallet på 15 minutter. Aktivator evaluerer bare regelen over data med en ankomsttid i 15-minuttersvinduet. Med mindre du øker toleransen for sen ankomst, er ikke datapunkter som kommer etter at vinduet stenger, inkludert.

Aktivator kan ikke ta hensyn til forsinkelser fra datakildene dine. For eksempel kan du ha IoT-sensorer som er offline i én time. Når de går på nett igjen, kan Activator motta dataene, men dataene ble forsinket i én time fra den offline-tilstanden, noe som skjer utenfor Activator.

Her er et annet eksempel.

Du lager en regel som beregner gjennomsnittstemperaturen i små intervaller. Ventetiden for sent ankommende hendelser er satt til standard to minutter. Aktivator inkluderer temperaturverdier 20 og 30, og beregner et gjennomsnitt på 25. Aktivator inkluderer imidlertid ikke den sene 40-graders hendelsen før neste regelaktivering.

Regler bygget på Power BI-visualobjekter

Innebygd ventetid varierer etter tjeneste. Latens for hendelsesstrømmer er annerledes enn latens for Power BI-visualiseringer. To faktorer påvirker latens for regler bygget på Power BI-visualiseringer: hvor ofte man spør Power BI-visualiseringer som er innebygd i systemet, og en forsinkelse som Activators backend kan introdusere.

Power BI-regler evalueres når nye data kommer til Activator. Som standard spør Activator Power BI én gang i timen, noe som betyr at hendelser som oppfyller regelbetingelsen utløser en aktivering maksimalt én time etter at hendelsen har skjedd. Du kan endre denne frekvensen i datakildeinnstillingene. For mer informasjon, se Spørringsfrekvens for spørringsdatakilder og Lag Power BI varsler og forbedre dem i Fabric Activator.