Trinnvis oppdatering og sanntidsdata for semantiske modeller

Artikkel
11/10/2023

Trinnvis oppdatering utvider planlagte oppdateringsoperasjoner ved å tilby automatisert oppretting og administrasjon av semantiske modelltabeller som ofte laster inn nye og oppdaterte data. For de fleste modeller inneholder én eller flere tabeller transaksjonsdata som endres ofte og kan vokse eksponentielt, for eksempel en faktatabell i et relasjons- eller stjernedatabaseskjema. En trinnvis oppdateringspolicy for å partisjonere tabellen, oppdatere bare de nyeste importpartisjonene og eventuelt bruke en annen DirectQuery-partisjon for sanntidsdata, kan redusere mengden data som må oppdateres betydelig. Samtidig sikrer denne policyen at de siste endringene i datakilden er inkludert i spørringsresultatene.

Med trinnvis oppdatering og sanntidsdata:

Det kreves færre oppdateringssykluser for data som endrer seg raskt. DirectQuery-modus får de nyeste dataoppdateringene etter hvert som spørringer behandles, uten å kreve høy oppdateringsfrekvens.
Oppdateringer går raskere. Bare de nyeste dataene som er endret, må oppdateres.
Oppdateringer er mer pålitelige. Langvarige tilkoblinger til flyktige datakilder er ikke nødvendige. Spørringer til kildedata kjører raskere, noe som reduserer potensialet for nettverksproblemer å forstyrre.
Ressursforbruket reduseres. Mindre data å oppdatere reduserer det totale forbruket av minne og andre ressurser i både Power BI- og datakildesystemer.
Store semantiske modeller er aktivert. Semantiske modeller med potensielt milliarder rader kan vokse uten å måtte oppdatere hele modellen fullstendig med hver oppdateringsoperasjon.
Installasjonsprogrammet er enkelt. Policyer for trinnvis oppdatering defineres i Power BI Desktop med bare noen få oppgaver. Når Power BI Desktop publiserer rapporten, bruker tjenesten automatisk disse policyene for hver oppdatering.

Når du publiserer en Power BI Desktop-modell til tjenesten, har hver tabell i den nye modellen én enkelt partisjon. Den ene partisjonen inneholder alle radene for tabellen. Hvis tabellen er stor, for eksempel med titalls millioner rader eller mer, kan det ta lang tid å oppdatere tabellen og bruke mye ressurser.

Med trinnvis oppdatering partisjonerer tjenesten dynamisk og skiller data som må oppdateres ofte fra data som kan oppdateres sjeldnere. Tabelldata filtreres ved hjelp av Power Query-parametere for dato/klokkeslett med reserverte navn RangeStart som skiller mellom store og små bokstaver og RangeEnd. Når du konfigurerer trinnvis oppdatering i Power BI Desktop, brukes disse parameterne til å filtrere bare en liten periode med data som lastes inn i modellen. Når Power BI Desktop publiserer rapporten til Power Bi-tjeneste, oppretter tjenesten trinnvis oppdatering og historiske partisjoner med den første oppdateringsoperasjonen, og eventuelt en DirectQuery-partisjon i sanntid basert på policyinnstillingene for trinnvis oppdatering. Tjenesten overstyrer deretter parameterverdiene for å filtrere og spørre etter data for hver partisjon basert på dato-/klokkeslettverdier for hver rad.

Med hver etterfølgende oppdatering returnerer spørringsfiltrene bare de radene i oppdateringsperioden som er dynamisk definert av parameterne. Disse radene med en dato/klokkeslett i oppdateringsperioden oppdateres. Rader med en dato/klokkeslett som ikke lenger er innenfor oppdateringsperioden, blir deretter en del av den historiske perioden, som ikke oppdateres. Hvis en DirectQuery-partisjon i sanntid er inkludert i policyen for trinnvis oppdatering, oppdateres filteret også slik at det plukker opp eventuelle endringer som skjer etter oppdateringsperioden. Både oppdatering og historiske perioder rulles fremover. Etter hvert som nye partisjoner for trinnvis oppdatering opprettes, blir ikke oppdateringspartisjoner lenger i oppdateringsperioden historiske partisjoner. Over tid blir historiske partisjoner mindre detaljerte etter hvert som de slås sammen. Når en historisk partisjon ikke lenger er i den historiske perioden som er definert av policyen, fjernes den helt fra modellen. Denne virkemåten kalles et rullende vindusmønster.

