Trinvis opdatering og data i realtid for datasæt

Trinvis opdatering udvider planlagte opdateringshandlinger ved at levere automatiseret partitionsoprettelse og -administration for datasættabeller, der ofte indlæser nye og opdaterede data. For de fleste datasæt er dette en eller flere tabeller, der indeholder transaktionsdata, der ændres ofte og kan vokse eksponentielt, f.eks. en faktatabel i et relations- eller stjernedatabaseskema. En politik for trinvis opdatering for at partitionere tabellen, kun opdatere den eller de nyeste importpartitioner og eventuelt bruge en ekstra DirectQuery-partition til data i realtid kan reducere den mængde data, der skal opdateres, betydeligt, samtidig med at det sikres, at selv de seneste ændringer i datakilden er inkluderet i forespørgselsresultaterne.

Med trinvis opdatering og data i realtid:

  • Færre opdateringscyklusser for hurtigt skiftende data – DirectQuery-tilstand henter de nyeste dataopdateringer, når forespørgsler behandles, uden at der kræves en høj opdateringsrytme.
  • Opdateringerne er hurtigere – Det er kun de nyeste data, der er blevet ændret, der skal opdateres.
  • Opdateringer er mere pålidelige – Langvarige forbindelser til flygtige datakilder er ikke nødvendige. Forespørgsler til kildedata kører hurtigere, hvilket reducerer risikoen for, at netværksproblemer forstyrres.
  • Ressourceforbruget reduceres – Hvis der skal opdateres færre data, reduceres det samlede forbrug af hukommelse og andre ressourcer i både Power BI- og datakildesystemer.
  • Muliggør store datasæt – Datasæt med potentielt milliarder af rækker kan vokse, uden at det er nødvendigt at opdatere hele datasættet fuldt ud med hver opdateringshandling.
  • Nem konfigurationPolitikker for trinvis opdatering er defineret i Power BI Desktop med blot nogle få opgaver. Når tjenesten er publiceret, anvender den automatisk disse politikker ved hver opdatering.

Når du publicerer en Power BI Desktop-model til tjenesten, har hver tabel i det nye datasæt en enkelt partition. Den enkelte partition indeholder alle rækker for den pågældende tabel. Hvis tabellen er stor, f.eks. med mange millioner rækker eller endnu mere, kan en opdatering af tabellen tage lang tid og forbruge en overdreven mængde ressourcer.

Med trinvis opdatering opdeler tjenesten dynamisk og adskiller data, der skal opdateres ofte, fra data, der kan opdateres mindre hyppigt. Tabeldata filtreres ved hjælp af parametre for dato/klokkeslæt i Power Query med de reserverede navne RangeStart og RangeEnd, hvor der skelnes mellem store og små bogstaver. Når du konfigurerer trinvis opdatering i Power BI Desktop, bruges parametrene kun til at filtrere en lille dataperiode, der skal indlæses i modellen. Når tjenesten publiceres til tjenesten med den første opdateringshandling, opretter den trinvise opdatering og historiske partitioner og eventuelt en DirectQuery-partition i realtid, der er baseret på politikindstillinger for trinvis opdatering, og tilsidesætter derefter parameterværdierne for at filtrere og forespørge data for hver partition baseret på dato-/klokkeslætsværdier for hver række.

Ved hver efterfølgende opdatering returnerer forespørgselsfiltrene kun de rækker i opdateringsperioden, der er dynamisk defineret af parametrene. Disse rækker med en dato/et klokkeslæt i opdateringsperioden opdateres. Rækker med en dato/et klokkeslæt, der ikke længere er inden for opdateringsperioden, bliver derefter en del af den historiske periode, som ikke opdateres. Hvis en DirectQuery-partition i realtid er inkluderet i politikken for trinvis opdatering, opdateres filteret også, så det registrerer eventuelle ændringer, der er opstået efter opdateringsperioden. Både opdaterings- og historiske perioder rulles fremad. Når der oprettes nye partitioner til trinvis opdatering, bliver opdateringspartitioner ikke længere i opdateringsperioden historiske partitioner. Med tiden bliver historiske partitioner mindre detaljerede, når de flettes sammen. Når en historisk partition ikke længere er i den historiske periode, der er defineret af politikken, fjernes den helt fra datasættet. Dette kaldes et rullende vinduesmønster.

