Semanttisten mallien lisäävä päivitys ja reaaliaikaiset tiedot

Lisäävä päivitys laajentaa ajoitettuja päivitystoimintoja tarjoamalla automatisoidun osion luonnin ja hallinnan semanttisille mallitaulukoille, jotka lataavat usein uusia ja päivitettyjä tietoja. Useimmissa malleissa yksi tai useampi taulukko sisältää tapahtumatietoja, jotka muuttuvat usein ja voivat kasvaa eksponentiaalisesti, kuten relaatio- tai tähtitietokannan rakenteen faktataulukko. Lisäävä päivityskäytäntö taulukon osioimiseksi, vain uusimpien tuontiosioiden päivittäminen ja valinnaisesti toisen DirectQuery-osion käyttö reaaliaikaisille tiedoille voi vähentää huomattavasti päivitettävien tietojen määrää. Samalla tämä käytäntö varmistaa, että tietolähteen uusimmat muutokset sisällytetään kyselyn tuloksiin.

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

  • Nopeasti muuttuvien tietojen päivitysjaksoja tarvitaan vähemmän. DirectQuery-tila saa uusimmat tietojen päivitykset kyselyiden käsittelyn aikana ilman suurta päivitysväliä.
  • Päivitykset ovat nopeampia. Vain uusimmat muuttuneet 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 potentiaalia.
  • Resurssien kulutus on vähäisempää. Kun päivitettävää tietoa on vähemmän, muistin ja muiden resurssien yleinen kulutus sekä Power BI-järjestelmissä että tietolähdejärjestelmissä on pienempi.
  • Suuret semanttiset mallit ovat käytössä. Semanttiset mallit, joissa on mahdollisesti miljardeja rivejä, voivat kasvaa ilman, että koko malli täytyy päivittää täysin jokaisella päivitystoiminnolla.
  • Asennus on helppoa. Lisäävän päivityksen käytännöt on määritetty Power BI Desktopissa vain muutamalla tehtävällä. Kun Power BI Desktop julkaisee raportin, palvelu ottaa nämä käytännöt automaattisesti käyttöön kunkin päivityksen yhteydessä.

Kun julkaiset Power BI Desktop -mallin palveluun, uuden mallin jokaisella taulukolla on yksi osio. Tämä yksittäinen osio sisältää kaikki kyseisen taulukon rivit. Jos taulukko on suuri, esimerkiksi kymmeniä miljoonia rivejä tai enemmän, 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, jotka voidaan päivittää harvemmin. Taulukon tiedot suodatetaan käyttämällä Power Queryn päivämäärä/aika-parametreja varatuilla, kirjainkoolta merkitsevällä nimellä RangeStart ja RangeEnd. Kun määrität lisäävän päivityksen Power BI Desktopissa, näiden parametrien avulla suodatetaan vain pieni tietojakso, joka on ladattu malliin. Kun Power BI Desktop julkaisee raportin Power BI -palvelu, palvelu luo lisäävän päivityksen ja historialliset osiot sekä valinnaisesti reaaliaikaisen DirectQuery-osion lisäävän päivityskäytännön asetusten perusteella. Palvelu ohittaa sitten parametriarvot, jotka suodattavat ja kyselevät kunkin osion tietoja kunkin rivin päivämäärä-/aika-arvojen perusteella.