Graphic representing a rolling window pattern.

Det fine med trinnvis oppdatering er at tjenesten håndterer alt for deg basert på policyene for trinnvis oppdatering du definerer. Prosessen og partisjonene som er opprettet fra den, er faktisk ikke synlige i tjenesten. I de fleste tilfeller er en veldefinert policy for trinnvis oppdatering alt som er nødvendig for å forbedre ytelsen for modelloppdatering betydelig. DirectQuery-partisjonen i sanntid støttes imidlertid bare for modeller i Premium-kapasiteter. Power BI Premium muliggjør også mer avanserte partisjons- og oppdateringsscenarioer gjennom XML-endepunktet (XMLA).

Forutsetninger

De neste delene beskriver støttede planer og datakilder.

Støttede planer

Trinnvis oppdatering støttes for Power BI Premium-, Premium per bruker-, Power BI Pro- og Power BI Embedded-modeller.

Å få de nyeste dataene i sanntid med DirectQuery støttes bare for Power BI Premium-, Premium per bruker- og Power BI Embedded-modeller.

Støttede datakilder

Trinnvis oppdatering og sanntidsdata fungerer best for strukturerte, relasjonelle datakilder som SQL Database og Azure Synapse, men kan også fungere for andre datakilder. I alle fall må datakilden støtte følgende:

Datofiltrering – Datakilden må støtte en mekanisme for å filtrere data etter dato. For en relasjonskilde er dette vanligvis en datokolonne med datatypen dato/klokkeslett eller heltall i måltabellen. Parameterne RangeStart og RangeEnd, som må være datatypen dato/klokkeslett, filtrerer tabelldata basert på datokolonnen. For datokolonner med surrogatnøkler for heltall i form av yyyymmdd, kan du opprette en funksjon som konverterer dato/klokkeslett-verdien i RangeStart- og RangeEnd-parameterne slik at de samsvarer med surrogatnøklene for heltallet i datokolonnen. Hvis du vil ha mer informasjon, kan du se Konfigurere trinnvis oppdatering – Konverter DateTime til heltall.

For andre datakilder må RangeStart- og RangeEnd-parameterne sendes til datakilden på en eller annen måte som aktiverer filtrering. For filbaserte datakilder der filer og mapper er organisert etter dato, kan RangeStart- og RangeEnd-parameterne brukes til å filtrere filene og mappene for å velge hvilke filer som skal lastes inn. For nettbaserte datakilder kan RangeStart- og RangeEnd-parameterne integreres i HTTP-forespørselen. Følgende spørring kan for eksempel brukes til trinnvis oppdatering av sporingene fra en AppInsights-forekomst:

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

Når trinnvis oppdatering er konfigurert, kjøres et Power Query-uttrykk som inneholder et dato/klokkeslett-filter basert på RangeStart- og RangeEnd-parameterne, mot datakilden. Hvis filteret er angitt i et spørringstrinn etter den første kildespørringen, er det viktig at spørringsdelegering kombinerer det første spørringstrinnet med trinnene som refererer til RangeStart- og RangeEnd-parameterne. For eksempel, i følgende spørringsuttrykkSql.Database, Table.SelectRows vil det brettes fordi det følger trinnet umiddelbart, og SQL Server støtter folding:

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"

Det finnes ingen krav til at den endelige spørringen støtter folding. I følgende uttrykk bruker vi for eksempel en ikke-foldet NativeQuery, men integrerer RangeStart- og RangeEnd-parameterne direkte i SQL:

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