Graphic representing a rolling window pattern.

Det gode ved trinvis opdatering er, at tjenesten håndterer alt dette for dig baseret på de politikker for trinvis opdatering, du definerer. Faktisk er processen og partitionerne, der er oprettet ud fra den, ikke engang synlige i tjenesten. I de fleste tilfælde er en veldefineret politik for trinvis opdatering alt, hvad der er nødvendigt for at forbedre ydeevnen for opdatering af datasæt markant. DirectQuery-partitionen i realtid understøttes dog kun for datasæt i Premium-kapaciteter. Power BI Premium muliggør også mere avancerede partitions- og opdateringsscenarier via XMLA-slutpunktet.

Krav

Understøttede planer

Trinvis opdatering understøttes for datasæt i Power BI Premium, Premium pr. bruger, Power BI Pro og Power BI Embedded.

Hentning af de nyeste data i realtid med DirectQuery understøttes kun for Power BI Premium-, Premium pr. bruger- og Power BI Embedded-datasæt.

Understøttede datakilder

Trinvis opdatering og data i realtid fungerer bedst til strukturerede relationsdatakilder, f.eks. SQL Database og Azure Synapse, men kan også fungere for andre datakilder. Under alle omstændigheder skal din datakilde understøtte følgende:

Datokolonne – Tabellen skal indeholde en datokolonne med datatypen dato/klokkeslæt eller heltal. Parametrene RangeStart og RangeEnd (som skal være datatypen dato/klokkeslæt) filtrerer tabeldata baseret på datokolonnen. For datokolonner med heltals surrogatnøgler i form af yyyymmddkan du oprette en funktion, der konverterer dato-/klokkeslætsværdien i parametrene RangeStart og RangeEnd, så de stemmer overens med heltals surrogatnøglerne for datokolonnen. Du kan få mere at vide under Konfigurer trinvis opdatering – Konvertér DateTime til heltal.

Forespørgselsdelegering – Trinvis opdatering er designet til datakilder, der understøtter forespørgselsdelegering, hvilket er Power Querys mulighed for at generere et enkelt forespørgselsudtryk for at hente og transformere kildedata, især hvis du henter de nyeste data i realtid med DirectQuery. De fleste datakilder, der understøtter SQL-forespørgsler, understøtter forespørgselsfoldning. Det gør datakilder som flade filer, blobs og nogle webfeeds ofte ikke.

Når trinvis opdatering er konfigureret, udføres et Power Query-udtryk, der indeholder et dato-/klokkeslætsfilter, der er baseret på parametrene RangeStart og RangeEnd, i forhold til datakilden. Filteret er i realiteten en transformation , der er inkluderet i forespørgslen, som definerer en WHERE-delsætning baseret på parametrene. I de tilfælde, hvor filteret ikke understøttes af datakilden, kan det ikke medtages i forespørgselsudtrykket. Hvis politikken for trinvis opdatering omfatter hentning af data i realtid med DirectQuery, kan transformationer, der ikke kan delees, ikke bruges. Hvis det er en ren importtilstandspolitik uden data i realtid, kan forespørgsels miksprogrammet kompensere og anvende filteret lokalt, hvilket kræver, at alle rækker til tabellen hentes fra datakilden. Dette kan medføre, at trinvis opdatering er langsom, og processen kan løbe tør for ressourcer enten i Power BI-tjenesten eller i en datagateway i det lokale miljø – hvilket effektivt kan besejre formålet med trinvis opdatering.

Da understøttelse af forespørgselsdelegering er forskellig for forskellige typer datakilder, skal der udføres kontrol for at sikre, at filterlogikken er inkluderet i de forespørgsler, der udføres i forhold til datakilden. I de fleste tilfælde forsøger Power BI Desktop at udføre denne bekræftelse for dig, når du definerer politikken for trinvis opdatering. Denne bekræftelse er pålidelig for SQL-baserede datakilder, f.eks. SQL Database, Azure Synapse, Oracle og Teradata. Andre datakilder kan dog ikke bekræfte uden at spore forespørgslerne. Hvis Power BI Desktop ikke kan bekræfte, vises der en advarsel i dialogboksen Konfiguration af politik for trinvis opdatering.

Query folding warning

Hvis du får vist denne advarsel og vil kontrollere, at den nødvendige forespørgselsdelegering finder sted, skal du bruge funktionen Power Query Diagnosticering eller spore forespørgsler ved hjælp af et værktøj, der understøttes af datakilden, f.eks. SQL Profiler. Hvis der ikke sker forespørgselsdelegering, skal du kontrollere, at filterlogikken er inkluderet i den forespørgsel, der overføres til datakilden. Hvis det ikke er muligt, indeholder forespørgslen sandsynligvis en transformation, der forhindrer foldning.

Før du konfigurerer din trinvise opdateringsløsning, skal du sørge for at læse og forstå vejledningen til forespørgselsdelegering grundigt i Power BI Desktop og Power Query-forespørgselsdelegering. Disse artikler kan hjælpe dig med at afgøre, om din datakilde og dine forespørgsler understøtter forespørgselsdelegering.

Enkelt datakilde

Når du konfigurerer trinvis opdatering og data i realtid ved hjælp af Power BI Desktop eller konfiguration af en avanceret løsning ved hjælp af TMSL (Tabular Model Scripting Language) eller TOM (Tabular Object Model) via XMLA-slutpunktet, skal alle partitioner , uanset om import eller DirectQuery forespørger data fra en enkelt kilde.

Andre datakildetyper

Ved hjælp af yderligere brugerdefinerede forespørgselsfunktioner og forespørgselslogik kan trinvis opdatering bruges sammen med andre typer datakilder, der indeholder filtre baseret på RangeStart og RangeEnd, som kan overføres i en enkelt forespørgsel. Excel-projektmappefiler, der er gemt i en mappe, filer i SharePoint eller RSS-kilder. Husk, at dette er avancerede scenarier, der kræver yderligere tilpasning og test ud over det, der er beskrevet her. Sørg for at se afsnittet Community senere i denne artikel for at få forslag til, hvordan du kan finde flere oplysninger om brug af trinvis opdatering til unikke scenarier som disse.

Tidsgrænser

Uanset trinvis opdatering har Power BI Pro-datasæt en grænse for opdateringstid på to timer og understøtter ikke hentning af data i realtid med DirectQuery. For datasæt i en Premium-kapacitet er tidsgrænsen fem timer. Opdateringshandlinger er proces- og hukommelseskrævende. En fuld opdateringshandling kan bruge lige så meget som det dobbelte af den mængde hukommelse, der kræves af datasættet alene, fordi tjenesten bevarer et øjebliksbillede af datasættet i hukommelsen, indtil opdateringshandlingen er fuldført. Opdateringshandlinger kan også være procestunge og forbruge en betydelig mængde tilgængelige CPU-ressourcer. Opdateringshandlinger skal også være afhængige af flygtige forbindelser til datakilder og disse datakildesystemers mulighed for hurtigt at returnere forespørgselsoutput. Tidsgrænsen er en sikkerhedsforanstaltning, der begrænser overforbruget af dine tilgængelige ressourcer.

Bemærk

Med Premium-kapaciteter har opdateringshandlinger, der udføres via XMLA-slutpunktet, ingen tidsgrænse. Du kan få mere at vide under Avanceret trinvis opdatering med XMLA-slutpunktet.

Da trinvis opdatering optimerer opdateringshandlinger på partitionsniveau i datasættet, kan ressourceforbruget reduceres væsentligt. Samtidig er opdateringshandlinger bundet af de samme grænser på to og fem timer, selv med trinvis opdatering, medmindre opdateringshandlinger via XMLA-slutpunktet er bundet af de samme grænser på to og fem timer. En effektiv politik for trinvis opdatering reducerer ikke kun mængden af data, der behandles med en opdateringshandling, men reducerer også mængden af unødvendige historiske data, der er gemt i dit datasæt.

Forespørgsler kan også begrænses af en standardtidsgrænse for datakilden. De fleste relationsdatakilder tillader tilsidesættelse af tidsgrænser i M-udtrykket i Power Query. Udtrykket nedenfor bruger f.eks. funktionen SQL Server-dataadgang til at angive CommandTimeout til 2 timer. Hver periode, der er defineret af politikintervallerne, sender en forespørgsel, der overholder indstillingen for timeout for kommandoer.

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 meget store datasæt i Premium-kapaciteter, der sandsynligvis vil indeholde milliarder af rækker, kan den indledende opdateringshandling startestrappet. Bootstrapping gør det muligt for tjenesten at oprette tabel- og partitionsobjekter for datasættet, men ikke indlæse og behandle data i nogen af partitionerne. Ved hjælp af SQL Server Management Studio kan partitioner derefter behandles individuelt, sekventielt eller parallelt, som begge kan reducere mængden af data, der returneres i en enkelt forespørgsel, men også omgå tidsgrænsen på fem timer. Du kan få mere at vide under Avanceret trinvis opdatering – Undgå timeout ved indledende fuld opdatering.

Dags dato og klokkeslæt

Den aktuelle dato og det aktuelle klokkeslæt er baseret på systemdatoen på tidspunktet for opdateringen. Hvis planlagt opdatering er aktiveret for datasættet i tjenesten, tages der højde for den angivne tidszone, når den aktuelle dato og det aktuelle klokkeslæt bestemmes. Både individuelle og planlagte opdateringer via tjenesten overvåger tidszonen, hvis den er tilgængelig. En opdatering, der forekommer kl. 20:00 Pacific Time (USA og Canada) med en angivet tidszone, bestemmer den aktuelle dato og det aktuelle klokkeslæt baseret på Pacific Time og ikke GMT (hvilket ellers ville være den næste dag). Opdateringshandlinger, der ikke er aktiveret via tjenesten, f.eks . TMSL-opdateringskommandoen, tager ikke højde for tidszonen for planlagt opdatering.

Time zone

Konfiguration af trinvis opdatering og data i realtid

Vi gennemgår vigtige begreber om konfiguration af trinvis opdatering og data i realtid her. Når du er klar til mere detaljerede trinvise instruktioner, skal du se Konfigurer trinvis opdatering og data i realtid for datasæt.

Konfiguration af trinvis opdatering udføres i Power BI Desktop. For de fleste modeller kræves der kun nogle få opgaver. Vær dog opmærksom på følgende:

  • Når du publicerer til tjenesten, kan du ikke publicere den samme model igen fra Power BI Desktop. Genpublicering vil fjerne alle eksisterende partitioner og data, der allerede findes i datasættet. Hvis du publicerer til en Premium-kapacitet, kan der foretages efterfølgende ændringer af metadataskemaet med værktøjer som ALM Toolkit med åben kildekode eller ved hjælp af TMSL (Tabular Model Scripting Language). Du kan få mere at vide under Avanceret trinvis opdatering – udrulning kun af metadata.
  • Når du publiceres til tjenesten, kan du ikke downloade datasættet tilbage som en PBIX til Power BI Desktop. Da datasæt i tjenesten kan blive så store, er det upraktisk at downloade tilbage og åbne på en typisk stationær computer.
  • Når du henter data i realtid med DirectQuery, kan du ikke publicere datasættet til et arbejdsområde, der ikke er Premium. Trinvis opdatering med data i realtid understøttes kun med Power BI Premium.

Opret parametre

Når du konfigurerer trinvis opdatering i Power BI Desktop, skal du først oprette to parametre for dato/klokkeslæt i Power Query med de reserverede navne RangeStart og RangeEnd, hvor der skelnes mellem store og små bogstaver. Disse parametre, der er defineret i dialogboksen Administrer parametre i Power Query-editor, bruges indledningsvist til at filtrere de data, der indlæses i Power BI Desktop-modeltabellen, så de kun indeholder de rækker, der har en dato/et klokkeslæt inden for den pågældende periode. Når modellen er publiceret til tjenesten, tilsidesættes RangeStart og RangeEnd automatisk af tjenesten for at forespørge om data, der er defineret af den opdateringsperiode, der er angivet i politikindstillingerne for trinvis opdatering.

Datakildetabellen FactInternetSales beregner f.eks. 10.000 nye rækker pr. dag. Hvis du vil begrænse antallet af rækker, der indledningsvist indlæses i modellen i Power BI Desktop, skal du angive en periode på to dage mellem RangeStart og RangeEnd.

Manage Parameters dialogue

Filtrer data

Når parametrene RangeStart og RangeEnd er defineret, anvender du derefter brugerdefinerede datofiltre på tabellens datokolonne. De filtre, du anvender, vælger et undersæt af data, der indlæses i modellen, når du klikker på Anvend.

Custom filter

Når du har oprettet filtre, der er baseret på parametrene og anvendt trin, indlæses to dages data i vores model ved hjælp af eksemplet FactInternetSales. Når du har oprettet filtre, indlæses der ca. 20.000 rækker i vores model.

Definer politik

Når der er anvendt filtre, og et undersæt af data er blevet indlæst i modellen, skal du derefter definere en trinvis opdateringspolitik for tabellen. Når modellen er publiceret til tjenesten, bruges politikken af tjenesten til at oprette og administrere tabelpartitioner og udføre opdateringshandlinger. Hvis du vil definere politikken, skal du bruge dialogboksen Trinvis opdatering og data i realtid til at angive både påkrævede indstillinger og valgfrie indstillinger.

Define policy dialog

Tabel

Listen Vælg tabel er som standard den tabel, du vælger i datavisning. Aktivér trinvis opdatering af tabellen med skyderen. Hvis power-forespørgselsudtrykket for tabellen ikke indeholder et filter, der er baseret på parametrene RangeStart og RangeEnd, er til/fra-knappen deaktiveret.

Påkrævede indstillinger

Indstillingen Arkivér data, der starter før opdateringsdato , bestemmer den historiske periode, hvor rækker med en dato/et klokkeslæt i den pågældende periode inkluderes i datasættet plus rækker for den aktuelle ufuldstændige historiske periode plus rækker i opdateringsperioden op til den aktuelle dato og det aktuelle klokkeslæt.

Hvis vi f.eks. angiver 5 år, gemmer tabellen de seneste fem hele år med historiske data i årspartitioner plus rækker for det aktuelle år i partitioner for kvartal, måned eller dag op til og med opdateringsperioden.

For datasæt i Premium-kapaciteter kan tilbagedaterede historiske partitioner selektivt opdateres med en granularitet, der bestemmes af denne indstilling. Du kan få mere at vide under Avanceret trinvis opdatering – Partitioner.

Indstillingen For trinvis opdatering af data, der starter før opdateringsdato , bestemmer den trinvise opdateringsperiode, hvor alle rækker med en dato/et klokkeslæt i den pågældende periode er inkluderet i opdateringspartitionerne og opdateres med hver opdateringshandling.

Hvis vi f.eks. angiver en opdateringsperiode på 3 dage, tilsidesætter tjenesten parametrene RangeStart og RangeEnd for at oprette en forespørgsel for rækker med en dato/et klokkeslæt inden for en periode på tre dage, der starter og slutter afhængigt af den aktuelle dato og det aktuelle klokkeslæt. Rækker med en dato/et klokkeslæt i de sidste 3 dage op til det aktuelle opdateringstidspunkt opdateres. Med denne type politik kan vi forvente, at vores tabel med FactInternetSales-datasæt i tjenesten, som i gennemsnit er 10.000 nye rækker pr. dag, vil opdatere omkring 30.000 rækker med hver opdateringshandling.

Sørg for at angive en periode, der kun indeholder det mindste antal rækker, der kræves for at sikre nøjagtig rapportering. Hvis du definerer politikker for mere end én tabel, skal de samme Parametre RangeStart og RangeEnd bruges, selvom der er defineret forskellige lager- og opdateringsperioder for hver tabel.

Valgfrie indstillinger

Indstillingen Hent de nyeste data i realtid med DirectQuery (kun Premium) gør det muligt at hente de seneste ændringer fra den valgte tabel i datakilden ud over den trinvise opdateringsperiode ved hjælp af DirectQuery. Alle rækker med en dato/et klokkeslæt senere end den trinvise opdateringsperiode medtages i en DirectQuery-partition og hentes fra datakilden med hver forespørgsel for datasæt.

Hvis den f.eks. er aktiveret, tilsidesætter tjenesten stadig parametrene RangeStart og RangeEnd for at oprette en forespørgsel for rækker med en dato/et klokkeslæt efter opdateringsperioden, der starter afhængigt af den aktuelle dato og det aktuelle klokkeslæt. Rækker med en dato/et klokkeslæt efter det aktuelle opdateringstidspunkt er inkluderet. Med denne type politik kan vi forvente, at vores tabel med FactInternetSales-datasæt i tjenesten inkluderer selv de nyeste dataopdateringer.

De seneste dage med kun opdatering sikrer, at alle rækker for hele dagen er inkluderet i opdateringshandlingen. Denne indstilling er valgfri , medmindre du aktiverer indstillingen Hent de nyeste data i realtid med DirectQuery (kun Premium). Lad os antage, at din opdatering er planlagt til at køre kl. 4:00 hver morgen. Hvis der vises nye rækker med data i datakildetabellen i løbet af disse fire timer mellem midnat og kl. 04:00, vil du ikke tage højde for dem. Nogle forretningsmålepunkter som tønder pr. dag i olie- og gasbranchen giver ingen mening med delvise dage. Et andet eksempel er opdatering af data fra et økonomisystem, hvor data for den foregående måned godkendes den 12. kalenderdag i måneden. Du kan angive opdateringsperioden til 1 måned og planlægge, at opdateringen skal køre den 12. dag i måneden. Når denne indstilling er valgt, opdateres data fra januar f.eks. den 12. februar.

Medmindre planlagt opdatering er konfigureret for en tidszone, der ikke er UTC-tidszone, skal du være opmærksom på, at opdateringshandlinger i tjenesten kører under UTC-tid, hvilket kan bestemme de hele perioder for ikrafttrædelsesdato og -virkning.

Indstillingen Registrer dataændringer muliggør endnu mere selektiv opdatering. Du kan vælge en dato-/klokkeslætskolonne, der bruges til kun at identificere og opdatere de dage, hvor dataene er blevet ændret. Dette forudsætter, at der findes en sådan kolonne i datakilden, som typisk er til overvågningsformål. Dette må ikke være den samme kolonne, der bruges til at partitionere dataene med parametrene RangeStart og RangeEnd. Maksimumværdien for denne kolonne evalueres for hver af perioderne i det trinvise interval. Hvis den ikke er ændret siden den seneste opdatering, er det ikke nødvendigt at opdatere perioden. I dette eksempel kan dette potentielt yderligere reducere de dage, der opdateres trinvist fra 3 til 1.

Det aktuelle design kræver, at kolonnen til registrering af dataændringer bevares og cachelagres i hukommelsen. Følgende teknikker kan bruges til at reducere kardinalitet og hukommelsesforbrug:

  • Bevar kun den maksimale værdi for kolonnen på opdateringstidspunktet, måske ved hjælp af en power-forespørgselsfunktion.
  • Reducer præcisionen til et acceptabelt niveau på grund af dine krav til opdateringshyppighed.
  • Definer en brugerdefineret forespørgsel til registrering af dataændringer ved hjælp af XMLA-slutpunktet, og undgå helt at bevare kolonneværdien.

I nogle tilfælde kan aktivering af indstillingen Registrer dataændringer forbedres yderligere. Det kan f.eks. være, at du vil undgå at bevare en kolonne med den seneste opdatering i cachen i hukommelsen eller aktivere scenarier, hvor en konfigurations-/instruktionstabel forberedes af ETL-processer til kun at markere de partitioner, der skal opdateres. I sådanne tilfælde skal du for Premium-kapaciteter bruge TMSL (Tabular Model Scripting Language) og/eller TOM (Tabular Object Model) til at tilsidesætte funktionsmåden for registrering af dataændringer. Du kan få mere at vide under Avanceret trinvis opdatering – Brugerdefinerede forespørgsler til registrering af dataændringer.

Publicer

Når du har konfigureret politikken for trinvis opdatering, publicerer du modellen til tjenesten. Når publiceringen er fuldført, kan du udføre den indledende opdateringshandling på datasættet.

Bemærk

Datasæt med en trinvis opdateringspolitik for at hente de nyeste data i realtid med DirectQuery kan kun publiceres til et Premium-arbejdsområde.

Hvis du mener, at datasættet vil vokse til mere end 1 GB for de datasæt, der er publiceret i arbejdsområder, der er tildelt til Premium-kapaciteter, kan du forbedre ydeevnen for opdateringshandlinger og sikre, at datasættet ikke overskrider størrelsesgrænserne ved at aktivere Lagerformat for store datasæt , før du udfører den første opdateringshandling i tjenesten. Du kan få mere at vide under Store datasæt i Power BI Premium.

Vigtigt

Når du har publiceret til tjenesten, kan du ikke downloade PBIX-filen igen.

Opdater

Efter publicering til tjenesten udfører du en indledende opdateringshandling på datasættet. Dette bør være en individuel (manuel) opdatering, så du kan overvåge status. Det kan tage et stykke tid at fuldføre den indledende opdateringshandling. Partitioner skal oprettes, historiske data indlæses, objekter som relationer og hierarkier bygges eller genopbygges, og beregnede objekter genberegnes.

Efterfølgende opdateringshandlinger, enten individuelle eller planlagte, er meget hurtigere, fordi det kun er partitionerne for trinvis opdatering, der opdateres. Der skal stadig udføres andre behandlingshandlinger, f.eks. fletning af partitioner og genberegning, men det tager normalt kun en lille brøkdel af tiden sammenlignet med den indledende opdatering.

Automatisk opdatering af rapport

For rapporter, der bruger et datasæt med en trinvis opdateringspolitik for at hente de nyeste data i realtid med DirectQuery, er det en god idé at aktivere automatisk sideopdatering med et fast interval eller baseret på registrering af ændringer, så rapporterne inkluderer de nyeste data uden forsinkelse. Du kan få mere at vide under Automatisk sideopdatering i Power BI.

Avanceret trinvis opdatering

Hvis dit datasæt er på en Premium-kapacitet, hvor XMLA-slutpunktet er aktiveret, kan trinvis opdatering udvides yderligere i forbindelse med avancerede scenarier. Du kan f.eks. bruge SQL Server Management Studio til at få vist og administrere partitioner, starte den indledende opdateringshandling eller opdatere tilbagedaterede historiske partitioner. Du kan få mere at vide under Avanceret trinvis opdatering med XMLA-slutpunktet.

Community

Power BI har et dynamisk community, hvor MVP'er, BI-fagfolk og peers deler ekspertise inden for diskussionsgrupper, videoer, blogs og meget mere. Når du lærer om trinvis opdatering, skal du se disse ekstra ressourcer:

Næste trin

Konfigurer trinvis opdatering for datasæt
Avanceret trinvis opdatering med XMLA-slutpunktet
Fejlfinding i forbindelse med trinvis opdatering
Trinvis opdatering for dataflow