Kunkin myöhemmän päivityksen yhteydessä kyselysuodattimet palauttavat vain ne rivit, jotka ovat parametrien dynaamisesti määrittämän päivitysjakson sisällä. Rivit, joilla on päivitysajan päivämäärä/aika, päivitetään. Rivit, joilla on päivämäärä/aika eivät enää päivitysjakson aikana, tulevat sitten osa historiallista aikaa, jota ei päivitetä. Jos lisäävän päivityksen käytäntöön sisältyy reaaliaikainen DirectQuery-osio, myös sen suodatin päivitetään siten, että se poimii päivitysjakson jälkeen tehdyt muutokset. Sekä päivitysjaksot että historialliset jaksot kootaan eteenpäin. Kun uusia lisäävän päivityksen osioita luodaan, päivitysosioista ei enää tule historiallisia osioita päivitysjaksolla. Ajan mittaan historialliset osiot muuttuvat vähemmän rakeisiksi, kun ne yhdistetään. Kun historiallinen osio ei ole enää käytännön määrittämällä historiallisella kaudella, se poistetaan kokonaan mallista. Tätä toimintaa kutsutaan vieritysikkunamalliksi.

Graphic representing a rolling window pattern.

Lisäävän päivityksen hienous on siinä, että palvelu käsittelee sen kaiken puolestasi määrittämiesi lisäävän päivityksen käytäntöjen perusteella. Itse asiassa prosessi ja siitä luodut osiot eivät näy palvelussa. Useimmissa tapauksissa tarvitaan vain hyvin määritetty lisäävän päivityksen käytäntö, jotta mallin päivityksen suorituskykyä voidaan parantaa huomattavasti. Reaaliaikaista DirectQuery-osiota tuetaan kuitenkin vain Premium-kapasiteettien malleissa. Power BI Premium mahdollistaa myös kehittyneemmät osio- ja päivitystilanteet XML for Analysis (XMLA) -päätepisteen kautta.

Edellytykset

Seuraavissa osissa kuvataan tuetut palvelupaketit ja tietolähteet.

Tuetut palvelupaketit

Lisäävää päivitystä tuetaan Power BI Premium-, käyttäjäkohtainen Premium-, Power BI Pro- ja Power BI Embedded -malleissa.

Uusimpien tietojen reaaliaikaista hankkimista DirectQueryn avulla tuetaan vain Power BI Premium-, käyttäjäkohtainen Premium- ja Power BI Embedded -malleissa.

Tuetut tietolähteet

Lisäävä päivitys ja reaaliaikaiset tiedot sopivat parhaiten jäsennettyihin relaatiotietolähteisiin, kuten SQL-tietokanta ja Azure Synapseen, mutta voivat myös toimia muissa tietolähteissä. Joka tapauksessa tietolähteen on tuettava seuraavia:

Päivämääräsuodatus – Tietolähteen on tuettava jotakin mekanismia tietojen suodattamiseksi päivämäärän mukaan. Relaatiolähteessä tämä on yleensä päivämääräsarake, jonka päivämäärä/aika-tietotyyppi tai kokonaisluku-tietotyyppi kohdetaulukossa. RangeStart- ja RangeEnd-parametrit, joiden on oltava päivämäärä/aika-tietotyyppi, suodattavat taulukkotietoja päivämääräsarakkeen perusteella. :n muodon yyyymmddkokonaisluvun korvaavien avainten päivämääräsarakkeille voit luoda funktion, joka muuntaa RangeStart- ja RangeEnd-parametrien päivämäärä-/aika-arvon 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.

Muiden tietolähteiden kohdalla RangeStart- ja RangeEnd-parametrit on välitettävä tietolähteeseen jollakin tavalla, joka mahdollistaa suodattamisen. Tiedostopohjaisissa tietolähteissä, joissa tiedostot ja kansiot on järjestetty päivämäärän mukaan, RangeStart- ja RangeEnd-parametreilla voidaan suodattaa tiedostot ja kansiot ladattavan tiedoston valitsemiseksi. Verkkopohjaisten tietolähteiden RangeStart- ja RangeEnd-parametrit voidaan integroida HTTP-pyyntöön. Esimerkiksi seuraavaa kyselyä voidaan käyttää AppInsights-esiintymän jäljitysten lisäävässä päivityksessä:

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