Hvis policyen for trinnvis oppdatering imidlertid omfatter å hente sanntidsdata med DirectQuery, kan ikke transformasjoner som ikke er foldet, brukes. Hvis det er en ren importmoduspolicy uten sanntidsdata, kan spørringsflettingsmotoren kompensere og bruke filteret lokalt, noe som krever henting av alle rader for tabellen fra datakilden. Dette kan føre til at trinnvis oppdatering går tregt, og prosessen kan gå tom for ressurser enten i Power Bi-tjeneste eller i en lokal datagateway – som effektivt bekjemper formålet med trinnvis oppdatering.

Siden støtte for spørringsdelegering er forskjellig for ulike typer datakilder, bør bekreftelse utføres for å sikre at filterlogikken er inkludert i spørringene som kjøres mot datakilden. I de fleste tilfeller forsøker Power BI Desktop å utføre denne bekreftelsen for deg når du definerer policyen for trinnvis oppdatering. Denne bekreftelsen er pålitelig for SQL-baserte datakilder som SQL Database, Azure Synapse, Oracle og Teradata. Andre datakilder kan imidlertid ikke bekreftes uten å spore spørringene. Hvis Power BI Desktop ikke kan bekrefte spørringene, vises en advarsel i dialogboksen konfigurasjon av policy for trinnvis oppdatering.

Screenshot of the query folding warning

Hvis du ser denne advarselen og vil bekrefte at den nødvendige spørringsdelegeringen forekommer, kan du bruke funksjonen Power Query Diagnostics eller spore spørringer ved hjelp av et verktøy som støttes av datakilden, for eksempel SQL Profiler. Hvis spørringsdelegering ikke forekommer, må du kontrollere at filterlogikken er inkludert i spørringen som sendes til datakilden. Hvis ikke, er det sannsynlig at spørringen inneholder en transformasjon som hindrer folding.

Før du konfigurerer den trinnvise oppdateringsløsningen, må du lese og forstå veiledning for spørringsdelegering i Power BI Desktop og Power Query-spørringsdelegering. Disse artiklene kan hjelpe deg med å finne ut om datakilden og spørringene støtter spørringsdelegering.

Enkel datakilde

Når du konfigurerer trinnvis oppdatering og sanntidsdata ved hjelp av Power BI Desktop, eller konfigurerer en avansert løsning ved hjelp av TMSL (Tabular Model Scripting Language) eller Tabular Object Model (TOM) via XMLA-endepunktet, må alle partisjoner, enten import eller DirectQuery, spørre etter data fra én enkelt kilde.

Andre datakildetyper

Ved hjelp av mer egendefinerte spørringsfunksjoner og spørringslogikk kan trinnvis oppdatering brukes med andre typer datakilder hvis filtre er basert på RangeStart og RangeEnd kan sendes i én enkelt spørring, for eksempel med datakilder som Excel-arbeidsbokfiler som er lagret i en mappe, filer i SharePoint og RSS-feeder. Husk at dette er avanserte scenarioer som krever ytterligere tilpassing og testing utover det som er beskrevet her. Pass på å se fellesskapsdelen senere i denne artikkelen for forslag til hvordan du kan finne mer informasjon om hvordan du bruker trinnvis oppdatering for unike scenarier.

Tidsbegrensninger

Uavhengig av trinnvis oppdatering har Power BI Pro-modeller en tidsgrense for oppdatering på to timer og støtter ikke å få sanntidsdata med DirectQuery. For modeller i en Premium-kapasitet er tidsgrensen fem timer. Oppdateringsoperasjoner er prosess- og minneintensive. En full oppdateringsoperasjon kan bruke så mye som dobbelt så mye minne som kreves av modellen alene, fordi tjenesten opprettholder et øyeblikksbilde av modellen i minnet til oppdateringsoperasjonen er fullført. Oppdateringsoperasjoner kan også være prosessintensive og bruke en betydelig mengde tilgjengelige CPU-ressurser. Oppdateringsoperasjoner må også være avhengige av flyktige tilkoblinger til datakilder, og muligheten til disse datakildesystemene til raskt å returnere spørringsutdata. Tidsgrensen er en beskyttelse for å begrense overforbruk av tilgjengelige ressurser.

