Tietovoiden päivityksen ymmärtäminen ja optimointi

  • Artikkeli

Power BI -tietovoiden avulla voit muodostaa yhteyden, muuntaa, yhdistää ja jakaa tietoja analytiikkaa varten. Tietovoiden tärkein osa on päivitysprosessi, jossa otetaan käyttöön tietovoille lisäämäsi muunnosvaiheet ja päivitetään tiedot kohteissa itse.

Jos haluat tietää suoritusajoista, suorituskyvystä ja siitä, saatko tietovuosta kaiken hyödyn irti, voit ladata päivityshistorian, kun olet päivittämässä tietovuon.

Tutustu päivityksiin

Tietovoihin voidaan soveltaa kahdenlaisia päivitystyyppejä:

  • Full, joka suorittaa tietojen täydellisen huuhtelun ja uudelleenlatauksen.

  • Lisäävä (vain Premium), joka käsittelee tietojen alijoukon määrittämäsi suodattimena ilmaistujen aikapohjaisten sääntöjen perusteella. Päivämääräsarakkeen suodatin jakaa tiedot dynaamisesti Power BI -palvelu alueisiin. Kun lisäävä päivitys on määritetty, tietovuo muuttaa kyselyä automaattisesti sisältämään suodatuksen päivämäärän mukaan. Voit muokata automaattisesti luotua kyselyä hienosäätämällä tai mukauttamalla päivitystä Power Queryn Laajennettu editori. Jos tuot oman Azure Data Lake -Tallennus, näet aikaosittajat tiedoista määrittämäsi päivityskäytännön perusteella.

    Muistiinpano

    Lisätietoja lisäävästä päivityksestä ja sen toiminnasta on artikkelissa Lisäävän päivityksen käyttäminen tietovoiden kanssa.

Lisäävä päivitys mahdollistaa suuret tietovuot Power BI:ssä seuraavien etujen avulla:

  • Päivitykset ovat nopeampia ensimmäisen päivityksen jälkeen seuraavien seikkojen vuoksi:

    • Power BI päivittää käyttäjän määrittämät viimeiset N osiota (joissa osio on päivä/viikko/kuukausi ja niin edelleen), tai
    • Power BI päivittää vain tiedot, jotka on päivitettävä. Päivitä esimerkiksi vain viimeiset viisi päivää 10 vuoden semanttisesta mallista.
    • Power BI päivittää vain tiedot, jotka ovat muuttuneet, kunhan määrität sarakkeen, johon haluat tarkistaa muutokset.

  • Päivitykset ovat luotettavampia. Sinun ei enää tarvitse säilyttää pitkäkestoisia yhteyksiä lyhytkestoisiin lähdejärjestelmiin.

  • Resurssien kulutus on vähäisempää. Kun päivitettävää tietoa on vähemmän, muistin ja muiden resurssien yleinen kulutus on pienempi.

  • Aina kun mahdollista, Power BI käyttää osioissa rinnakkaista käsittelyä, mikä voi johtaa nopeampiin päivityksiin.

Jos päivitys epäonnistuu, tietoja ei päivitetä näissä päivitystilanteissa. Tiedot voivat olla vanhentuneita, kunnes viimeisin päivitys on valmis, tai voit päivittää ne manuaalisesti, jolloin ne voidaan suorittaa loppuun ilman virheitä. Päivitys tapahtuu osiossa tai entiteetissä, joten jos lisäävä päivitys epäonnistuu tai entiteetissä on virhe, koko päivitystapahtumaa ei tapahdu. Toisin sanoen, jos osio (lisäävän päivityksen käytäntö) tai entiteetti epäonnistuu tietovuon yhteydessä, koko päivitystoiminto epäonnistuu, eikä tietoja päivitetä.

Päivitysten ymmärtäminen ja optimointi

Jos haluat ymmärtää paremmin, miten tietovuon päivitystoiminto suoriutuu, tarkista tietovuon päivityshistoria siirtymällä johonkin tietovuostasi. Valitse tietovuon kohdalla Enemmän vaihtoehtoja (...). Valitse sitten Asetukset > Päivityshistoria. Voit myös valita tietovuon Työtilassa. Valitse sitten Enemmän vaihtoehtoja (...) > Päivityshistoria.

Screenshot of dataflows refresh history.

Päivityshistoria tarjoaa yleiskatsauksen päivittymisistä, mukaan lukien tyypin – pyydettäessä tai ajoitettuna, keston ja suorituksen tilan. Jos haluat nähdä tiedot CSV-tiedostona, valitse latauskuvake päivityskuvakkeen rivin oikeassa reunassa. Ladattu CSV sisältää seuraavassa taulukossa kuvatut määritteet. Premium-päivitykset tarjoavat lisätietoja ylimääräisten käsittely- ja tietovuo-ominaisuuksien perusteella verrattuna Pro-pohjaisiin tietovoihin, jotka sijaitsevat jaetussa kapasiteetissa. Näin ollen jotkin seuraavista mittareista ovat käytettävissä vain Premiumissa.

Kohde Kuvaus Pro Premium
Pyydetty Ajan päivitys ajoitettiin tai päivitystä napsautettiin nyt paikallisessa ajassa. ✔ ✔
Tietovuon nimi Tietovuon nimi. ✔ ✔
Tietovuon päivityksen tila Completed, Failed tai Skipped (entiteetille) ovat mahdollisia tilojen arvoja. Linkitettyjen entiteettien kaltaiset käyttötapaukset ovat syitä siihen, miksi ne voidaan ohittaa. ✔ ✔
Yksikön nimi Taulukon nimi. ✔ ✔
Osion nimi Tämä kohde on riippuvainen siitä, onko tietovuo Premium-ominaisuus vai ei, ja näkyykö Pro muodossa NA, koska se ei tue lisääviä päivitystä. Premium näyttää joko FullRefreshPolicyPartition- tai IncrementalRefreshPolicyPartition-[DateRange]. ✔
Päivityksen tila Yksittäisen entiteetin tai osion päivitystila, joka antaa tilan päivitettävien tietojen kyseiselle aikaosittajalle. ✔ ✔
Aloitusaika Premiumissa tämä on aika, jolloin tietovuo jonotettiin entiteetin tai osion käsittelyä varten. Tämä aika voi vaihdella, jos tietovoilla on riippuvuussuhteita, ja niiden on odotettava, että yläpuolisen tietovuon tulosjoukko aloittaa käsittelyn. ✔ ✔
Päättymisaika Päättymisaika on tietovuon entiteetin tai osion päättymisaika tarvittaessa. ✔ ✔
Kesto Tietovuon päivittymisen kulunut kokonaisaika ilmaistuna tiedoissa HH:MM:SS. ✔ ✔
Käsitellyt rivit Tietyn entiteetin tai osion tietovuomoduulin skannaamien tai kirjoittamien rivien määrä. Tämä kohde ei välttämättä aina sisällä tietoja suorittamasi toiminnon perusteella. Tiedot voidaan jättää pois, kun laskentamoduulia ei käytetä tai kun käytät yhdyskäytävää, kun tietoja käsitellään siellä. ✔
Käsitellyt tavut Tietovuomoduulin kirjoittamat tietyn entiteetin tai osion tiedot ilmaistuina tavuina.

Kun käytät yhdyskäytävää tässä tietovuossa, näitä tietoja ei anneta.		 ✔
Vahvistuksia enintään (kt) Vahvistus voi olla suurin vahvistusmuisti, joka on hyödyllinen muistin loppuneiden virheiden diagnosoinnissa, kun M-kyselyä ei ole optimoitu.

Kun käytät yhdyskäytävää tässä tietovuossa, näitä tietoja ei anneta.		 ✔
Suoritinaika Tietyn entiteetin tai osion osalta aika, joka ilmaistaan kohdassa HH:MM:SS, jonka tietovuomoduuli käytti muunnosten suorittamiseen.

Kun käytät yhdyskäytävää tässä tietovuossa, näitä tietoja ei anneta.		 ✔
Odotusaika Tietyn entiteetin tai osion osalta entiteetin odotustilassa käyttämä aika Premium-kapasiteetin kuormituksen mukaan. ✔
Laskentamoduuli Tietyn entiteetin tai osion kohdalla on tietoja siitä, miten päivitystoiminto käyttää laskentamoduulia. Arvot ovat:
-NA
-Taitettu
-Välimuistissa
- Välimuistiin tallennettu + taitettu

Nämä elementit kuvataan tarkemmin jäljempänä tässä artikkelissa.		 ✔
Error Tarvittaessa yksityiskohtainen virhesanoma kuvataan entiteetin tai osion mukaan. ✔ ✔

Ohjeet tietovuon päivittämiseen

Päivitystilastot tarjoavat arvokkaita tietoja, joiden avulla voit optimoida ja nopeuttaa tietovoiden suorituskykyä. Seuraavissa osissa kuvataan joitakin skenaarioita, mitä kannattaa varoa ja miten optimoida annettujen tietojen perusteella.

Hallinta

Tietovoiden käyttö samassa työtilassa mahdollistaa suoraviivaisen orkestroinnin. Sinulla voi olla esimerkiksi tietovoita A, B ja C yhdessä työtilassa ja ketjutusta kuten A > B > C. Jos päivität lähteen (A), myös loppuvaiheen entiteetit päivitetään. Jos päivität C-päivityksen, muut on päivitettava erikseen. Jos lisäät tietovuohon B uuden tietolähteen (joka ei sisälly A:aan), tietoja ei myöskään päivitetä osana orkestroinnia.

Haluat ehkä ketjuttaa kohteita, jotka eivät sovi Power BI:n hallittuun orkestrointiin. Näissä skenaarioissa voit käyttää ohjelmointirajapintoja ja/tai käyttää Power Automatea. Voit tarkistaa ohjelmallisen päivityksen ohjelmointirajapinnan dokumentaatiosta ja PowerShell-komentosarjasta . Power Automate -liitin mahdollistaa tämän toimenpiteen tekemisen koodia kirjoittamatta. Näet yksityiskohtaisia malleja, joissa on tarkat ohjeet peräkkäisiin päivityksiin.

Seuranta

Aiemmin tässä artikkelissa kuvattujen parannettujen päivitystilastojen avulla saat yksityiskohtaiset tietovuon päivitystiedot. Jos kuitenkin haluat nähdä tietovuot, joissa on koko vuokraajan laajuinen tai työtilan laajuinen päivitysten yleiskatsaus, voit esimerkiksi luoda valvontakoontinäytön, voit käyttää ohjelmointirajapintoja tai PowerAutomate-malleja. Vastaavasti yksinkertaisten tai monimutkaisten ilmoitusten lähettämiseen voi käyttää PowerAutomate-liitintä tai luoda oman mukautetun sovelluksen ohjelmointirajapintojen avulla.

Aikakatkaisuvirheet

Poiminta-, muuntamis- ja latausskenaarioiden suorittamiseen kuluvan ajan optimointi on ihanteellinen ratkaisu. Power BI:ssä sovelletaan seuraavia tapauksia:

  • Joillakin liittimillä on eksplisiittiset aikakatkaisuasetukset, jotka voit määrittää. Lisätietoja on artikkelissa Näyttöyhteys orit Power Queryssa.
  • Power BI -tietovuot, jotka käyttävät Power BI Prota, voivat myös kokea aikakatkaisuja pitkäkestoisille kyselyille entiteetissä tai tietovoissa. Tätä rajoitusta ei ole Power BI Premium -työtiloissa.

Aikakatkaisuohjeet

Power BI Pro -tietovoiden aikakatkaisurajat ovat seuraavat:

  • Kaksi tuntia yksittäisen entiteetin tasolla.
  • Kolme tuntia koko tietovuon tasolla.

Jos sinulla on esimerkiksi tietovuo, jossa on kolme taulukkoa, yksittäisessä taulukossa ei voi kestää yli kahta tuntia ja koko tietovuo aikakatkaistaan, jos kesto ylittää kolme tuntia.

Jos sinulla on aikakatkaisuja, harkitse tietovuokyselyiden optimointia ja harkitse kyselyn delegointia lähteeseen lähdejärjestelmissäsi.

Harkitse erikseen päivittämistä käyttäjäkohtaiseen Premiumiin, jota nämä aikakatkaisut eivät koske, ja tarjoaa suorituskyvyn lisääntymistä useiden käyttäjäkohtaisen Power BI Premium -ominaisuuksien vuoksi.

Pitkät kestot

Monimutkaisten tai suurten tietovoiden päivittyminen voi kestää enemmän aikaa, samoin kuin huonosti optimoidut tietovuot. Seuraavissa osioissa on ohjeita pitkien päivitysten keston lieventämiseen.

Ohjeita pitkien päivitysten kestoille

Ensimmäinen vaihe tietovoiden pitkien päivitysten keston parantamiseksi on tietovoiden luominen parhaiden käytäntöjen mukaisesti. Merkittävät mallit ovat seuraavat:

Seuraavaksi voit arvioida, voitko käyttää lisäävää päivitystä.

Lisäävän päivityksen käyttäminen voi parantaa suorituskykyä. On tärkeää, että jakosuodattimet lähetetään lähdejärjestelmään, kun kyselyitä lähetetään päivitystoimintoja varten. Suodattimen lähettäminen vaatii, että tietolähde tukee kyselyn delegointia lähteeseen, tai voit ilmaista liiketoimintalogiikan funktion tai muun keinon avulla, joka voi auttaa Power Querya poistamaan ja suodattamaan tiedostoja tai kansioita. Useimmat tietolähteet, jotka tukevat SQL-kyselyitä, tukevat kyselyn delegointia lähteeseen, ja jotkin OData-syötteet voivat myös tukea suodatusta.

Kuitenkin tietolähteet, kuten tietuetiedostot, blob-objektit ja ohjelmointirajapinnat, eivät yleensä tue suodatusta. Jos tietolähteen tausta ei tue suodatinta, sitä ei voi lähettää. Tässä tapauksessa koostemoduuli kompensoi ja ottaa suodattimen käyttöön paikallisesti, mikä saattaa edellyttää täydellisen semanttisen mallin noutamista tietolähteestä. Tämä toiminto voi hidastaa lisäävää päivitystä ja prosessi voi johtaa resurssien loppumiseen joko Power BI -palvelu tai paikallisessa tietoyhdyskäytävässä, jos sitä käytetään.

Kun otetaan huomioon kunkin tietolähteen kyselyn taitostuen eri tasot, varmista, että suodatinlogiikka sisältyy lähdekyselyihin. Tämän helpottamiseksi Power BI yrittää suorittaa tämän tarkistuksen puolestasi käyttäen Power Query Onlinen vaiheittaisia delegointiilmaisimia. Monet näistä optimoinnista ovat suunnitteluaikaisia kokemuksia, mutta päivityksen jälkeen sinulla on mahdollisuus analysoida ja optimoida päivitysten suorituskykyä.

Harkitse lopuksi ympäristön optimointia. Voit optimoida Power BI -ympäristön suurentamalla kapasiteettia, pienentämällä tietoyhdyskäytävien kokoa oikealle ja pienentämällä verkkoviivettä seuraavilla optimoinneilla:

  • Kun käytät kapasiteetteja, jotka ovat käytettävissä Power BI Premiumissa tai käyttäjäkohtaisessa Premiumissa, voit parantaa suorituskykyä suurentamalla Premium-esiintymääsi tai määrittämällä sisällön eri kapasiteettiin.

  • Yhdyskäytävää tarvitaan, kun Power BI:n on käytettävä tietoja, jotka eivät ole saatavilla suoraan Internetissä. Voit asentaa paikallisen tietoyhdyskäytävän paikalliseen palvelimeen tai näennäiskoneeseen.

    • Jos haluat tietoja yhdyskäytävän kuormituksista ja kokosuosituksista, katso Paikallisen tietoyhdyskäytävän koon määrittäminen.
    • Arvioi myös tietojen tuominen ensin valmistelutietovuohon ja viittaa siihen jatkokäsittelyssä käyttämällä linkitettyjä ja laskettuja entiteettejä.

  • Verkon viive voi vaikuttaa päivitysten suorituskykyyn kasvattamalla aikaa, jonka pyynnöt vaativat päästäkseen Power BI -palvelu, ja vastausten toimitusaikaa. Vuokraajille määritetään Power BI:ssä tietty alue. Lisätietoja vuokraajan sijainnista on kohdassa Organisaatiosi oletusalueen etsiminen. Kun vuokraajan käyttäjät käyttävät Power BI -palvelu, heidän pyyntönsä reititetään aina kyseiselle alueelle. Kun pyynnöt saavuttavat Power BI -palvelu, palvelu voi tämän jälkeen lähettää ylimääräisiä pyyntöjä esimerkiksi taustalla olevaan tietolähteeseen tai tietoyhdyskäytävään, joita verkkoviive koskee myös.

    • Työkalut, kuten Azure Speed Test , osoittavat verkkoviiveen asiakkaan ja Azure-alueen välillä. Yleensä voit minimoida verkkoviiveen vaikutuksen pyrkimalla pitämään tietolähteet, yhdyskäytävät ja Power BI -klusterin mahdollisimman lähellä. Samalla alueella oleminen on suosittavaa. Jos verkkoviive on ongelma, voit kokeilla yhdyskäytävien ja tietolähteiden sijoittamista lähemmäs Power BI -klusteria sijoittamalla ne pilvipalvelussa isännöitäviin näennäiskoneisiin.

Korkea suoritinaika

Jos näet suuren suoritinajan, sinulla on todennäköisesti kalliita muunnoksia, joita ei ole delegoitu lähteeseen. Suorittimen korkea aika johtuu joko käytössä olevien vaiheiden määrästä tai tehtyjen muunnosten tyypistä. Jokainen näistä mahdollisuuksista voi johtaa suurempiin päivitysaikoihin.

Ohjeita korkeaan suoritinaikaan

Suorittimen korkean ajan optimoinnilla on kaksi vaihtoehtoa.

Käytä ensin kyselyn delegointia lähteeseen itse, minkä pitäisi pienentää tietovuon käsittelymoduulin kuormitusta suoraan. Kyselyn delegointi lähteessä mahdollistaa sen, että lähdejärjestelmä tekee suurimman osan työstä. Tietovuo voi sitten välittää kyselyt lähteen alkuperäisellä kielellä sen sijaan, että se joutuisi suorittamaan kaikki laskennan muistissa alkuperäisen kyselyn jälkeen.

Kaikki tietolähteet eivät voi suorittaa kyselyn delegointia lähteeseen, ja vaikka kyselyn delegointi lähteeseen olisi mahdollista, jotkin tietovuot saattavat suorittaa joitakin muunnoksia, jotka eivät voi delegoida lähteeseen. Tässä tapauksessa Power BI:n tarjoama parannettu laskentamoduuli tarjoaa mahdollisuuden parantaa suorituskykyä jopa 25-kertaiseksi erityisesti muunnoksia varten.

Laskentamoduulin käyttäminen suorituskyvyn maksimoimiseen

Vaikka Power Queryllä on suunnitteluajan näkyvyys kyselyn lähteeseen delegoinnissa, laskentamoduulin sarakkeessa on tietoja siitä, käytetäänkö itse sisäistä moduulia. Laskentamoduulista on hyötyä, kun sinulla on monimutkainen tietovuo ja suoritat muunnoksia muistissa. Tässä tilanteessa parannetut päivitystilastot voivat olla hyödyllisiä, koska laskentamoduulin sarakkeessa on tietoja siitä, käytettiinkö itse moduulia vai ei.

Seuraavissa osioissa annetaan ohjeita laskentamoduulin ja sen tilastotietojen käytöstä.

Varoitus

Suunnitteluaikana editorin lähteeseen delegoinnin ilmaisin saattaa näyttää, että kysely ei taita tietoja toisesta tietovuosta. Tarkista lähteen tietovuo, jos parannettu käsittely on käytössä. Näin varmistat, että lähteen tietovuo on otettu käyttöön.

Laskentamoduulin tilaa koskevat ohjeet

Parannetun laskentamoduulin ottaminen käyttöön ja eri tilojen ymmärtäminen on hyödyllistä. Sisäisesti parannettu laskentamoduuli käyttää SQL-tietokantaa tietojen lukemiseen ja tallentamiseen. Tässä on parasta suorittaa muunnokset kyselymoduulia vasten. Seuraavissa kappaleissa annetaan erilaisia tilanteita sekä ohjeita siitä, mitä kunkin tulee tehdä.

NA – Tämä tila tarkoittaa, ettei laskentamoduulia ole käytetty, koska:

  • Käytät Power BI Pro -tietovoita.
  • Olet eksplisiittisesti poistanut laskentamoduulin käytöstä.
  • Käytät kyselyn delegointia lähteeseen.
  • Suoritat monimutkaisia muunnoksia, jotka eivät voi käyttää kyselyjen nopeuttamiseen käytettävää SQL-moduulia.

Jos koet pitkiä kestoja ja saat yhä tilaksi NA, varmista, että se on otettu käyttöön eikä se ole vahingossa pois päältä. Suosittelemme esimerkiksi, että käytät valmistelutietovoita tietojen noutamiseksi aluksi Power BI -palvelu ja koostat sitten tietovoita näiden tietojen päälle, kun ne ovat valmistelutietovuossa. Tämä malli voi pienentää lähdejärjestelmien kuormitusta ja yhdessä laskentamoduulin kanssa nopeuttaa muunnoksia ja parantaa suorituskykyä.

Välimuistissa – Jos näet välimuistiin tallennetun tilan, tietovuon tiedot on tallennettu laskentamoduuliin ja niihin voidaan viitata osana toista kyselyä. Tämä tilanne on ihanteellinen, jos käytät sitä linkitettynä entiteettinä, koska laskentamoduuli tallentaa tiedot välimuistiin jatkokäyttöön. Välimuistiin tallennettuja tietoja ei tarvitse päivittää useita kertoja samassa tietovuossa. Tämä tilanne on mahdollisesti ihanteellinen myös, jos haluat käyttää sitä DirectQuerylle.

Välimuistiin tallennettaessa suorituskykyvaikutukset alkuperäiseen käsittelyyn kannattaa myöhemmin, samassa tietovuossa tai eri tietovuossa samassa työtilassa.

Jos entiteetillä on pitkä kesto, sinun kannattaa ehkä poistaa laskentamoduuli käytöstä. Jotta entiteetti voidaan tallentaa välimuistiin, Power BI kirjoittaa sen tallennustilaan ja SQL:ään. Jos kyseessä on yksittäinen käyttö -entiteetti, käyttäjille suorituskykyedut eivät välttämättä ole kaksinkertaisen käsittelymäärän pienentämisen arvoisia.

Taitettu – taitettu tarkoittaa, että tietovuo pystyi käyttämään SQL-laskentaa tietojen lukemiseen. Laskettu entiteetti käytti taulukkoa SQL:stä tietojen lukemiseen, ja käytetty SQL liittyy kyselyn rakenteisiin.

Taitettu tila näkyy, jos kun käytät paikallisia tai pilvipalvelutietolähteitä, latasit ensin tiedot valmistelutietovuohon ja viittasit siihen tässä tietovuossa. Tämä tila koskee vain entiteettejä, jotka viittaavat toiseen entiteettiin. Tämä tarkoittaa sitä, että kyselysi suoritettiin SQL-moduulin avulla, ja niitä voidaan parantaa SQL-käsittelyllä. Jos haluat varmistaa, että SQL-moduuli käsittelee muunnoksesi, käytä SQL-delegointia tukevia muunnoksia, kuten yhdistämistä (yhdistämistä), ryhmittelyperustetta (koostamista) ja liittämistoimintoja (union) Kyselyeditori.

Välimuistiin tallennettu + taitettu – Kun välimuistiin lisätään + taitetaan, tietojen päivitys on todennäköisesti optimoitu, koska sinulla on entiteetti, joka viittaa toiseen entiteettiin ja johon toinen entiteetti viittaa yläpuoliseen entiteettiin. Tämä toiminto suoritetaan myös SQL:n päällä, joten se voi myös parantaa SQL-käsittelyä. Jotta suorituskyky on mahdollisimman paras mahdollinen, käytä muunnoksia, jotka tukevat SQL-delegointia, kuten yhdistämistä (yhdistämistä), ryhmittelyperustetta (koostamista) ja liittämistoimintoja (yhdistämistoimintoja) Kyselyeditori.

Laskentamoduulin suorituskyvyn optimoinnin ohjeet

Seuraavissa vaiheissa mahdollistat kuormitusten käynnistämisen laskentamoduulissa, mikä parantaa aina suorituskykyä.

Lasketut ja linkitetyt entiteetit samassa työtilassa:

Tietojen käsittely on keskityttävä saamaan tiedot tallennustilaan mahdollisimman nopeasti. Käytä suodattimia vain, jos ne vähentävät yleistä semanttista mallikokoa. Pidä muunnoslogiikka erillään tästä vaiheesta. Erota sitten muunnos- ja liiketoimintalogiikka erilliseen samassa työtilassa olevaan tietovuohon. Käytä linkitettyjä tai laskettuja entiteettejä. Tämän ansiosta moduuli voi aktivoida ja kiihdyttää laskennan. Yksinkertaisen analogian vuoksi se on kuin ruoanvalmistus keittiössä: ruoanvalmistus on yleensä erillinen vaihe ja eri asia kuin raaka-aineiden kerääminen, ja se on myös välttämätöntä, jotta ruoan voi panna uuniin. Vastaavasti sinun on valmisteltava logiikka erikseen, ennen kuin se voi hyödyntää laskentamoduulia.

Varmista, että suoritat taittotoiminnot, kuten yhdistämiset, liittämiset, muunnokset ja muut.

Voit myös luoda tietovoita julkaistujen ohjeiden ja rajoitusten puitteissa.

Kun laskentamoduuli on käytössä, mutta suorituskyky on hidas:

Tee seuraavat toimenpiteet, kun tutkit tilanteita, joissa käsittelymoduuli on käytössä, mutta suorituskyky on huono:

  • Rajoita työtilassa olevia laskettuja ja linkitettyjä entiteettejä.
  • Jos alkuperäinen päivityksesi tapahtuu niin, että laskentamoduuli on käytössä, tiedot kirjoitetaan Lake-tallennustilaan ja välimuistiin. Tämä kaksoiskirjoitus johtaa siihen, että päivitykset ovat hitaampia.
  • Jos sinulla on tietovuo, joka linkittää useisiin tietovoihin, ajoita lähdetietovoiden päivitykset niin, etteivät ne päivity kaikki samanaikaisesti.

Huomioitavat asiat ja rajoitukset

Power BI Pro -käyttöoikeudessa tietovoiden päivitysrajoitus on 8 päivitystä päivässä.

Liittyvä sisältö