Kun lisäävää päivitystä määritetään, tietolähteestä suoritetaan Power Query -lauseke, joka sisältää RangeStart- ja RangeEnd-parametreihin perustuvan päivämäärä- ja aikasuodattimen. Jos suodatin on määritetty kyselyvaiheessa alkuperäisen lähdekyselyn jälkeen, on tärkeää, että kyselyn delegointi lähteeseen yhdistää alkuperäisen kyselyvaiheen vaiheisiin, jotka viittaavat RangeStart- ja RangeEnd-parametreihin. Esimerkiksi seuraavassa kyselylausekkeessa taitetaan Table.SelectRows , koska se seuraa Sql.Database heti vaihetta, ja SQL Server tukee delegointia lähteeseen:

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

Lopullisen kyselyn tuen delegointia lähteeseen ei edellytetä. Esimerkiksi seuraavassa lausekkeessa käytämme ei-taitettavaa NativeQueryä, mutta integroimme RangeStart- ja RangeEnd-parametrit suoraan SQL:ään:

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

Jos lisäävän päivityksen käytäntöön sisältyy reaaliaikaisten tietojen noutaminen 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 -palvelu tai paikallisessa tietoyhdyskäytävässä. Tämä poistaa tehokkaasti lisäävän päivityksen tarkoituksen.

Koska Kyselyn delegointi lähteeseen -tuki eroaa erityyppisille tietolähteille, on suoritettava tarkistus sen varmistamiseksi, että suodatinlogiikka sisältyy kyselyihin, joita 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öä. Tämä tarkistus on luotettava SQL-pohjaisissa tietolähteissä, kuten SQL-tietokanta, Azure Synapsessa, Oraclessa ja Teradatassa. Muut tietolähteet eivät kuitenkaan ehkä pysty tarkistamaan kyselyitä jäljittämättä. Jos Power BI Desktop ei pysty vahvistamaan kyselyitä, lisäävän päivityksen käytännön määritys -valintaikkunassa näkyy varoitus.

Screenshot of the query folding warning

Jos näet tämän varoituksen ja haluat varmistaa, että tarvittava kyselyn delegointi lähteeseen suoritetaan, 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 delegointia lähteeseen ei suoriteta, tarkista, että suodatinlogiikka sisältyy tietolähteelle välitettyyn kyselyyn. 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 perusteellisesti ohjeet Kyselyn delegointi lähteeseen -kohdasta 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 lisäratkaisun TMSL:n (Tabular Model Scripting Language) tai XMLA-päätepisteen kautta taulukko-objektimallilla (TOM), kaikkien osioiden, joko tuonnin tai DirectQueryn, on tehtävä tietokysely yhdestä lähteestä.

Muut tietolähdetyypit

Käyttämällä mukautettuja kyselyfunktioita ja kyselylogiikkaa lisäävää päivitystä voidaan käyttää muuntyyppisten tietolähteiden kanssa, jos suodattimia voidaan käyttää yhden kyselyn perusteella RangeStart ja RangeEnd voidaan välittää yhdessä kyselyssä, kuten tietolähteissä, kuten kansioon tallennetuissa Excel-työkirjatiedostoissa, SharePointin tiedostoissa ja RSS-syötteissä. Muista, että nämä ovat kehittyneitä skenaarioita, jotka edellyttävät lisämukautuksia ja testausta tässä kuvattujen lisäksi. Katso tämän artikkelin myöhemmästä Yhteisö-osiosta ehdotuksia siitä, miten saat lisätietoja lisäävän päivityksen käytöstä ainutlaatuisissa skenaarioissa.

Määräajat

