Semanttisten mallien lisäävä päivitys ja reaaliaikaiset tiedot
Power BI:n semanttisten mallien lisäävä päivitys ja reaaliaikaiset tiedot tarjoavat tehokkaita tapoja käsitellä dynaamisia tietoja ja parantaa mallin päivityksen suorituskykyä. Kun osion luominen ja hallinta automatisoidaan, lisäävä päivitys vähentää päivitettävien tietojen määrää ja sallii reaaliaikaisten tietojen lisäämisen. Tässä artikkelissa kerrotaan, miten voit määrittää Power BI:n lisäävän päivityksen ominaisuudet ja käyttää niitä nopeasti etene olevien tietojen tallentamiseksi ja suorituskyvyn parantamiseksi.
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 -palveluun, 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.
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.
Vaatimukset
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äkohtaisessa Premiumissa ja Power BI Embedded -malleissa.
Tuetut tietolähteet
Lisäävä päivitys ja reaaliaikaiset tiedot sopivat parhaiten jäsennettyihin ja relaatiotietolähteisiin, kuten SQL-tietokantaan ja Azure Synapse, 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. Jos kyseessä on relaatiolähde, tämä on yleensä päivämääräsarake, jonka päivämäärä/aika- tai kokonaisluku-tietotyyppi on 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 ja reaaliaikaisten tietojen määrittäminen – DateTime-funktion 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 määritetään 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 lähde lähteeseen, 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 ei tarvitse tukea lähteeseen delegointia. Esimerkiksi seuraavassa lausekkeessa käytämme ei-taitettavaa NativeQuery-kyselyä, 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 -palvelussa 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-tietokannassa, Azure Synapse, 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.
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 seuraava lauseke käyttää SQL Serverin tietojen käyttöfunktiota ja asettaa 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"
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
Oletusarvoisesti nykyinen päivämäärä ja aika määritetään UTC-ajan (Coordinated Universal Time) perusteella päivityshetkellä. Pyydettäessä ajoitetussa ja REST-ohjelmointirajapinnan päivityksessä voit määrittää päivitys-kohdassa eri aikavyöhykkeen, joka otetaan huomioon nykyistä päivämäärää ja aikaa määritettäessä. Esimerkiksi päivityksessä, joka tapahtuu klo 20.00 Tyynenmeren aikaa (Yhdysvallat ja Kanada), kun aikavyöhyke on määritetty, määritetään nykyinen päivämäärä ja aika Tyynenmeren ajan mukaan, ei UTC-aikaan, joka palaa seuraavana päivänä.
Päivitystoiminnot, joita ei ole käynnistetty Power BI -palvelun kautta, kuten XMLA TMSL -päivityskomento, eivät ota huomioon aikavyöhykemääritystä ja oletuksena UTC.
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.
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 -palveluun, 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 -palveluun, 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 -editorin 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 RangeStart palvelu ohittaa sen automaattisesti kyselemään tietoja, RangeEnd 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.
Tietojen suodattaminen
Kun - ja RangeStart -RangeEndparametrit 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ä.
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.
Table
Valitse taulukko -luetteloruudun oletusarvo on taulukkonäkymässä valitsemasi taulukko. Ota lisäävä päivitys käyttöön taulukolle liukusäätimellä. Jos taulukon Power Query -lauseke ei sisällä -ja-parametreihin RangeStart perustuvaa RangeEnd 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, esimerkiksi barrelit päivässä öljy- ja kaasualalla, eivät ole mielekkäitä, kun on osittaiset päivät. 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 "Päivitys"-kohdan aikavyöhykettä ole määritetty sellaiselle, joka ei ole UTC-ajan alapuolella, palvelun päivitystoiminnot suoritetaan UTC-ajan mukaisesti, mikä voi määrittää voimassa olevan päivämäärä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:
- Jatka vain sarakkeen enimmäisarvoa 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 Tunnista tietojen muutokset - asetuksen käyttöönottoa voidaan parantaa edelleen. 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 enimmäiskokorajoituksia ottamalla käyttöön Suuren semanttisen mallin tallennusmuoto -asetuksen ennen ensimmäisen päivitystoiminnon suorittamista palvelussa. 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.
Päivitä
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:
- Power BI -yhteisö
- Hae "Power BI:n lisäävä päivitys" Bing
- Hae lisäävä päivitys tiedostoja Bing
- Hae "Säilytä olemassa olevat tiedot käyttämällä lisäävää päivitystä" Bing