Ventetid i aktivator
Fabric Activator kører regler mod data i realtid. Resultaterne er næsten øjeblikkelige, men der er faktorer, der kan medføre ventetid. I de fleste tilfælde er denne ventetid umærkelig, men i andre tilfælde kan ventetiden være op til 10 minutter. Det er vigtigt at modtage nøjagtige og rettidige oplysninger, når du opretter og modtager regler. I denne artikel gennemgås de processer og indstillinger, der bestemmer balancen mellem medtagelse af hændelser og strukturen af en regel, og hvor hurtigt en aktivator sendes. Skal Aktivator f.eks. tillade, at der modtages flere data, og være inkluderet, eller skal Aktivator sikre, at modtagerne modtager deres beskeder på et angivet tidspunkt? Og hvordan påvirker den måde, en regel struktureres på, den hastighed, hvormed en aktivering sendes til modtagere?
Der er tre vigtige faktorer, der påvirker ventetiden for aktivering af regler:
- Brugerindstillingen for tolerance for sen ankomst.
- En forsinkelse på op til et minut, der kan introduceres af Aktivatorens backendbehandling.
- Sammenlægninger af reglen.
Tolerance for sen ankomst
Tolerance for sen ankomst angives på skærmen Definition af aktivatorregel og anvendes på hændelsens ankomsttidspunkt. Hvis du vil vide mere om, hvordan du angiver tolerance for sen ankomst, skal du se Indstillingen For tolerance for forsinket ankomst.
Ventetid for behandling af backend
Regler skal muligvis behandles, før reglen aktiveres. Hvis reglen f.eks. er en sammenligning med et tidligere sæt hændelser, kræver det backendbehandling for at hente de tidligere data, foretage sammenligningen og beregne resultatet. Et andet eksempel er, at hvis reglen kører mod 10 millioner rækker med data, introduceres ventetiden ved backendbehandling af disse data.
Ventetid for sammenlægning
Hvis der bruges en sammenlægning i regeldefinitionen, aktiveres reglen kun, når den fuldfører de angivne klokkeslætsvinduer. Lad os f.eks. sige, at en regel er bygget til at gennemsnittet af dataene over fire timer. Hvis en hændelse, der opfylder regelbetingelserne, indtages kl. 12, udløses reglen kl. 16. Ventetiden er et resultat af indstillingerne for sammenlægning. 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
Lad os definere nogle baggrundsbegreber for bedre at kunne indramme diskussionen.
- Hændelsestidspunkt: Det tidspunkt, hvor den oprindelige hændelse fandt sted. Det er en del af hændelsens nyttedata. For eksempel, når en kørende bil på motorvejen nærmer sig en betalingsbod og bemærket af en sensor.
- Behandlingstid: Det tidspunkt, hvor hændelsen når behandlingssystemet og overholdes. Når en betalingsstandssensor f.eks. ser bilen og computersystemet, tager det et øjeblik at behandle dataene.
- 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. Behandlingen kan udføres på en forudsigelig og gentagelig måde. Hvis der f.eks. skal foretages en optælling for nogle fejlhåndteringsbetingelser, er ankomsttider sikre start- og slutpunkter.
Sen ankomst sker, når reglen har en klokkeslætsparameter, og hændelsestidspunktet er inden for denne tidsparameter, men ankomsttidspunktet falder uden for denne parameter. Hvis vi bruger eksemplet med betalingsstanden igen, genkendes bilen af betalingsbåsens sensor, og hændelsestiden er inden for tidsparameteren. Activator kan se, at reglen har en aggregering og udfører denne aggregering over dataene. Den tid, det tager at udføre denne aggregering, placerer ankomsttid uden for tidsparameteren. Denne hændelse anses nu for sent. Hvis du vil inkludere forsinkede ankomster, skal du angive en værdi for tolerancen for sen ankomst.
Du kan finde flere ressourcer om dette emne i Tyler Akidaus blogindlæg Streaming 101 og Streaming 102.
Toleranceindstilling for sen ankomst
Tolerance for sen ankomst er en brugerindstilling. Tolerance for sen ankomst refererer til, hvor længe Aktivator venter på, at en hændelse ankommer og bekræftes og behandles. Standarden er to minutter. Tolerance for forsinket ankomst bidrager til ventetid. Regler, der oprettes med en tolerance for sen ankomst, har en ventetid, der mindst er den mængde tid, som tolerancen for sen ankomst er angivet til. Når du opretter en regel, skal du beslutte, om du vil bruge standardtolerancen eller ændre den. Tolerance sikrer, at forsinkede hændelser og hændelser, der ankommer i ude af rækkefølge, har mulighed for at blive inkluderet i regelevalueringen. Hvis en hændelse falder uden for tolerancen for sen ankomst, tager Aktivator ikke hensyn til den. Alle hændelser med et ankomsttidspunkt efter denne tolerance indregnes ikke.
Overordnet set er overvejelserne, 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 brugeren angiver, at vedkommende vil tillade en tolerance for sen ankomst og vente med at se, om andre datapunkter ankommer.
Aktivator kan ikke indregne forsinkelser fra brugerens data. Brugeren kan f.eks. have IoT-sensorer, der er offline i 1 time. Når de går online igen, kan Aktivator modtage dataene, men dataene blev forsinket i 1 time fra denne offlinetilstand, hvilket sker uden for Aktivator.
Her er et andet eksempel.
Brugeren opretter en regel, der beregner den gennemsnitlige temperatur i minutintervaller. Tolerancen for sen ankomst er angivet til Standard. Standard er to minutter. Temperaturværdierne 20 og 30 er inkluderet, og gennemsnitstemperaturen er 25. Den sene ankommer hændelse for 40-graders temperaturen er dog ikke inkluderet, før den næste regelaktivering finder sted.
| Begivenhedstidspunkt | Ankomsttidspunkt | Temperatur |
|---|---|---|
| 09:00 | 09:02 | 20 |
| 09:01 | 09:03 | 30 |
| 09:02 | 09:07 | 40 |
Vigtigt
Du kan i øjeblikket ikke tilsidesætte standardtolerancen for sen ankomst. Denne indstilling gælder heller ikke for Power BI-regler.
Regler, der er baseret på Power BI-visualiseringer
Indbygget ventetid varierer afhængigt af tjenesten. Ventetid for eventstreams er forskellig fra ventetid for Power BI-visualiseringer. Der er to dele, der udgør ventetiden for regler, der er baseret på Power BI-visualiseringer: hyppigheden af forespørgsler om Power BI-visualiseringer, der er indbygget i systemet, og en forsinkelse, som Aktivatorens backend muligvis introducerer.
Power BI-regler evalueres, hver gang der modtages nye data i Aktivator. Aktivatoren henter nye data fra Power BI hver time. Det betyder, at hændelser, der opfylder regelbetingelsen, udløser en aktivering højst én time efter hændelsens indtræffer. Du kan få flere oplysninger under Hent data for Aktivator fra Power BI.