Merk

Med Premium-kapasiteter har oppdateringsoperasjoner utført gjennom XMLA-endepunktet ingen tidsbegrensning. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering med XMLA-endepunktet.

Fordi trinnvis oppdatering optimaliserer oppdateringsoperasjoner på partisjonsnivå i modellen, kan ressursforbruket reduseres betydelig. Samtidig, selv med trinnvis oppdatering, med mindre de går gjennom XMLA-endepunktet, er oppdateringsoperasjoner bundet av de samme to- og femtimersgrensene. En effektiv policy for trinnvis oppdatering reduserer ikke bare mengden data som behandles med en oppdateringsoperasjon, men reduserer også mengden unødvendige historiske data som er lagret i modellen.

Spørringer kan også begrenses av en standard tidsbegrensning for datakilden. De fleste relasjonelle datakilder tillater overordnede tidsbegrensninger i Power Query M-uttrykket. Uttrykket nedenfor bruker for eksempel SQL Server-datatilgangsfunksjonen til å angi CommandTimeout til 2 timer. Hver periode definert av policyintervallene sender inn en spørring som observerer innstillingen for tidsavbrudd for kommandoen:

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"

For svært store modeller i Premium-kapasiteter som sannsynligvis inneholder milliarder av rader, kan den første oppdateringsoperasjonen startes. Bootstrapping gjør det mulig for tjenesten å opprette tabell- og partisjonsobjekter for modellen, men laster ikke inn og behandler data i noen av partisjonene. Ved hjelp av SQL Server Management Studio kan du angi partisjoner som skal behandles individuelt, sekvensielt eller parallelt, for både å redusere mengden data som returneres i én enkelt spørring, og også omgå femtimerstidsgrensen. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – Forhindre tidsavbrudd ved første fullstendige oppdatering.

Gjeldende dato og klokkeslett

Gjeldende dato og klokkeslett er basert på systemdatoen på oppdateringstidspunktet. Hvis planlagt oppdatering er aktivert for modellen i tjenesten, tas den angitte tidssonen hensyn til når gjeldende dato og klokkeslett bestemmes. Både individuelle og planlagte oppdateringer gjennom tjenesten observerer tidssonen hvis tilgjengelig. En oppdatering som for eksempel skjer klokken 20:00 Stillehavskysten (USA og Canada) med en angitt tidssone, bestemmer gjeldende dato og klokkeslett basert på Stillehavskysten, ikke Coordinated Universal Time (UTC), som vil returnere neste dag. Oppdateringsoperasjoner som ikke startes gjennom Power Bi-tjeneste, for eksempel kommandoen TMSL-oppdatering, tar ikke hensyn til den planlagte tidssonen for oppdatering.

Screenshot of Scheduled refresh dialog showing the Time zone input field

Konfigurere trinnvis oppdatering og sanntidsdata

Denne delen beskriver viktige begreper for å konfigurere trinnvis oppdatering og sanntidsdata. Når du er klar for mer detaljerte trinnvise instruksjoner, kan du se Konfigurere trinnvis oppdatering og sanntidsdata for semantiske modeller.

Konfigurering av trinnvis oppdatering utføres i Power BI Desktop. For de fleste modeller kreves bare noen få oppgaver. Husk imidlertid følgende punkter:

Når du har publisert til Power Bi-tjeneste, kan du ikke publisere den samme modellen på nytt fra Power BI Desktop. Publisering på nytt fjerner eventuelle eksisterende partisjoner og data som allerede finnes i modellen. Hvis du publiserer til en Premium-kapasitet, kan etterfølgende metadataskjemaendringer gjøres med verktøy som ALM Toolkit med åpen kildekode, eller ved hjelp av TMSL. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – bare metadatadistribusjon.
Når du har publisert til Power Bi-tjeneste, kan du ikke laste ned modellen tilbake som en PBIX-fil til Power BI Desktop. Fordi modeller i tjenesten kan bli så store, er det upraktisk å laste ned og åpne dem på en vanlig stasjonær datamaskin.
Når du henter sanntidsdata med DirectQuery, kan du ikke publisere modellen til et arbeidsområde som ikke er Premium. Trinnvis oppdatering med sanntidsdata støttes bare med Power BI Premium.

Opprett parametere

Hvis du vil konfigurere trinnvis oppdatering i Power BI Desktop, må du først opprette to Power Query-dato-/klokkeslettparametere med reserverte navn RangeStart som skiller mellom store og små bokstaver og RangeEnd. Disse parameterne, som er definert i dialogboksen Behandle parametere i Power Query-redigering, brukes i utgangspunktet til å filtrere dataene som lastes inn i power BI Desktop-modelltabellen for å inkludere bare de radene med en dato/klokkeslett i denne perioden. RangeStart representerer den eldste eller tidligste datoen/klokkeslettet, og RangeEnd representerer den nyeste eller nyeste datoen/klokkeslettet. Når modellen er publisert til tjenesten, RangeStart og RangeEnd overstyres automatisk av tjenesten for å spørre etter data som er definert av oppdateringsperioden som er angitt i policyinnstillingene for trinnvis oppdatering.

Datakildetabellen FactInternetSales har for eksempel et gjennomsnitt på 10 000 nye rader per dag. Hvis du vil begrense antall rader som opprinnelig ble lastet inn i modellen i Power BI Desktop, angir du en periode på to dager mellom RangeStart og RangeEnd.

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

Filtrer data

Når og RangeStartRangeEnd parameterne er definert, bruker du egendefinerte datofiltre på tabellens datokolonne. Filtrene du bruker, velger et delsett med data som lastes inn i modellen når du velger Bruk.

Screenshot of column context menu with Custom Filter selected

Når vi har opprettet filtre basert på parameterne og brukt trinnene, lastes to dager med data (omtrent 20 000 rader) inn i modellen med et factInternetSales-eksempel.

Definer policy

Når filtre er brukt og et delsett med data er lastet inn i modellen, definerer du en policy for trinnvis oppdatering for tabellen. Når modellen er publisert til tjenesten, brukes policyen av tjenesten til å opprette og administrere tabellpartisjoner og utføre oppdateringsoperasjoner. Hvis du vil definere policyen, bruker du dialogboksen Trinnvis oppdatering og sanntidsdata til å angi både nødvendige og valgfrie innstillinger.

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

Table

Listeboksen Velg tabell er standard for tabellen du valgte i datavisning. Aktiver trinnvis oppdatering for tabellen med glidebryteren. Hvis Power Query-uttrykket for tabellen ikke inneholder et filter basert på RangeStart og RangeEnd parameterne, er ikke veksleknappen tilgjengelig.

Obligatoriske innstillinger

Innstillingen Arkivdata som starter før oppdateringsdato bestemmer den historiske perioden der rader med en dato/klokkeslett i denne perioden er inkludert i modellen, pluss rader for gjeldende ufullstendige historiske periode, pluss rader i oppdateringsperioden frem til gjeldende dato og klokkeslett.

Hvis du for eksempel angir fem år, lagrer tabellen de siste fem hele årene med historiske data i årspartisjoner. Tabellen inneholder også rader for gjeldende år i kvartals-, måneds- eller dagpartisjoner, opptil og inkludert oppdateringsperioden.

For modeller i Premium-kapasiteter kan tilbakedatert historiske partisjoner selektivt oppdateres med en detaljerthet som bestemmes av denne innstillingen. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – Partisjoner.

Innstillingen for trinnvis oppdatering av data som starter før oppdateringsdatoen , bestemmer den trinnvise oppdateringsperioden der alle rader med dato/klokkeslett i denne perioden er inkludert i oppdateringspartisjonene og oppdateres med hver oppdateringsoperasjon.

Hvis du for eksempel angir en oppdateringsperiode på tre dager, overstyrer RangeStart tjenesten og RangeEnd parameterne for å opprette en spørring for rader med en dato/klokkeslett innen en tredagersperiode, med begynnelsen og slutten avhengig av gjeldende dato og klokkeslett. Rader med dato/klokkeslett i de siste tre dagene frem til gjeldende operasjonstid for oppdatering oppdateres. Med denne policytypen kan du forvente at FactInternetSales-modelltabellen i tjenesten, som i gjennomsnitt er 10 000 nye rader per dag, oppdaterer omtrent 30 000 rader med hver oppdateringsoperasjon.

Angi en periode som bare inneholder minimum antall rader som kreves for å sikre nøyaktig rapportering. Når du definerer policyer for mer enn én tabell, må det samme RangeStart og RangeEnd parametere brukes selv om ulike lager- og oppdateringsperioder er definert for hver tabell.

Valgfrie innstillinger

Innstillingen Hent de nyeste dataene i sanntid med DirectQuery (bare Premium) muliggjør henting av de siste endringene fra den valgte tabellen i datakilden utover den trinnvise oppdateringsperioden ved hjelp av DirectQuery. Alle rader med en dato/klokkeslett senere enn den trinnvise oppdateringsperioden er inkludert i en DirectQuery-partisjon og hentes fra datakilden med hver modellspørring.

Hvis for eksempel denne innstillingen er aktivert, overstyrer RangeStart tjenesten fortsatt og RangeEnd parameterne for å opprette en spørring for rader med en dato/klokkeslett etter oppdateringsperioden, med begynnelsen avhengig av gjeldende dato og klokkeslett. Rader med en dato/klokkeslett etter gjeldende operasjonstidspunkt for oppdatering er også inkludert. Med denne policytypen inkluderer FactInternetSales-modelltabellen i tjenesten de nyeste dataoppdateringene.

Innstillingen Bare oppdater fullstendige dager sikrer at alle rader for hele dagen er inkludert i oppdateringsoperasjonen. Denne innstillingen er valgfri med mindre du aktiverer innstillingen Få de nyeste dataene i sanntid med innstillingen Bare DirectQuery (premium ). La oss for eksempel si at oppdateringen er planlagt å kjøre klokken 04:00 hver morgen. Hvis nye rader med data vises i datakildetabellen i løpet av disse fire timene mellom midnatt og 04:00, vil du ikke gjøre rede for dem. Noen forretningsmålinger som fat per dag i olje- og gassindustrien gir ingen mening med delvise dager. Et annet eksempel er oppdatering av data fra et finansielt system der data for forrige måned godkjennes på den tolvte kalenderdagen i måneden. Du kan angi oppdateringsperioden til én måned og planlegge at oppdateringen skal kjøre på den tolvte dagen i måneden. Når dette alternativet er valgt, oppdateres for eksempel januardata 12. februar.

Husk at med mindre planlagt oppdatering er konfigurert for en ikke-UTC-tidssone, oppdaterer du operasjoner i tjenesten under UTC-tid, som kan bestemme gjeldende dato og fullstendige perioder.

Innstillingen Identifiser dataendringer muliggjør enda mer selektiv oppdatering. Du kan velge en dato/klokkeslett-kolonne som brukes til å identifisere og oppdatere bare de dagene der dataene er endret. Denne innstillingen forutsetter at en slik kolonne finnes i datakilden, som vanligvis er for overvåkingsformål. Denne kolonnen skal ikke være den samme kolonnen som brukes til å partisjonere dataene med RangeStart og RangeEnd parameterne. Maksimumsverdien for denne kolonnen evalueres for hver av periodene i det trinnvise området. Hvis den ikke har endret seg siden forrige oppdatering, er det ikke nødvendig å oppdatere perioden, noe som potensielt kan redusere dagene trinnvist fra tre til én.

Gjeldende utforming krever at kolonnen for å oppdage dataendringer beholdes og bufres i minnet. Følgende teknikker kan brukes til å redusere kardinalitet og minneforbruk:

Bevar bare den maksimale verdien for kolonnen på oppdateringstidspunktet, kanskje ved hjelp av en Power Query-funksjon.
Reduser presisjonen til et akseptabelt nivå, gitt kravene til oppdateringsfrekvensen.
Definer en egendefinert spørring for å oppdage dataendringer ved hjelp av XMLA-endepunktet, og unngå å beholde kolonneverdien helt.

I noen tilfeller kan aktivering av alternativet Identifiser dataendringer* forbedres ytterligere. Du kan for eksempel unngå å beholde en siste oppdateringskolonne i minnehurtigbufferen, eller aktivere scenarioer der en konfigurasjons-/instruksjonstabell klargjøres ved å pakke ut innlastingsprosesser (ETL) for å flagge bare de partisjonene som må oppdateres. I slike tilfeller, for Premium-kapasiteter, kan du bruke TMSL og/eller TOM til å overstyre virkemåten for identifisering av dataendringer. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – Egendefinerte spørringer for å oppdage dataendringer.

Publiser

Når du har konfigurert policyen for trinnvis oppdatering, publiserer du modellen til tjenesten. Når publiseringen er fullført, kan du utføre den første oppdateringsoperasjonen på modellen.

Merk

Semantiske modeller med en policy for trinnvis oppdatering for å få de nyeste dataene i sanntid med DirectQuery, kan bare publiseres til et Premium-arbeidsområde.

For modeller som er publisert til arbeidsområder som er tilordnet Premium-kapasiteter, kan du forbedre ytelsen for oppdateringsoperasjoner hvis du tror modellen vil vokse utover 1 GB, og sikre at modellen ikke maksimalt er større størrelsesgrenser ved å aktivere Lagringsformat for stor modell før du utfører den første oppdateringsoperasjonen i tjenesten. Hvis du vil ha mer informasjon, kan du se Store modeller i Power BI Premium.

Viktig

Når Power BI Desktop publiserer modellen til tjenesten, kan du ikke laste ned PBIX-filen tilbake.

Refresh

Når du har publisert til tjenesten, utfører du en første oppdateringsoperasjon på modellen. Denne oppdateringen bør være en individuell (manuell) oppdatering, slik at du kan overvåke fremdriften. Den første oppdateringsoperasjonen kan ta litt tid å fullføre. Partisjoner må opprettes, historiske data lastes inn, objekter som relasjoner og hierarkier bygget eller gjenoppbygd, og beregnede objekter beregnes på nytt.

Etterfølgende oppdateringsoperasjoner, enten individuelle eller planlagte, er mye raskere fordi bare de trinnvise oppdateringspartisjonene oppdateres. Andre behandlingsoperasjoner må fremdeles forekomme, for eksempel sammenslåing av partisjoner og omberegning, men det tar vanligvis mye mindre tid enn den første oppdateringen.

Automatisk rapportoppdatering

For rapporter som bruker en modell med en policy for trinnvis oppdatering for å få de nyeste dataene i sanntid med DirectQuery, er det lurt å aktivere automatisk sideoppdatering med et fast intervall eller basert på endringsgjenkjenning, slik at rapportene inkluderer de nyeste dataene uten forsinkelse. Hvis du vil ha mer informasjon, kan du se Automatisk sideoppdatering i Power BI.

Avansert trinnvis oppdatering

Hvis modellen er på en Premium-kapasitet med et XMLA-endepunkt aktivert, kan trinnvis oppdatering utvides ytterligere for avanserte scenarier. Du kan for eksempel bruke SQL Server Management Studio til å vise og administrere partisjoner, starte den første oppdateringsoperasjonen eller oppdatere tilbakedatert historiske partisjoner. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering med XMLA-endepunktet.

Fellesskap

Power BI har et levende fellesskap der MVPer, BI-eksperter og kolleger deler ekspertise i diskusjonsgrupper, videoer, blogger og mer. Når du lærer om trinnvis oppdatering, kan du se disse ressursene: