Tietojoukkojen lisäävä päivitys ja reaaliaikaiset tiedot

Lisäävä päivitys laajentaa ajoitettuja päivitystoimintoja tarjoamalla automaattisen osion luomisen ja hallinnan tietojoukon taulukoille, jotka lataavat usein uusia ja päivitettyjä tietoja. Useimmissa tietojoukoissa tämä on yksi tai useampi taulukko, joka sisältää tapahtumatietoja, jotka muuttuvat usein ja voivat kasvaa eksponentiaalisesti, kuten faktataulukko relaatio- tai tähtitietokantarakenteessa. Lisäävän päivityksen käytäntö taulukon jakamiseen, vain uusimpien tuontiosioiden päivittäminen ja valinnaisesti ylimääräisen DirectQuery-osion hyödyntäminen reaaliaikaisille tiedoille voi vähentää huomattavasti päivitettävien tietojen määrää samalla kun varmistetaan, että myös tietolähteen uusimmat muutokset sisällytetään kyselyn tuloksiin.

Lisäävä päivitys ja reaaliaikaiset tiedot:

  • Vähemmän päivitysjaksoja nopeasti muuttuville tiedoille – DirectQuery-tila saa uusimmat tietopäivitykset, kun kyselyt käsitellään ilman suurta päivitysväliä.
  • Päivitykset ovat nopeampia – vain uusimmat muutetut tiedot on päivitettävä.
  • Päivitykset ovat luotettavampia – pitkäkestoisia yhteyksiä muuttuviin tietolähteisiin ei tarvita. Kyselyt lähdetietojen suorittamiseen nopeammin, mikä vähentää verkko-ongelmien häiriöitä.
  • Resurssien kulutus on vähäisempää : kun päivitettävien tietojen määrä on pienempi, muistin ja muiden resurssien yleinen kulutus sekä Power BI- että tietolähdejärjestelmissä on pienempi.
  • Ottaa käyttöön suuria tietojoukkoja – Tietojoukot, joissa voi olla miljardeja rivejä, voivat kasvaa ilman, että koko tietojoukkoa tarvitsee päivittää täysin kunkin päivitystoiminnon yhteydessä.
  • Helppo asennus – Lisäävän päivityksen käytännöt on määritetty Power BI Desktopissa muutamalla tehtävällä. Julkaisun jälkeen palvelu ottaa nämä käytännöt automaattisesti käyttöön kunkin päivityksen yhteydessä.

Kun julkaiset Power BI Desktop -mallin palveluun, jokaisella uuden tietojoukon taulukolla on yksi osio. Tämä yksittäinen osio sisältää kaikki kyseisen taulukon rivit. Jos taulukko on suuri, esimerkiksi kymmenien miljoonien rivien koko, kyseisen taulukon päivitys voi kestää kauan ja kuluttaa liikaa resursseja.

Lisäävän päivityksen myötä palvelu osioi ja erottaa dynaamisesti tiedot, jotka on päivitettävä usein tiedoista, joita voidaan päivittää harvemmin. Taulukkotiedot suodatetaan käyttämällä Power Queryn päivämäärä/aika-parametreja varatuilla, kirjainkoollaan merkitsevällä nimellä RangeStart ja RangeEnd. Kun määrität lisäävää päivitystä Power BI Desktopissa, parametreilla suodatetaan vain pieni määrä tietoja, jotka ladataan malliin. Kun palvelu julkaistaan ensimmäisen päivitystoiminnon yhteydessä, palvelu luo lisäävän päivityksen ja historialliset osiot ja valinnaisesti reaaliaikaisen DirectQuery-osion lisäävän päivityksen käytäntöasetusten perusteella ja ohittaa sitten parametriarvot suodattaakseen ja kyselläkseen jokaisen osion tiedot kunkin rivin päivämäärä-/aika-arvojen perusteella.

Kunkin seuraavan päivityksen yhteydessä kyselysuodattimet palauttavat vain ne rivit, jotka parametrit määrittävät dynaamisesti päivitysjaksolla. Rivit, joilla on päivitysajanjakson aikana päivämäärä/aika, päivitetään. Riveistä, joiden päivämäärä/aika ei enää ole päivitysjakson aikana, tulee osa historiallista kautta, jota ei päivitetä. Jos reaaliaikainen DirectQuery-osio sisältyy lisäävän päivityksen käytäntöön, myös sen suodatinta päivitetään niin, että se poimii päivitysjakson jälkeen tapahtuneet muutokset. Sekä päivitysjaksot että historialliset jaksot kootaan eteenpäin. Kun uusia lisäävän päivityksen osioita luodaan, päivitysosioista, jotka eivät enää päivitysjakson aikana tule historiallisia osioita. Ajan mittaan historialliset osiot muuttuvat vähemmän eriytetyiksi, kun ne yhdistetään. Kun historiallinen osio ei enää ole käytännön määrittämällä historiallisella kaudella, se poistetaan kokonaan tietojoukosta. Tätä kutsutaan vieritysikkunamalliksi.

Graphic representing a rolling window pattern.

Lisäävän päivityksen hienous on siinä, että palvelu käsittelee kaiken tämän puolestasi määrittämiesi lisäävän päivityksen käytäntöjen perusteella. Itse asiassa siitä luotu prosessi ja siitä luodut osiot eivät edes näy palvelussa. Useimmissa tapauksissa tietojoukon päivityksen suorituskyvyn parantaminen edellyttää vain tarkkaan määritettyä lisäävän päivityksen käytäntöä. Reaaliaikaista DirectQuery-osiota tuetaan kuitenkin vain Premium-kapasiteettien tietojoukoissa. Power BI Premium mahdollistaa myös kehittyneemmät osio- ja päivitysskenaariot XMLA-päätepisteen kautta.

Vaatimukset

Tuetut palvelupaketit

Lisäävää päivitystä tuetaan Power BI Premiumin, käyttäjäkohtaisen Premiumin, Power BI Pron ja Power BI Embeddedin tietojoukoissa.

Uusimpien tietojen hakemista reaaliaikaisesti DirectQueryn avulla tuetaan vain Power BI Premiumissa, käyttäjäkohtaisessa Premiumissa ja Power BI Embedded -tietojoukoissa.

Tuetut tietolähteet

Lisäävä päivitys ja reaaliaikaiset tiedot toimivat parhaiten jäsennettyjen relaatiotietolähteiden, kuten SQL-tietokannan ja Azure Synapsen, kanssa, mutta ne voivat toimia myös muissa tietolähteissä. Joka tapauksessa tietolähteesi on tuettava seuraavia:

Päivämääräsarake : Taulukon on sisällettävä päivämääräsarake, jonka tietotyyppi on päivämäärä/aika tai kokonaisluku. RangeStart- ja RangeEnd-parametrit (joiden on oltava päivämäärä/aika-tietotyyppi) suodattavat taulukkotietoja päivämääräsarakkeen perusteella. -lomakkeen kokonaisluvun korvaavien avainten päivämääräsarakkeille voit luoda funktion yyyymmdd, joka muuntaa Päivämäärä/aika-arvon RangeStart- ja RangeEnd-parametreissa vastaamaan päivämääräsarakkeen kokonaisluvun korvaavia avaimia. Lisätietoja on artikkelissa Lisäävän päivityksen määrittäminen – Päivämäärän ja ajan muuntaminen kokonaisluvuksi.

Kyselyn delegointi lähteeseen – Lisäävä päivitys on suunniteltu tietolähteille, jotka tukevat kyselyn delegointia lähteeseen. Power Query voi luoda yksittäisen kyselylausekkeen lähdetietojen noutamista ja muuntamista varten erityisesti silloin, kun uusimmat tiedot saadaan reaaliaikaisesti DirectQueryn avulla. Useimmat tietolähteet, jotka tukevat SQL-kyselyitä, tukevat kyselyn taittamista. Tietuetiedostojen, blob-objektien ja joidenkin verkkosyötteiden kaltaiset tietolähteet eivät useinkaan tue sitä.

Kun lisäävä päivitys määritetään, Tietolähteelle suoritetaan Power Query -lauseke, joka sisältää RangeStart- ja RangeEnd-parametreihin perustuvan päivämäärä- ja aikasuodattimen. Suodatin on itse asiassa kyselyyn sisältyvä muunnos , joka määrittää parametreihin perustuvan WHERE-lauseen. Jos tietolähde ei tue suodatinta, sitä ei voi sisällyttää kyselylausekkeeseen. Jos lisäävän päivityksen käytäntö sisältää reaaliaikaisten tietojen noutamisen DirectQueryllä, ei delegoitavia muunnoksia voi käyttää. Jos kyseessä on puhdas tuontitilakäytäntö ilman reaaliaikaisia tietoja, kyselyn koostemoduuli saattaa kompensoida ja käyttää suodatinta paikallisesti, mikä edellyttää taulukon kaikkien rivien noutamista tietolähteestä. Tämä voi hidastaa lisäävää päivitystä, ja prosessi voi johtaa resurssien loppumiseen joko Power BI -palvelussa tai paikallisessa tietoyhdyskäytävässä. Tämä estää käytännössä lisäävän päivityksen tarkoituksen.

Koska kyselyn delegoinnin lähteeseen -tuki on erilainen erityyppisille tietolähteille, on suoritettava tarkistus sen varmistamiseksi, että suodatinlogiikka sisältyy kyselyihin, jotka suoritetaan tietolähdettä vasten. Useimmissa tapauksissa Power BI Desktop yrittää suorittaa tämän tarkistuksen puolestasi määrittäessään lisäävän päivityksen käytäntöä. Sql-pohjaisten tietolähteiden, kuten SQL-tietokannan, Azure Synapsen, Oraclen ja Teradatan, osalta tämä tarkistus on luotettava. Muut tietolähteet eivät ehkä kuitenkaan pysty tarkistamaan kyselyitä jäljittämättä. Jos Power BI Desktop ei pysty vahvistamaan sitä, lisäävän päivityksen käytäntömääritysikkunassa näkyy varoitus.

Query folding warning

Jos näet tämän varoituksen ja haluat varmistaa, että tarvittava kyselyn delegointi lähteeseen on käynnissä, käytä Power Query -diagnostiikkaominaisuutta tai jäljitä kyselyt käyttämällä tietolähteen tukemaa työkalua, kuten SQL Profiler-työkalua. Jos kyselyn delegointi lähteeseen ei onnistu, tarkista, että suodatinlogiikka sisältyy kyselyyn, joka välitetään tietolähteelle. Jos näin ei ole, kysely sisältää todennäköisesti muunnoksen, joka estää lähteeseen delegoinnin.

Ennen kuin määrität lisäävän päivitysratkaisun, lue ja tutustu perusteellisesti ohjeisiin Kyselyn delegointi lähteeseen Power BI Desktopissa ja Power Query -kyselyn delegoinnissa lähteeseen. Näiden artikkelien avulla voit selvittää, tukevatko tietolähteesi ja kyselysi kyselyn delegointia lähteeseen.

Yksittäinen tietolähde

Kun määrität lisäävää päivitystä ja reaaliaikaisia tietoja Power BI Desktopin avulla tai määrität edistynyttä ratkaisua käyttämällä TMSL-kieltä (Tabular Model Scripting Language) tai TOM(Tabular Object Model) XMLA-päätepisteen kautta, kaikki osiot , olipa tuonnin tai DirectQueryn tehtävä tietokyselyjä yhdestä lähteestä.

Muut tietolähdetyypit

Käyttämällä muita mukautettuja kyselyfunktioita ja kyselylogiikkaa lisäävää päivitystä voidaan käyttää muuntyyppisten tietolähteiden kanssa, jotka antavat RangeStart- ja RangeEnd-pohjaisia suodattimia, voidaan välittää yksittäisessä kyselyssä. Esimerkiksi Excel-työkirjatiedostot, jotka on tallennettu kansioon, SharePoint-tiedostoihin tai RSS-syötteisiin. Muista, että nämä ovat kehittyneitä skenaarioita, jotka edellyttävät lisämukautuksia ja testausta tässä kuvattujen lisäksi. Katso tässä artikkelissa myöhemmin yhteisöosiosta ehdotuksia siitä, miten löydät lisätietoja lisäävän päivityksen käytöstä tällaisissa ainutlaatuisissa skenaarioissa.

Määräajat

Lisäävästä päivityksestä riippumatta Power BI Pro -tietojoukkojen päivitysaikarajoitus on kaksi tuntia . Ne eivät tue reaaliaikaisten tietojen noutamista DirectQueryn avulla. Premium-kapasiteetin tietojoukoissa aikaraja on viisi tuntia. Päivitystoiminnot käyttävät paljon prosessi- ja muistitehoa. Täydellinen päivitystoiminto voi käyttää jopa kaksinkertaisen määrän muistia pelkästään tietojoukon vaatimaan määrään, koska palvelu ylläpitää muistissa olevan tietojoukon tilannevedosta, kunnes päivitystoiminto on suoritettu. Päivitystoiminnot voivat myös olla prosessi-intensiivisiä, ja ne kuluttavat merkittävästi käytettävissä olevia suoritinresursseja. Päivitystoimintojen on perustuttava myös muuttuviin yhteyksiin tietolähteisiin ja kyseisten tietolähdejärjestelmien kykyyn palauttaa nopeasti kyselyn tuloste. Aikaraja on suojakeino, jolla rajoitetaan käytettävissä olevien resurssien ylikäyttöä.

Huomautus

Premium-kapasiteeteilla XMLA-päätepisteen kautta suoritettavilla päivitystoiminnoilla ei ole aikarajaa. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys XMLA-päätepisteellä.

Koska lisäävä päivitys optimoi päivitystoiminnot tietojoukon osiotasolla, resurssien kulutusta voidaan vähentää merkittävästi. Samaan aikaan, jopa lisäävän päivityksen tapauksessa, ellei XMLA-päätepisteen kautta, päivitystoiminnot sidotaan samoihin kahden ja viiden tunnin rajoituksiin. Tehokas lisäävän päivityksen käytäntö ei ainoastaan vähennä päivitystoiminnolla käsiteltävien tietojen määrää, vaan myös vähentää tietojoukkoon tallennettujen tarpeettomien historiallisten tietojen määrää.

Tietolähteen oletusaikarajoitus voi myös rajoittaa kyselyitä. Useimmat relaatiotietolähteet sallivat aikarajoitusten ohittamisen Power Query M -lausekkeessa. Esimerkiksi alla oleva lauseke käyttää SQL Serverin tietojen käyttöfunktiota määrittääkseen CommandTimeout-ominaisuudeksi kaksi tuntia. Kukin käytäntöalueiden määrittämä jakso lähettää kyselyn, joka noudattaa komennon aikakatkaisua.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

Premium-kapasiteettien erittäin suurissa tietojoukoissa, jotka todennäköisesti sisältävät miljardeja rivejä, ensimmäinen päivitystoiminto voidaan käynnistää. Käynnistyksen avulla palvelu voi luoda tietojoukolle taulukko- ja osio-objekteja, mutta ei ladata ja käsitellä tietoja millekään osiolle. SQL Server Management Studion avulla osiot voidaan sitten käsitellä yksitellen, peräkkäin tai rinnakkain. Ne molemmat voivat pienentää yksittäisessä kyselyssä palautettavien tietojen määrää mutta ohittaa myös viiden tunnin aikarajan. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys – Estä aikakatkaisut ensimmäisessä täydessä päivityksessä.

Nykyinen päivämäärä ja aika

Nykyinen päivämäärä ja aika perustuvat järjestelmän päivämäärään päivityksen ajankohtana. Jos ajoitettu päivitys on otettu käyttöön palvelun tietojoukolle, määritetty aikavyöhyke otetaan huomioon nykyistä päivämäärää ja aikaa määritettäessä. Sekä yksittäiset että ajoitetut päivitykset palvelun kautta huomaavat aikavyöhykkeen, jos se on käytettävissä. Esimerkiksi päivityksessä, joka tapahtuu klo 20.00 Tyynenmeren aikaa (Yhdysvallat ja Kanada), jossa on määritetty aikavyöhyke, määritetään nykyinen päivämäärä ja aika Tyynenmeren ajan mukaan, ei GMT:n (joka olisi muuten seuraava päivä). Päivitystoiminnot, joita ei ole käynnistetty palvelun kautta, kuten TMSL-päivityskomento, eivät ota huomioon ajoitettua päivityksen aikavyöhykettä.

Time zone

Lisäävän päivityksen ja reaaliaikaisten tietojen määrittäminen

Tässä käsittelemme tärkeitä lisäävän päivityksen ja reaaliaikaisten tietojen määrittämistä. Kun olet valmis tarkempiin vaiheittaisiin ohjeisiin, muista tutustua ohjeartikkeliin Tietojoukkojen lisäävän päivityksen ja reaaliaikaisten tietojen määrittäminen.

Lisäävä päivitys määritetään Power BI Desktopissa. Useimmissa malleissa tarvitaan vain muutama tehtävä. Muista kuitenkin seuraavat asiat:

  • Kun se julkaistaan palveluun, et voi julkaista samaa mallia uudelleen Power BI Desktopista. Uudelleenjulkaiseminen poistaisi kaikki tietojoukossa jo olevat osiot ja tiedot. Jos julkaiset Premium-kapasiteettiin, seuraavat metatietorakenteen muutokset voidaan tehdä avoimen lähdekoodin ALM Toolkitin tai TMSL:n (Tabular Model Scripting Language) avulla. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys – vain metatietojen käyttöönotto.
  • Kun tietojoukko julkaistaan palveluun, et voi ladata tietojoukkoa takaisin PBIX-tiedostona Power BI Desktopiin. Koska palvelun tietojoukot voivat kasvaa niin suuriksi, on mahdotonta ladata takaisin ja avata tavallisessa pöytätietokoneessa.
  • Kun saat reaaliaikaisia tietoja DirectQueryn avulla, et voi julkaista tietojoukkoa premium-työtilaan. Reaaliaikaisia tietoja sisältävää lisäävää päivitystä tuetaan vain Power BI Premiumissa.

Parametrien luominen

Kun määrität lisäävää päivitystä Power BI Desktopissa, luot ensin kaksi Power Queryn päivämäärä/aika-parametria varatuilla, kirjainkooltaan merkitsevällä nimellä RangeStart ja RangeEnd. Power Query -editorin Parametrien hallinta -valintaikkunassa määritettyjä parametreja käytetään aluksi suodattamaan Power BI Desktop -mallitaulukkoon ladatut tiedot niin, että ne sisältävät vain ne rivit, joilla on kyseisenä aikana päivämäärä/aika. Kun malli on julkaistu palveluun, palvelu ohittaa RangeStartin ja RangeEndin automaattisesti kyselemään tietoja, jotka on määritetty lisäävän päivityksen käytäntöasetuksissa määritetyn päivitysjakson mukaisesti.

Esimerkiksi FactInternetSales-tietolähdetaulukossa on keskimäärin 10 000 uutta riviä päivässä. Jos haluat rajoittaa malliin aluksi ladattujen rivien määrää Power BI Desktopissa, määritämme kahden päivän jakson RangeStart- ja RangeEnd-arvojen välillä.

Manage Parameters dialogue

Tietojen suodatus

Kun RangeStart- ja RangeEnd-parametrit on määritetty, voit käyttää mukautettuja päivämääräsuodattimia taulukon päivämääräsarakkeessa. Valitse käyttämäsi suodattimet tietojen alijoukko, joka ladataan malliin, kun valitset Käytä.

Custom filter

FactInternetSales-esimerkin avulla malliin ladataan noin 20 000 riviä, kun olemme luoneet parametreihin perustuvia suodattimia ja soveltaneet vaiheita.

Määritä käytäntö

Kun suodattimet on otettu käyttöön ja tietojen alijoukko on ladattu malliin, määrität lisäävän päivityskäytännön taulukolle. Kun malli on julkaistu palveluun, palvelu käyttää käytäntöä taulukon osioiden luomiseen ja hallintaan sekä päivitystoimintojen suorittamiseen. Määrität käytännön käyttämällä Lisäävä päivitys ja reaaliaikaiset tiedot -valintaikkunaa sekä vaadittujen asetusten että valinnaisten asetusten määrittämiseen.

Define policy dialog

Taulukko

Valitse taulukko -luetteloruudussa käytetään oletusarvoisesti taulukkoa, jonka valitset tietonäkymässä. Ota lisäävä päivitys käyttöön taulukolle liukusäätimellä. Jos taulukon Power Query -lauseke ei sisällä RangeStart- ja RangeEnd-parametreihin perustuvaa suodatinta, vaihtopainike on poistettu käytöstä.

Vaaditut asetukset

Arkistoi tiedot, jotka alkavat ennen päivityksen päivämäärää -asetusta, määrittävät historiallisen kauden, jolloin tietojoukkoon sisällytetään rivejä, joilla on päivämäärä/aika kyseisellä ajanjaksolla, sekä nykyisen keskeneräisen historiallisen kauden rivejä sekä päivitysjakson rivejä nykyiseen päivämäärään ja aikaan saakka.

Jos määritämme esimerkiksi viisi vuotta, taulukkomme tallentaa viimeiset viisi kokonaista vuotta historiallisia tietoja vuoden osioihin sekä rivit kuluvalle vuodelle vuosineljänneksen, kuukauden tai päivän osioissa päivitysjaksoon asti.

Premium-kapasiteettien tietojoukoissa takautuvia historiallisia osioita voidaan päivittää valikoivasti tämän asetuksen määrittämällä askelvälillä. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys – Osiot.

Lisäävä päivitystiedot alkavat ennen päivityksen päivämäärää -asetus määrittää lisäävän päivitysajan, jolloin kaikki rivit, joilla on kyseisenä ajanjaksona päivämäärä/aika, sisällytetään päivitysosioihin ja päivitetään kunkin päivitystoiminnon yhteydessä.

Jos määritämme esimerkiksi kolmen päivän päivitysjakson, jokaisen päivitystoiminnon yhteydessä palvelu ohittaa RangeStart- ja RangeEnd-parametrit luodakseen kyselyn riveille, joiden päivämäärä/aika on kolmen päivän ajanjaksolla, alkamis- ja päättyminen riippuu nykyisestä päivämäärästä ja ajasta. Rivit, joilla on päivämäärä/aika viimeisten kolmen päivän aikana nykyiseen päivitystoimintoaikaan saakka, päivitetään. Tämäntyyppisen käytännön avulla voimme odottaa FactInternetSales-tietojoukkotaulukkoa palvelussa, joka on keskimäärin 10 000 uutta riviä päivässä, päivittävän noin 30 000 riviä kunkin päivitystoiminnon yhteydessä.

Muista määrittää kausi, joka sisältää vain tarkan raportoinnin varmistamiseen tarvittavan rivien vähimmäismäärän. Jos määrität käytäntöjä useille taulukoille, samoja RangeStart- ja RangeEnd-parametreja on käytettävä, vaikka kullekin taulukolle määriteltäisiin eri säilö- ja päivitysjaksot.

Valinnaiset asetukset

Hae uusimmat tiedot reaaliaikaisesti DirectQueryllä (vain Premium) -asetuksen avulla voit noutaa uusimmat muutokset tietolähteen valitusta taulukosta lisäävän päivitysjakson jälkeen DirectQueryn avulla. Kaikki rivit, joiden päivämäärä ja aika on suurempi kuin lisäävä päivitysjakso, sisällytetään DirectQuery-osioon ja noudetaan tietolähteestä jokaisen tietojoukkokyselyn yhteydessä.

Jos se on käytössä esimerkiksi kunkin päivitystoiminnon yhteydessä, palvelu ohittaa yhä RangeStart- ja RangeEnd-parametrit luodakseen kyselyn riveille, joilla on päivitysjakson jälkeen päivämäärä/aika ja jotka alkavat riippua nykyisestä päivämäärästä ja ajasta. Rivit, joilla on päivämäärä/aika nykyisen päivitystoiminnon ajan jälkeen, sisällytetään. Tämäntyyppisen käytännön avulla voimme odottaa, että FactInternetSales-tietojoukkotaulukko sisältää myös uusimmat tietopäivitykset.

Päivitä vain täydet päivät -toiminto varmistaa, että kaikki koko päivän rivit sisältyvät päivitystoimintoon. Tämä asetus on valinnainen, ellet ota käyttöön Hae uusimmat tiedot reaaliaikaisesti DirectQuerylla (vain Premium) -asetuksella. Oletetaan, että päivitys on ajoitettu suoritettavaksi klo 4.00 joka aamu. Jos uudet tietorivit näkyvät tietolähdetaulukossa kyseisten neljän tunnin aikana keskiyön ja 4:00 AM:n välillä, et halua ottaa niitä huomioon. Jotkin liiketoiminnan mittarit, kuten barrelit päivässä öljy- ja kaasualalla, eivät ole mielekkäitä, kun osittaiset päivät ovat. Toinen esimerkki on taloushallinnon järjestelmän tietojen päivittäminen, kun edellisen kuukauden tiedot hyväksytään kuun 12. päivänä. Voit määrittää päivitysväliksi yhden kuukauden ja ajoittaa päivityksen suoritettavaksi kuukauden 12. päivänä. Kun tämä vaihtoehto on valittuna, se esimerkiksi päivittää tammikuun tiedot 12. helmikuuta.

Pidä mielessä, että ellei ajoitettua päivitystä ole määritetty UTC-aikavyöhykkeelle, palvelun päivitystoiminnot suoritetaan UTC-ajan kuluessa, mikä voi määrittää voimaantulopäivän ja täydet jaksot.

Tunnista tietojen muutokset -asetus mahdollistaa entistäkin valikoivamman päivityksen. Voit valita päivämäärä/aika-sarakkeen, jonka avulla tunnistetaan ja päivitetään vain ne päivät, jolloin tiedot ovat muuttuneet. Tämä olettaa, että tällainen sarake on olemassa tietolähteessä, joka on yleensä valvontaa varten. Tämä ei saa olla sama sarake, jota käytetään tietojen jakamiseen RangeStart- ja RangeEnd-parametreilla. Tämän sarakkeen suurin arvo lasketaan jokaisen lisäävän alueen ajanjakson osalta. Jos arvo ei ole muuttunut viimeisen päivityksen jälkeen, ajanjaksoa ei tarvitse päivittää. Tässä esimerkissä lisäävästi päivitetyt päivät voivat vähentyä entisestään 3:sta 1:een.

Nykyinen rakenne edellyttää, että sarake on pysyvä ja tallennettu välimuistiin tietojen muutosten havaitsemiseksi. Seuraavia tekniikoita voidaan käyttää kardinaliteetin ja muistin kulutuksen vähentämiseen:

  • Säilytä vain sarakkeen enimmäisarvo päivityshetkellä, ehkä käyttämällä Power Query -funktiota.
  • Vähennä tarkkuus hyväksyttävälle tasolle päivitystaajuutta koskevien vaatimusten mukaisesti.
  • Määritä mukautettu kysely tietojen muutosten havaitsemiseksi XMLA-päätepisteen avulla ja vältä sarakkeen arvon säilyttäminen kokonaan.

Joissakin tapauksissa Tietojen muutosten havaitseminen -asetuksen käyttöönottoa voidaan parannella edelleen. Saatat esimerkiksi haluta välttää viimeisen päivityksen sarakkeen säilymisen välimuistissa tai ottaa käyttöön tilanteita, joissa määritys/ohjetaulukko valmistellaan ETL-prosesseilla vain päivitettävien osioiden merkitsemistä varten. Tällaisissa tilanteissa Voit ohittaa tietojen muutosten toiminnan Premium-kapasiteeteissa TMSL -kielellä ja/tai taulukko-objektimallilla (TOM). Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys – Mukautetut kyselyt tietojen muutosten havaitsemiseksi.

Julkaise

Kun lisäävän päivityksen käytäntö on määritetty, julkaise malli palveluun. Kun julkaiseminen on valmis, voit suorittaa tietojoukolle ensimmäisen päivitystoiminnon.

Huomautus

Tietojoukot, joissa on lisäävän päivityksen käytäntö ja jotka saavat uusimmat tiedot reaaliaikaisesti DirectQueryllä, voidaan julkaista vain Premium-työtilaan.

Jos tietojoukko julkaistaan Premium-kapasiteeteille määritetyissä työtiloissa ja tietojoukko kasvaa yli 1 Gt:n, voit parantaa päivitystoiminnon suorituskykyä ja varmistaa, että tietojoukko ei enimmäiskokorajoituksia ottamalla suuren tietojoukon tallennusmuodon käyttöön ennen palvelun ensimmäistä päivitystoimintoa. Lisätietoja on artikkelissa Suuret tietojoukot Power BI Premiumissa.

Tärkeä

Kun olet julkaissut palveluun, et voi ladata PBIX:ää takaisin.

Päivitä

Kun olet julkaissut palveluun, suorita tietojoukolle ensimmäinen päivitystoiminto. Tämän pitäisi olla yksilöllinen (manuaalinen) päivitys, jotta voit seurata edistymistä. Ensimmäisen päivitystoiminnon suorittaminen voi kestää kauan. Osioita on luotava, historialliset tiedot on ladattava, objekteja, kuten suhteita ja hierarkioita, on luotava tai rakennettava uudelleen ja lasketut objektit lasketaan uudelleen.

Myöhemmät päivitystoiminnot ( joko yksittäiset tai ajoitetut) ovat paljon nopeampia, koska vain lisäävän päivityksen osiot päivitetään. Muita käsittelytoimintoja on vielä tehtävä, kuten osioiden yhdistäminen ja uudelleenlaskenta, mutta se vie yleensä vain pienen murto-osan ajasta alkuperäiseen päivitykseen verrattuna.

Automaattinen raportin päivitys

Raporteissa, joissa käytetään tietojoukkoa ja lisäävän päivityksen käytäntöä saadaksesi uusimmat tiedot reaaliaikaisesti DirectQueryn avulla, automaattinen sivun päivitys kannattaa ottaa käyttöön kiinteällä aikavälillä tai muutoksen havaitsemisen perusteella, jotta raportit sisältävät uusimmat tiedot viipymättä. Lisätietoja on artikkelissa Automaattinen sivun päivitys Power BI:ssä.

Kehittynyt lisäävä päivitys

Jos tietojoukkosi on Premium-kapasiteetissa, jossa XMLA-päätepiste on käytössä, lisäävää päivitystä voi jatkaa kehittyneessä skenaariossa. SQL Server Management Studion avulla voit esimerkiksi tarkastella ja hallita osioita, käynnistää ensimmäisen päivitystoiminnon tai päivittää takautuvia historiallisia osioita. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys XMLA-päätepisteen avulla.

Yhteisö

Power BI:ssä on eloisa yhteisö, jossa kansanedustajat, BI-ammattilaiset ja vertaisryhmät jakavat asiantuntemusta keskusteluryhmistä, videoista, blogeista ja muusta. Kun opit lisäävästä päivityksestä, muista tutustua näihin lisäresursseihin:

Seuraavat vaiheet

Lisäävän päivityksen määrittäminen tietojoukoille
Kehittynyt lisäävä päivitys XMLA-päätepisteellä
Lisäävän päivityksen vianmääritys
Tietovoiden lisäävä päivitys