Aktivointiviive

Fabric Activator suorittaa reaaliaikaisia tietoja koskevia sääntöjä. Tulokset ovat lähes välittömiä, mutta erilaiset tekijät voivat aiheuttaa viivettä. Useimmissa tapauksissa tätä viivettä ei huomaa, mutta joissain tapauksissa se voi olla jopa 10 minuuttia. Tarkkojen ja ajantasaisten tietojen saaminen on tärkeä huomioitava seikka, kun luot ja vastaanotat sääntöjä. Tässä artikkelissa käydään läpi prosesseja ja asetuksia, jotka määrittävät tapahtumien sisällyttämisen ja sääntörakenteen tasapainon sekä kuinka nopeasti Activator lähettää aktivaation. Esimerkiksi, pitäisikö Activatorin sallia enemmän datan saapumista ja sisällyttämistä, vai pitäisikö sen varmistaa, että vastaanottajat saavat hälytyksensä tiettyyn aikaan? Ja miten sääntörakenne vaikuttaa siihen, kuinka nopeasti Aktivaattori lähettää aktivoinnin vastaanottajille?

Kolme tärkeää tekijää vaikuttavat sääntöjen aktivointiviiveeseen:

• Myöhäisen saapumisen sietokyky.
• Backend-prosessoinnin viive.
• Aggregaatioviive.

Myöhäinen saapumistoleranssi

Suoratoistodatassa tapahtumat eivät aina saapu oikeassa järjestyksessä tai ajallaan. Tapahtuman aika (milloin se tapahtui) voi olla säännön aikaikkunan sisällä, mutta sen saapumisaika (kun aktivaattori sai sen) voi jäädä tämän ikkunan ulkopuolelle – mikä tekee tapahtumasta myöhässä. Oletuksena Aktivaattori poistaa myöhäiset tapahtumat sääntöjen arvioinnista.

Myöhäisten tapahtumien odotusaika -asetus säätelee, kuinka kauan aktivaattori odottaa ennen arviointiikkunan sulkemista, antaen myöhäisille tapahtumille mahdollisuuden saapua. Tämä asetus löytyy sääntömäärittely-näytönLisäasetukset-osiosta. Jos haluat oppia konfiguroimaan, katso Myöhäisen saapumisen toleranssiasetus.

Taustakäsittelyn viive

Aktivaattorin saattaa joutua käsittelemään sääntö ennen sen aktivoitumista, mikä voi aiheuttaa jopa minuutin viiveen. Esimerkiksi, jos sääntöä verrataan aiempaan tapahtumasarjaan, Aktivaattori hakee aiemmat tiedot, tekee vertailun ja laskee tuloksen. Toisena esimerkkinä, jos sääntö koskee 10 miljoonaa datariviä, Activatorin käsittely kyseisestä tilavuudesta aiheuttaa myös viivettä.

Koosteen viive

Jos koostetta käytetään säännön määrityksessä, sääntö aktivoidaan vain, kun se täyttää määritetyt aikaikkunat. Esimerkiksi, sanotaan, että rakennetaan sääntö, joka keskiarvoistaa datan neljän tunnin aikana. Jos sääntöehtoja täyttävä tapahtuma vastaanotetaan klo 12, sääntö käynnistyy klo 16. Viive johtuu aggregaatioasetuksista. Vaikka sääntö sisältää yksinkertaisen koosteen, kuten keskiarvon, aktivointi ei voi lähettää aktivointia, ennen kuin Activator suorittaa koosteen saapuvissa tapahtumatiedoissa.

Tausta-ajan käsitteet

Jotta keskustelu olisi parempaa, määritellään muutamia taustakonsepteja.

• Tapahtuman aika: Päivämäärä, jolloin alkuperäinen tapahtuma tapahtui. Se on osa tapahtuman hyötykuormaa. Esimerkiksi hetki, jolloin anturi havaitsee auton lähestyvän maksupistettä, on tapahtumaaika.
• Käsittelyaika: Aika, jonka aikana käsittelyjärjestelmä vastaanottaa ja havainnee tapahtuman. Esimerkiksi, kun maksupisteanturi näkee auton, aika, jolloin tietokonejärjestelmä vastaanottaa ja käsittelee anturin tiedot, on käsittelyaika.
• Saapumisaika (vesileima tai käsittelyaika): Merkki, joka ilmaisee, milloin tapahtumatiedot saavuttavat Activatorin. Saapuvia tapahtumatietoja ei koskaan tallenneta tietovirtojen luonteen mukaan, joten saapumisajat ilmaisevat Activatorin edistymisen tiettyyn tietovirran kohtaan. Tässä vaiheessa activator voi tuottaa täydellisiä, oikeita ja toistettavissa olevia tuloksia, joita ei tarvitse sällätä. Tässä vaiheessa aktivoija voi aloittaa tietojen käsittelyn. Aktivaattori käsittelee dataa ennustettavasti ja toistettavasti. Esimerkiksi, jos Aktivaattorin täytyy laskea tiedot uudelleen virheiden käsittelyä varten, se voi käyttää saapumisaikoja turvallisina aloitus- ja lopetuspisteinä. Esimerkiksi, kun maksupistejärjestelmä on vastaanottanut kaikki autohavainnot klo 9.05 asti, saapumisaikamerkki siirtyy klo 9.05 asti. Kaikki havainnot, jotka saapuvat sen jälkeen — vaikka tapahtumaaika olisi ennen klo 9:05 — ovat myöhässä.

Myöhäinen saapuminen tapahtuu, kun säännöllä on aikaparametri ja Tapahtuma-aika on kyseisen aikaparametrin sisällä, mutta saapumisaika jää sen ulkopuolelle. Käyttäen maksupisteen esimerkkiä: anturi tunnistaa auton ja tapahtumaaika on säännön aikaikkunan sisällä. Jos sensori kuitenkin lähettää havaitsemisen liian kauan — esimerkiksi verkon ruuhkautumisen vuoksi — tapahtuma saapuu Activatorille ikkunan sulkeuduttua. Aktivaattori pitää tapahtumaa myöhässä. Jos haluat, että myöhästyneet saapuvat otetaan mukaan, aseta myöhästyneiden tapahtumien odotusaikaLisäasetuksista.

Lisätietoja tästä aiheesta on Tyler Akidaun blogikirjoituksissa Streaming 101 ja Streaming 102.

Myöhäisen saapumisen salliva toleranssiasetus

Voit säätää myöhäisen saapumisen toleranssiasetuksen. Oletusarvo on kaksi minuuttia. Tämä asetus lisää viivettä. Säännöillä, jotka luot odotusajalla, on minimiviive, joka vastaa konfiguroitua kestoa. Kun luot sääntöä, päätä, käytätkö oletusarvoa vai muutatko sitä. Asetus varmistaa, että myöhäiset ja epäjärjestyksessä olevat tapahtumat voivat tulla mukaan sääntöjen arviointiin. Jos tapahtuma ylittää myöhäisen saapumisen toleranssin, Aktivaattori ei ota sitä huomioon. Tapahtumat, joilla on saapumisaika tuon kynnyksen jälkeen, eivät ole mukana.

Kaiken kaikkiaan pohdi, onko tärkeämpää:

• Odota myöhäisiä arvopisteitä, tai
• Suorita sääntö mahdollisesti puutteellisilla tiedoilla, jotta sääntö aktivoituu nopeammin. 

Tässä esimerkissä arvopisteitä mitataan 15 minuutin lisäyksillä. Kolme ensimmäistä pistettä, jotka ovat sinisiä, näkyvät aikaikkunassa. Neljäs piste, joka on oranssi, ei. Tapahtuma-aika on 15 minuutin välein, mutta activator ei käytä tapahtumaa 15 minuutin välein. Activator arvioi säännön vain tiedoille, joiden saapumisaika on 15 minuutin kuluessa. Ellei myöhästymisen toleranssia kasvateta, datapisteitä, jotka saapuvat ikkunan sulkeuduttua, eivät sisälly.

Aktivaattori ei voi ottaa huomioon viiveitä tietolähteistäsi. Esimerkiksi IoT-anturit voivat olla offline-tilassa tunnin ajan. Kun he palaavat verkkoon, Aktivaattori voi vastaanottaa tiedot, mutta tiedot viivästyivät tunnin verran tuosta offline-tilasta, mikä tapahtuu Aktivaattorin ulkopuolella.

Tässä on toinen esimerkki.

Luot säännön, joka laskee keskilämpötilan minuutteina. Myöhäisten tapahtumien odotusaika on asetettu oletuksena kahteen minuuttiin. Aktivaattori sisältää lämpötilaarvot 20 ja 30, ja laskee keskiarvon 25. Aktivaattori ei kuitenkaan sisällä myöhässä saapuvaa 40 asteen tapahtumaa ennen seuraavaa sääntöaktivointia.

Power BI -visualisointeihin perustuvat säännöt

Sisäinen viive vaihtelee palvelun mukaan. Tapahtumavirtojen viive eroaa Power BI:n visuaalien viiveestä. Kaksi tekijää vaikuttavat Power BI:n visuaaleihin perustuvien sääntöjen viiveeseen: järjestelmään rakennettujen Power BI:n visuaalien kyselyjen tiheys sekä viive, jonka Activatorin taustajärjestelmä saattaa aiheuttaa.

Power BI -sääntöjä arvioidaan aina, kun uusia tietoja saapuu Aktivointi-toiminnossa. Oletuksena Aktivaattori kysyy Power BI:tä kerran tunnissa, mikä tarkoittaa, että sääntöehtoa täyttävät tapahtumat laukaisevat aktivoinnin enintään tunnin kuluttua tapahtumasta. Voit muuttaa tätä taajuutta tietolähteiden asetuksissa. Lisätietoja löytyy Query frequency for query data sources ja Create Power BI alerts and fine ne in Fabric Activator.