Lisäävästä päivityksestä riippumatta Power BI Pro -mallien päivityksen aikaraja on kaksi tuntia , eivätkä ne tue reaaliaikaisten tietojen saamista DirectQueryllä. Premium-kapasiteetin mallien aikaraja on viisi tuntia. Päivitystoiminnot vaativat paljon prosessia ja muistia. Täysi päivitystoiminto voi käyttää jopa kaksinkertaisen määrän muistia pelkästään mallin edellyttämään määrään, koska palvelu ylläpitää tilannevedosta mallista muistissa, kunnes päivitystoiminto on suoritettu loppuun. Päivitystoiminnot voivat myös olla prosessiin intensiivisiä ja kuluttaa huomattavan määrän käytettävissä olevia suoritinresursseja. Päivitystoimintojen on myös perustuttava muuttuviin yhteyksiin tietolähteisiin ja kyseisten tietolähdejärjestelmien kykyyn palauttaa nopeasti kyselyn tuloste. Aikaraja on suoja, jolla rajoitetaan käytettävissä olevien resurssien ylikäyttöä.

Muistiinpano

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

Koska lisäävä päivitys optimoi päivitystoiminnot mallin osiotasolla, resurssien kulutusta voidaan vähentää merkittävästi. Samalla, jopa lisäävässä päivityksessä, elleivät ne käy XMLA-päätepisteen läpi, päivitystoiminnot sidotaan samoihin kahden tunnin ja viiden tunnin rajoituksiin. Tehokas lisäävän päivityksen käytäntö paitsi vähentää päivitystoiminnolla käsiteltyjen tietojen määrää myös vähentää malliisi 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 olevassa lausekkeessa commandTimeout-arvoksi määritetään kaksi tuntia SQL Serverin tietojen käyttöfunktion avulla. 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"

Jos Premium-kapasiteettien erittäin suurissa malleissa on todennäköisesti miljardeja rivejä, ensimmäinen päivitystoiminto voidaan käynnistää. Käynnistyksen avulla palvelu voi luoda mallille taulukko- ja osio-objekteja, mutta ei lataa ja käsittele tietoja mihinkään osioon. SQL Server Management Studion avulla voit määrittää osiot, jotka käsitellään erikseen, peräkkäin tai rinnakkain. Voit pienentää yksittäisessä kyselyssä palautettavien tietojen määrää ja ohittaa myös viiden tunnin aikarajan. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys – Estä aikakatkaisut ensimmäisen täyden päivityksen yhteydessä.

Nykyinen päivämäärä ja kellonaika

Nykyinen päivämäärä ja aika perustuvat järjestelmän päivämäärään päivityksen hetkellä. Jos ajoitettu päivitys on otettu käyttöön mallille palvelussa, 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) käyttäen määritettyä aikavyöhykettä, määritetään nykyinen päivämäärä ja aika Tyynenmeren ajan mukaan, ei Koordinoitu yleisaika (UTC), joka palauttaisi seuraavan päivän. Päivitystoiminnot, joita ei ole käynnistetty Power BI -palvelu kautta, kuten TMSL-päivityskomento, eivät ota huomioon ajoitettua päivityksen aikavyöhykettä.

Screenshot of Scheduled refresh dialog showing the Time zone input field

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

Tässä osiossa kuvataan tärkeitä lisäävän päivityksen ja reaaliaikaisten tietojen määrittämistä. Kun olet valmis tarkempiin vaiheittaisiin ohjeisiin, katso Lisäävän päivityksen ja reaaliaikaisten tietojen määrittäminen semanttisia malleja varten.

Lisäävän päivityksen määrittäminen tehdään Power BI Desktopissa. Useimmissa malleissa tarvitaan vain muutama tehtävä. Ota kuitenkin huomioon seuraavat asiat:

  • Kun olet julkaissut Power BI -palvelu, et voi julkaista samaa mallia uudelleen Power BI Desktopista. Uudelleenjulkaiseminen poistaa kaikki mallissa jo olevat osiot ja tiedot. Jos julkaiset Premium-kapasiteettiin, myöhemmät metatietorakenteen muutokset voidaan tehdä avoimen lähdekoodin ALM Toolkitin tai TMSL:n avulla. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys – vain metatietojen käyttöönotto.
  • Kun olet julkaissut Power BI -palvelu, et voi ladata mallia takaisin .pbix-tiedostona Power BI Desktopiin. Koska palvelun mallit voivat kasvaa niin suuriksi, niiden lataaminen ja avaaminen tavallisessa pöytätietokoneessa on mahdotonta.
  • Kun saat reaaliaikaisia tietoja DirectQueryn avulla, et voi julkaista mallia työtilaan, joka ei ole Premium-työtilassa. Reaaliaikaisten tietojen lisäävää päivitystä tuetaan vain Power BI Premiumissa.

