Trinnvis oppdatering for datasett

Trinnvis oppdatering utvider planlagte oppdateringsoperasjoner ved å tilby automatisert oppretting av partisjoner og administrasjon av datasetttabeller som ofte laster inn nye og oppdaterte data. For de fleste datasett er dette én eller flere tabeller som inneholder transaksjonsdata som endres ofte og kan vokse eksponentielt, som en faktatabell i et relasjonelt eller stjernedatabaseskjema. Hvis du partisjonerer tabellen og oppdaterer bare de nyeste partisjonene, reduserer du betydelig hvor mye data som må oppdateres.

Med trinnvis oppdatering:

  • Oppdateringer er raskere – bare de nyeste dataene som har endrede behov, må oppdateres.
  • Oppdateringer er mer pålitelige – langvarige tilkoblinger til flyktige datakilder er ikke nødvendig. Spørringer til kildedata kjører raskere, og reduserer potensialet for at nettverksproblemer kan forstyrre.
  • Ressursforbruk reduseres – mindre data å oppdatere reduserer samlet forbruk av minne og andre ressurser i både Power BI og datakildesystemer.
  • Aktiverer store datasett – Datasett med potensielt milliarder med rader kan vokse uten å måtte oppdatere hele datasettet fullstendig med hver oppdateringsoperasjon.
  • Enkel oppsett – Policyer for trinnvis oppdatering er definert i Power BI Desktop med bare noen få oppgaver. Når den publiseres, bruker tjenesten automatisk disse policyene for hver oppdatering.

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

Med trinnvis oppdatering vil tjenesten dynamisk partisjonere og skille data som må oppdateres ofte fra data som kan oppdateres sjeldnere. Tabelldata filtreres ved hjelp av Power Query parametere for dato/klokkeslett med de reserverte navnene RangeStart og RangeEnd som skiller mellom små og store bokstaver. Når du opprinnelig konfigurerer trinnvis oppdatering i Power BI Desktop, brukes parameterne til å filtrere bare en liten periode med data som skal lastes inn i modellen. Når den publiseres til tjenesten, med den første oppdateringsoperasjonen, oppretter tjenesten trinnvis oppdatering og historiske partisjoner basert på policyinnstillinger for trinnvis oppdatering, og overstyrer deretter parameterverdiene for å filtrere og spørre etter data for hver partisjon basert på dato/klokkeslett-verdier for hver rad.

For hver etterfølgende oppdatering filtrerer og returnerer spørringen bare de radene i oppdateringsperioden, dynamisk definert av parameterne. Radene med dato/klokkeslett i oppdateringsperioden oppdateres. Rader med dato/klokkeslett som ikke lenger er innenfor oppdateringsperioden blir en del av den historiske perioden, som ikke oppdateres. Både oppdateringer og historiske perioder rulles fremover. Når det opprettes nye trinnvise oppdateringspartisjoner, blir oppdateringspartisjoner i oppdateringsperioden historiske partisjoner. Over tid blir historiske partisjoner mindre detaljerte når 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 datasettet. Dette er kjent som et mønster for rullende vindu.

Den vakre trinnvise oppdateringen er at tjenesten håndterer alt dette for deg basert på policyene for trinnvis oppdatering som du definerer. Prosessen og partisjoner som er opprettet fra den, er faktisk ikke engang synlige i tjenesten. I de fleste tilfeller er en veldefinert policy for trinnvis oppdatering alt som er nødvendig for å forbedre ytelsen til datasettets oppdatering betraktelig. For datasett i Premium kapasiteter støttes imidlertid mer avanserte partisjons- og oppdateringsscenarioer gjennom XMLA-endepunktet.

Krav

Støttede abonnementer

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

Støttede datakilder

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

Datokolonne – tabellen må inneholde en datokolonne av datatypen dato/klokkeslett eller heltall. RangeStart- og RangeEnd-parameterne (som må være datatype for dato/klokkeslett) filtertabelldata basert på datokolonnen. Når det gjelder datokolonner med heltall surrogatnøkler i form av , kan du opprette en funksjon som konverterer dato/klokkeslett-verdien i parameterne for å samsvare med yyyymmdd heltallsnøkkelen i datakildetabellen. Hvis du vil ha mer informasjon, kan du se Konfigurer trinnvis oppdatering – Konverter DateTime til heltall.

Spørringsde folding – trinnvis oppdatering er utformet for datakilder som støtter spørringsfolding, som er Power Query mulighet til å generere et enkelt spørringsuttrykk for å hente og transformere kildedata. De fleste datakilder som støtter SQL-spørringer, støtter spørringsfolding. Datakilder som flate filer, blotter og noen nettfeeder gjør det ofte ikke.

Når trinnvis oppdatering er konfigurert, utføres et Power Query dato/klokkeslett-uttrykk som inneholder et dato/klokkeslett-filter basert på RangeStart- og RangeEnd-parameterne, mot datakilden. Filteret er i kraft en transformasjon som er inkludert i spørringen som definerer en WHERE-setning basert på parameterne. I tilfeller der filteret ikke støttes av datakilden, kan det ikke inkluderes i spørringsuttrykket. Nettflettingsmotoren for spørringen kompenserer og bruker filteret lokalt, noe som krever at du henter alle radene i tabellen fra datakilden. Dette kan føre til at trinnvis oppdatering tar lang tid, og prosessen kan gå tom for ressurser i Power BI-tjenesten eller i en lokal datagateway . Dette kan effektivt redusere formålet med trinnvis oppdatering.

Fordi støtte for spørringsfolding er forskjellig for ulike typer datakilder, bør du utføre verifisering for å sikre at filterlogikken er inkludert i spørringene som utføres mot datakilden. I de fleste tilfeller Power BI Desktop å utføre denne verifiseringen for deg når du definerer policyen for trinnvis oppdatering. Denne SQL pålitelig for SQL datakilder som SQL Database, Azure Synapse, Oracle og Teradata. Det kan imidlertid hende at det ikke er mulig å verifisere andre datakilder uten sporing av spørringene. Hvis Power BI Desktop ikke kan bekrefte, vises en advarsel i dialogboksen Konfigurasjon av trinnvis oppdateringspolicy.

Advarsel om spørringsde folding

Hvis du ser denne advarselen og vil bekrefte at den nødvendige spørringsde foldingen forekommer, kan du bruke funksjonen Power Query-diagnostikk eller spore spørringer ved hjelp av et verktøy som støttes av datakilden, for eksempel SQL Profiler. Hvis spørringsde folding ikke skjer, 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 forhindrer folding.

Før du konfigurerer løsningen for trinnvis oppdatering, må du lese og forstå veiledningen for spørringsdelegging grundig Power BI Desktop og Power Query spørringsde folding. Disse artiklene kan hjelpe deg med å finne ut om datakilden og spørringene støtter spørringsdelegging.

Andre datakildetyper

Ved å bruke flere egendefinerte spørringsfunksjoner og spørringslogikk kan trinnvis oppdatering brukes med andre typer datakilder som gir filtre basert på RangeStart og RangeEnd, kan sendes i én enkelt spørring. Arbeidsbokfiler som er Excel i en mappe, filer i SharePoint eller RSS-feeder. Husk at dette er avanserte scenarioer som krever ekstra tilpassing og testing utover det som er beskrevet her. Husk å se fellesskapsdelen senere i denne artikkelen for forslag til hvordan du finner mer informasjon om hvordan du bruker trinnvis oppdatering for unike scenarioer som disse.

Tidsbegrensninger

Uavhengig av trinnvis oppdatering har Power BI Pro et tidsgrense for oppdatering på to timer. For datasett i en Premium kapasitet er tidsgrensen på fem timer. Oppdateringsoperasjoner krever mye prosess og minne. En fullstendig oppdateringsoperasjon kan bruke så mye som dobbelt så mye minne som kreves av datasettet, fordi tjenesten opprettholder et øyeblikksbilde av datasettet i minnet til oppdateringsoperasjonen er fullført. Oppdateringsoperasjoner kan også være prosessintensive og bruke en betydelig mengde tilgjengelige PROSESSORressurser. Oppdateringsoperasjoner må også være avhengige av flyktige tilkoblinger til datakilder, og muligheten til disse datakildesystemene til raskt å returnere spørringsutdata. Tidsgrensen er et beskyttelse for å begrense overforbruk av de tilgjengelige ressursene dine.

Obs!

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

Fordi trinnvis oppdatering optimaliserer oppdateringsoperasjoner på partisjonsnivå i datasettet, kan ressursforbruket reduseres betraktelig. Samtidig, selv med trinnvis oppdatering, med mindre gjennom XMLA-endepunktet, er oppdateringsoperasjoner bundet av de samme to og fem timers grensene. 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 datasettet.

Spørringer kan også begrenses av en standard tidsgrense for datakilden. De fleste relasjonelle datakilder tillater overstyringstidsgrense i Power Query M-uttrykket. Uttrykket nedenfor bruker for eksempel følgende SQL Server-tilgangsfunksjonen for å angi CommandTimeout til 2 timer. Hver periode definert av retningslinjeområdene sender inn et spørsmål som observerer innstillingen for kommandotidsavbrudd.

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 datasett i Premium som sannsynligvis vil inneholde milliarder av rader, kan den første oppdateringsoperasjonen startes. Oppstart gjør det mulig for tjenesten å opprette tabeller og partisjonsobjekter for datasettet, men ikke laste inn og behandle data til noen av partisjonene. Ved hjelp SQL Server Management Studio kan partisjoner deretter behandles individuelt, sekvensielt, eller parallelt, som både kan redusere mengden data som returneres i én enkelt spørring, men også omgå tidsgrensen på fem timer. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – Forhindre tidsavbrudd ved første fullstendig oppdatering.

Gjeldende dato og klokkeslett

Gjeldende dato og klokkeslett er basert på systemdatoen da oppdateringen ble oppdatert. Hvis planlagt oppdatering er aktivert for datasettet i tjenesten, tas den angitte tidssonen med i betraktning når gjeldende dato og klokkeslett skal fastsettes. Både individuelle og planlagte oppdateringer gjennom tjenesten observerer tidssonen hvis tilgjengelig. En oppdatering som inntreffer for eksempel 08:00 PM Pacific Time (USA og Canada) med en angitt tidssone, bestemmer gjeldende dato og klokkeslett basert på Pacific Time, ikke GMT (som ellers ville være neste dag). Oppdateringsoperasjoner som ikke er aktivert gjennom tjenesten, som oppdateringskommandoen TMSL,vil ikke vurdere den planlagte oppdateringen av tidssonen.

Tidssone

Konfigurer trinnvis oppdatering

Vi skal gå gjennom viktige konsepter for konfigurering av trinnvis oppdatering her. Når du er klar for mer detaljerte trinnvise instruksjoner, må du se Konfigurere trinnvis oppdatering for datasett.

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

  • Når du publiserer til tjenesten, kan du ikke publisere den samme modellen på nytt fra Power BI Desktop. Publisering vil fjerne eksisterende partisjoner og data som allerede finnes i datasettet, ved å publisere på nytt. Hvis du publiserer til en Premium kapasitet, kan etterfølgende metadataskjemaendringer gjøres med ALM Toolkit med åpen kildekode eller ved å bruke Skriptspråk for tabellmodell (TMSL). Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – distribusjon av metadata.
  • Når det publiseres til tjenesten, kan du ikke laste ned datasettet tilbake som en PBIX for å Power BI Desktop. Fordi datasett i tjenesten kan vokse seg så store, er det upraktisk å laste ned tilbake og åpne på en vanlig stasjonær datamaskin.

Opprett parametere

Når du konfigurerer trinnvis oppdatering i Power BI Desktop, oppretter du først to parametere Power Query dato/klokkeslett med de reserverte navnene RangeStart og RangeEnd som skiller mellom små og store bokstaver. Disse parameterne, som er definert i dialogboksen Administrer parametere i Power Query-redigering, brukes først til å filtrere data som er lastet inn i Power BI Desktop-modelltabellen, for å inkludere bare de radene med en dato/klokkeslett i den perioden. Etter at modellen er publisert til tjenesten, overstyres RangeStart og RangeEnd automatisk av tjenesten for å spørre etter data som er definert av oppdateringsperioden som er angitt i innstillingene for trinnvis oppdatering- policy.

Eksempel: Datakildetabellen FactInternetSales har en gjennomsnittstabell på 10 000 nye rader per dag. For å begrense antall rader som først lastes inn i modellen i Power BI Desktop, angir vi en todagers periode mellom RangeStart og RangeEnd.

Administrer parametere-dialog

Å filtrere data

Når rangeStart- og RangeEnd-parametere er definert, kan du bruke egendefinerte datofiltre på tabellens datokolonne. Filtrene du bruker, velger et delsett av dataene som lastes inn i modellen når du klikker på Bruk.

Egendefinert filter

Ved hjelp av FactInternetSales-eksemplet, lastes omtrent 20 000 rader inn i modellen vår etter å ha opprettet filtre basert på parameterne og tatt i bruk trinnene.

Definer policy

Når filtre er tatt i bruk og et delsett med data er lastet inn i modellen, definerer du en trinnvis oppdateringspolicy for tabellen. Når modellen er publisert til tjenesten, brukes policyen av tjenesten til å opprette og administrere tabellpartisjoner og utføre oppdateringsoperasjoner.

Det finnes tre nødvendige innstillinger og to valgfrie innstillinger for å definere policyen:

Dialogboksen Definer policy

1 – Tabell

Tabelllisteboksen bruker tabellen du velger i Datavisning som standard. Aktiver trinnvis oppdatering for tabellen med glidebryteren. Hvis standarduttrykket Power Query for tabellen ikke inneholder et filter basert på RangeStart- og RangeEnd-parameterne, deaktiveres vippebryteren.

2 – Store rader fra de siste

Denne obligatoriske innstillingen bestemmer den historiske perioden der rader med en dato/klokkeslett i den perioden inkluderes i datasettet, pluss rader for den gjeldende ufullstendige historiske perioden, pluss rader i oppdateringsperioden opptil gjeldende dato og klokkeslett.

Hvis vi for eksempel angir fem år , vil tabellen lagre de siste fem hele årene med historiske data i årpartisjoner, pluss rader for gjeldende år i kvartalet, måneden eller dagen med partisjoner, opptil og inkludert oppdateringsperioden.

Når det gjelder datasett Premium kapasiteter, kan tilbakedaterte historiske partisjoner selektivt oppdateres selektivt med en tetthet som bestemmes av denne innstillingen. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – Partisjoner.

3 – oppdater radene fra de siste

Denne obligatoriske innstillingen bestemmer den trinnvise oppdateringsperioden der alle rader med dato/klokkeslett i den perioden er inkludert i oppdateringspartisjoner og oppdateres med hver oppdateringsoperasjon.

Hvis vi for eksempel angir en oppdateringsperiode på 10 dager, overstyrer tjenesten RangeStart- og RangeEnd-parameterne for å opprette en spørring for rader med en dato/klokkeslett i løpet av en tidagers periode, start og slutt avhengig av gjeldende dato og klokkeslett. Rader med et dato/klokkeslett i løpet av de siste 10 dagene opptil gjeldende tidspunkt for oppdateringsoperasjonen, oppdateres. Med denne typen policy kan vi forvente at vår FactInternetSales-datasetttabell i tjenesten, som gir gjennomsnitt 10 000 nye rader per dag, vil oppdatere omtrent 100 000 rader med hver oppdateringsoperasjon.

Husk å angi en periode som bare inkluderer minimum antall rader som kreves for å sikre nøyaktig rapportering. Hvis du definerer policyer for mer enn én tabell, må samme RangeStart- og RangeEnd-parametere brukes selv om forskjellige lagrings- og oppdateringsperioder er definert for hver tabell.

4 – oppdag dataendringer

Denne innstillingen er valgfri. Trinnvis oppdatering av 10 dager er mer effektivt enn en full oppdatering av fem år. Oppdatering kan imidlertid være enda mer selektiv. Med alternativet Oppdag dataendringer kan du velge en dato-/klokkeslettkolonne brukt til å identifisere og oppdatere bare de dagene hvor dataene er endret. Dette forutsetter at en slik kolonne eksisterer i datakilden, som typisk er for revisjonsformål. Dette kan ikke være den samme kolonnen som brukes til å dele dataene med RangeStart- og RangeEnd-parametere. Den maksimale verdien til denne kolonnen evalueres for hver av periodene i det trinnvise området. Hvis det ikke er endret siden siste oppdatering, er det ikke nødvendig å oppdatere perioden. I dette eksemplet kan dette potensielt ytterligere redusere dager som blir trinnvist oppdatert, fra 10 til rundt to.

Den nåværende designen krever at kolonnen for å oppdage dataendringer bufres i minne. Følgende teknikker kan brukes til å redusere kardinalitet og minneforbruk:

  • Vedvar kun maksimumsverdien for kolonnen på oppdateringstid tidspunktet for oppdatering, kanskje ved å bruke en Power Query funksjon.
  • Reduser presisjonen til et akseptabelt nivå, gitt dine krav til oppdateringsfrekvens.
  • Definer en egendefinert spørring for å oppdage dataendringer ved hjelp av XMLA-endepunktet, og unngå å vedvare kolonneverdien helt.

I noen tilfeller kan aktivering av Oppdag dataendringer-alternativet forbedres ytterligere. Du vil for eksempel unngå å vedvare en kolonne for siste oppdatering i hurtigbufferen i minnet, eller aktivere scenarioer der en konfigurasjons-/instruksjonstabell klargjøres av ETL-prosesser for å flagge bare de partisjonene som må oppdateres. I slike tilfeller bruker Premium Tabulær modellskriptingsspråk (TMSL) og/eller Tabular Object Model (TOM) for å overstyre virkemåten for oppdag dataendringer. Hvis du vil ha mer informasjon, kan du se Avansert trinnvis oppdatering – egendefinerte spørringer for å oppdage dataendringer.

5 – oppdater bare fullførte dager

Denne innstillingen er valgfri. La oss si at oppdateringen din er planlagt å kjøre 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 kanskje ikke ønske å ta dem med i betraktningen. Enkelte forretningsmåledata, som tønner per dag i olje- og gassindustrien, gir ikke mening med deldager. Et annet eksempel er oppdatering av data fra et økonomisk system hvor data for forrige måned er godkjent den 12. kalenderdagen i måneden. Du kan angi oppdateringsperioden til 1 måned og planlegge at oppdateringen skal kjøre den 12. dagen av måneden. Med dette alternativet valgt vil det for eksempel oppdatere januar-data 12. februar.

Vær oppmerksom på at med mindre planlagt oppdatering er konfigurert for en ikke-UTC-tidssone, kan oppdateringsoperasjoner i tjenesten kjøres under UTC-tid, som kan fastslå den effektive datoen og effektens hele perioder.

Publiser

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

Hvis du tror datasettet vil øke utover 1 GB eller mer, kan du forbedre ytelsen til oppdateringsoperasjonen og sikre at datasettet ikke maksimale størrelsesgrenser for store datasett blir større enn 1 GB eller mer, før du utfører den første oppdatering Premium soperasjonen i tjenesten. Hvis du vil ha mer informasjon, kan du se Store Power BI Premium.

Viktig!

Når du har blitt publisert til tjenesten, kan du ikke laste ned PBIX-filen tilbake.

Oppdater

Når du har publisert til tjenesten, kan du utføre en første oppdateringsoperasjon på datasettet. Dette bør være en individuell (manuell) oppdatering, slik at du kan overvåke fremdriften. Det kan ta ganske lang tid å fullføre den første oppdateringsoperasjonen. Partisjoner må opprettes, historiske data lastes inn, objekter som relasjoner og hierarkier bygges eller bygges på nytt, og beregnede objekter beregnes på nytt.

Etterfølgende oppdateringsoperasjoner, enten individuelle eller planlagte, er mye raskere, fordi bare de trinnvise oppdateringspartisjon(ene) oppdateres. Andre behandlingsoperasjoner må fremdeles forekomme, for eksempel fletting av partisjoner og ny beregning, men det tar vanligvis bare en brøkdel av tiden sammenlignet med den første oppdateringen.

Avansert trinnvis oppdatering

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

Fellesskap

Power BI har et levende fellesskap hvor MVP-er, BI-profesjonelle og likesinnede deler ekspertise innen diskusjonsgrupper, videoer, blogger og mer. Når du lærer om trinnvis oppdatering, må du sjekke ut disse ekstra ressursene:

Neste trinn

Konfigurer trinnvis oppdatering for datasett
Avansert trinnvis oppdatering med XMLA-endepunktet
Feilsøk trinnvis oppdatering
Trinnvis oppdatering for dataflyter