Parametrien luominen

Jos haluat määrittää lisäävän päivityksen Power BI Desktopissa, luo ensin kaksi Power Queryn päivämäärä/aika-parametria varatuilla, kirjainkooltaan merkitsevällä nimellä RangeStart ja RangeEnd. Näitä parametreja, jotka on määritetty Power Query -editori Parametrien hallinta -valintaikkunassa, käytetään aluksi Suodattamaan Power BI Desktop -mallitaulukkoon ladatut tiedot sisältämään vain ne rivit, joilla on päivämäärä/aika kyseisellä ajanjaksolla. RangeStart edustaa vanhinta tai aikaisinta päivämäärää/aikaa ja RangeEnd edustaa uusinta tai viimeisintä päivämäärää/aikaa. Kun malli on julkaistu palveluun ja RangeEnd palvelu ohittaa sen automaattisesti kyselemään tietoja, RangeStart jotka on määritetty lisäävän päivityksen käytäntöasetuksissa määritetyllä päivitysjaksolla.

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

Screenshot of the Manage Parameters dialog showing the RangeStart and RangeEnd parameters.

Tietojen suodattaminen

Kun - ja RangeEnd -RangeStartparametrit on määritetty, käytät mukautettuja päivämääräsuodattimia taulukon päivämääräsarakkeessa. Käyttämäsi suodattimet valitsevat alijoukon tiedoista, jotka ladataan malliin, kun valitset Käytä.

Screenshot of column context menu with Custom Filter selected

FactInternetSales-esimerkissä luodessamme parametreihin perustuvia suodattimia ja otettuamme käyttöön vaiheita malliin ladataan kaksi päivää tietoja (noin 20 000 riviä).

Määritä käytäntö

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

Screenshot of the Incremental refresh and real-time data dialog showing the Incrementally refresh this table option on.

Table

Valitse taulukko -luetteloruudussa käytetään oletusarvoisesti taulukkoa, jonka valitsit Tietonäkymässä. Ota lisäävä päivitys käyttöön taulukolle liukusäätimellä. Jos taulukon Power Query -lauseke ei sisällä -ja-parametreihin RangeEnd perustuvaa RangeStart suodatinta, vaihtopainike ei ole käytettävissä.

Vaaditut asetukset

Arkistoi tiedot, jotka alkavat ennen päivityspäivämäärää -asetus, määrittää historiallisen ajanjakson, jolloin malliin sisällytetään päivämäärä/aika-rivit sekä nykyisen keskeneräisen historiallisen jakson rivit sekä päivitysjakson rivit nykyiseen päivämäärään ja aikaan saakka.

Jos määrität esimerkiksi viisi vuotta, taulukkoon tallennetaan historialliset tiedot vuoden osioina viiden viime vuoden ajalta. Taulukko sisältää myös rivejä kuluvalle vuodelle vuosineljänneksen, kuukauden tai päivän osioissa aina päivitysjaksoon asti.

Premium-kapasiteettien malleissa takautuvat historialliset osiot 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ästi päivittyvät tiedot, jotka alkavat ennen päivityspäivämäärää -asetusta, määrittävät lisäävän päivitysajan, jolloin kaikki rivit, joilla on päivämäärä/aika kyseisenä aikana, sisällytetään päivitysosioihin ja päivitetään kunkin päivitystoiminnon yhteydessä.

Jos esimerkiksi määrität päivitysväliksi kolme päivää jokaisen päivitystoiminnon yhteydessä, palvelu ohittaa RangeStart - ja RangeEnd -parametrit luodakseen kyselyn riveille, joiden päivämäärä ja aika on kolmen päivän aikana ja joiden alku ja loppu 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 voit odottaa, että palvelun FactInternetSales-mallitaulukko, joka on keskimäärin 10 000 uutta riviä päivässä, päivittää noin 30 000 riviä kunkin päivitystoiminnon yhteydessä.

Määritä jakso, joka sisältää vain niiden rivien vähimmäismäärän, joita tarvitaan tarkan raportoinnin varmistamiseen. Kun määrität käytäntöjä useammalle kuin yhdelle taulukolle, samaa RangeStart ja RangeEnd parametreja on käytettävä, vaikka kullekin taulukolle olisi määritetty eri säilön ja päivityksen jaksot.

Valinnaiset asetukset

Nouda uusimmat tiedot reaaliaikaisesti DirectQueryllä (vain Premium) -asetuksella voit noutaa uusimmat muutokset tietolähteestä valitusta taulukosta lisäävän päivitysjakson jälkeen DirectQueryn avulla. Kaikki rivit, joilla on lisäävää päivitysjaksoa uudempi päivämäärä/aika, sisällytetään DirectQuery-osioon ja noudetaan tietolähteestä jokaisessa mallikyselyssä.

Jos tämä asetus on käytössä esimerkiksi kunkin päivitystoiminnon yhteydessä, palvelu ohittaa RangeStart yhä - ja RangeEnd -parametrit luodakseen kyselyn riveille, joilla on päivämäärä/aika päivitysjakson jälkeen, ja aloitus on riippuvainen 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 myös. Tämäntyyppisen käytännön avulla palvelun FactInternetSales-mallitaulukko sisältää uusimmat tietopäivitykset.

Vain täysien päivien päivittäminen -asetus varmistaa, että koko päivän kaikki rivit sisältyvät päivitystoimintoon. Tämä asetus on valinnainen, ellet ota käyttöön Hae uusimmat tiedot reaaliaikaisesti DirectQuerylla (vain Premium). Oletetaan esimerkiksi, että päivitys on ajoitettu suoritettavaksi klo 4.00 joka aamu. Jos tietolähdetaulukossa näkyy uusia tietorivejä kyseisten neljän tunnin aikana keskiyön ja 4.00 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 kahdestoista kalenteripäivänä. Voit määrittää päivitysjaksoksi yhden kuukauden ja ajoittaa päivityksen suoritettavaksi kuukauden kahdestoista päivänä. Kun tämä vaihtoehto on valittuna, se esimerkiksi päivittää tammikuun tiedot 12. helmikuuta.

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

Havaitse tietojen muutokset -asetus mahdollistaa entistä valikoivamman päivityksen. Voit valita päivämäärä/aika-sarakkeen, jonka avulla tunnistetaan ja päivitetään vain ne päivät, joiden tiedot ovat muuttuneet. Tämä asetus olettaa, että tietolähteessä on kyseinen sarake, joka on yleensä valvontaa varten. Tämän sarakkeen ei tulisi olla sama sarake kuin jota käytetään tietojen jakamiseen -ja-parametreilla RangeStartRangeEnd . Tämän sarakkeen enimmäisarvo arvioidaan jokaisen lisäävän alueen ajanjakson osalta. Jos se ei ole muuttunut viimeisen päivityksen jälkeen, ajanjaksoa ei tarvitse päivittää, mikä voi mahdollisesti pienentää lisäävästi päivitettyjen päivien määrää kolmesta yhteen.

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:

  • Pysyviä ovat vain sarakkeen suurin arvo päivityshetkellä, mahdollisesti Power Query -funktion avulla.
  • 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ä sarakearvon säilyttäminen kokonaan.

Joissakin tapauksissa Havaitse tietojen muutokset*-asetuksen käyttöönottoa voidaan parantaa lisää. Saatat esimerkiksi haluta välttää viimeisimmän päivityksen sarakkeen säilymisen välimuistissa tai ottaa käyttöön tilanteita, joissa määritys/ohjetaulukko valmistellaan poiminta-muunnoslataus (ETL) -prosesseilla merkitsemään vain ne osiot, jotka on päivitettävä. Tällaisissa tilanteissa voit käyttää Premium-kapasiteeteissa TMSL:ää ja/tai tom:a tietojen muutosten toiminnan ohittamiseen. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys – Mukautetut kyselyt tietojen muutosten havaitsemiseksi.

Julkaise

Kun olet määrittänut lisäävän päivityskäytännön, julkaise malli palveluun. Kun julkaiseminen on valmis, voit suorittaa mallille ensimmäisen päivitystoiminnon.

Muistiinpano

Semanttiset mallit, joissa on lisäävän päivityksen käytäntö saadaksesi uusimmat tiedot reaaliaikaisesti DirectQueryllä, voidaan julkaista vain Premium-työtilaan.

Jos malli julkaistaan Premium-kapasiteeteille määritettyihin työtiloihin julkaistuissa malleissa, joiden uskot mallin kasvavan yli 1 Gt:n kokoon, voit parantaa päivitystoiminnon suorituskykyä ja varmistaa, että malli ei rajoita kokorajoituksia ottamalla käyttöön Suuren mallin tallennusmuoto ennen palvelun ensimmäisen päivitystoiminnon suorittamista. Lisätietoja on artikkelissa Suuret mallit Power BI Premiumissa.

Tärkeä

Kun Power BI Desktop julkaisee mallin palveluun, et voi ladata kyseistä .pbix-tiedostoa takaisin.

Refresh

Kun olet julkaissut palveluun, suoritat mallille ensimmäisen päivitystoiminnon. Tämän päivityksen tulee olla yksilöllinen (manuaalinen) päivitys, jotta voit seurata edistymistä. Ensimmäisen päivitystoiminnon suorittaminen voi kestää jonkin aikaa. Osiot on luotava, historialliset tiedot on ladattava, esimerkiksi suhteet ja hierarkiat on luotava tai luotava uudelleen, ja lasketut objektit on laskettava uudelleen.

Myöhemmät yksittäiset tai ajoitetut päivitystoiminnot ovat paljon nopeampia, koska vain lisäävän päivityksen osiot päivitetään. Muita käsittelytoimintoja on tehtävä edelleen, kuten osioiden yhdistäminen ja uudelleenlaskenta, mutta se vie yleensä paljon vähemmän aikaa kuin ensimmäinen päivitys.

Automaattinen raportin päivitys

Raporteissa, joissa käytetään lisäävän päivityksen käytäntöä ja saadaan uusimmat tiedot reaaliaikaisesti DirectQueryllä, automaattinen sivun päivitys kannattaa ottaa käyttöön kiinteällä aikavälillä tai muutoksen havaitsemisen perusteella niin, että 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 mallisi on Premium-kapasiteetissa, jossa on käytössä XMLA-päätepiste, lisäävää päivitystä voidaan laajentaa edistyneempiä skenaarioita varten. SQL Server Management Studion avulla voit esimerkiksi tarkastella ja hallita osioita, käynnistää ensimmäisen päivitystoiminnon tai päivittää takautuvat historialliset osiot. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys XMLA-päätepisteen avulla.

Yhteisö

Power BI:ssä on eloinen yhteisö, jossa MVP-, BI-ammattilaiset ja -kollegat jakavat asiantuntemusta keskusteluryhmistä, videoista, blogeista ja muusta. Kun opit lisäävästä päivityksestä, tutustu seuraaviin resursseihin: