Trinvis opdatering og data i realtid for semantiske modeller

Trinvis opdatering udvider planlagte opdateringshandlinger ved at levere automatisk oprettelse og administration af partitioner for semantiske modeltabeller, der ofte indlæser nye og opdaterede data. For de fleste modeller indeholder en eller flere tabeller transaktionsdata, der ændres ofte og kan vokse eksponentielt, f.eks. en faktatabel i et relations- eller stjernedatabaseskema. En politik for trinvis opdatering til partitionering af tabellen, opdatering af de nyeste importpartitioner og eventuelt brug af en anden DirectQuery-partition til data i realtid kan reducere den mængde data, der skal opdateres, markant. Samtidig sikrer denne politik, at de seneste ændringer i datakilden er inkluderet i forespørgselsresultaterne.

Med trinvis opdatering og data i realtid:

  • Der er brug for færre opdateringscyklusser for data, der ændrer sig hurtigt. DirectQuery-tilstand henter de nyeste dataopdateringer, når forespørgsler behandles, uden at det kræver 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 netværksproblemer.
  • Ressourceforbruget reduceres. Færre data, der skal opdateres, reducerer det samlede forbrug af hukommelse og andre ressourcer i både Power BI- og datakildesystemer.
  • Store semantiske modeller er aktiveret. Semantiske modeller med potentielt milliarder af rækker kan vokse, uden at det er nødvendigt at opdatere hele modellen fuldt ud med hver opdateringshandling.
  • Det er nemt at konfigurere. Politikker for trinvis opdatering er defineret i Power BI Desktop med blot nogle få opgaver. Når Power BI Desktop publicerer rapporten, anvender tjenesten automatisk disse politikker for hver opdatering.

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

Med trinvis opdatering partitioneres og adskilles data, der skal opdateres ofte, dynamisk fra data, der kan opdateres sjældnere. Tabeldata filtreres ved hjælp af parametre for dato/klokkeslæt i Power Query med de reserverede navne med forskel på store og små bogstaver RangeStart og RangeEnd. Når du konfigurerer trinvis opdatering i Power BI Desktop, bruges disse parametre kun til at filtrere en lille periode med data, der indlæses i modellen. Når Power BI Desktop publicerer rapporten på Power BI-tjeneste, opretter tjenesten med den første opdateringshandling trinvis opdatering og historiske partitioner og eventuelt en DirectQuery-partition i realtid baseret på politikindstillingerne for trinvis opdatering. Tjenesten tilsidesætter derefter parameterværdierne for at filtrere og forespørge om 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 inden for 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 sker efter opdateringsperioden. Både opdateringsperioderne og de historiske perioder rulles fremad. Når der oprettes nye trinvise opdateringspartitioner, bliver opdateringspartitioner, der ikke længere er i opdateringsperioden, historiske partitioner. Med tiden bliver historiske partitioner mindre detaljerede, efterhånden som 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 modellen. Denne funktionsmåde kaldes et rullende vinduesmønster.

Graphic representing a rolling window pattern.

Skønheden ved trinvis opdatering er, at tjenesten håndterer det hele for dig baseret på de politikker for trinvis opdatering, du definerer. Faktisk er den proces og de partitioner, der er oprettet ud fra den, ikke 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 modelopdatering betydeligt. DirectQuery-partitionen i realtid understøttes dog kun for modeller i Premium-kapaciteter. Power BI Premium muliggør også mere avancerede partitions- og opdateringsscenarier via XML for Analysis-slutpunktet (XMLA).

Krav

I de næste afsnit beskrives de understøttede planer og datakilder.

Understøttede planer

Trinvis opdatering understøttes for Power BI Premium-, Premium pr. bruger-, Power BI Pro- og Power BI Embedded-modeller.

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

Understøttede datakilder

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

Datofiltrering – Datakilden skal understøtte en mekanisme til filtrering af data efter dato. For en relationel kilde er dette typisk en datokolonne med datatypen dato/klokkeslæt eller heltal i måltabellen. 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 svarer til datokolonnens heltals surrogatnøgler. Du kan få mere at vide under Konfigurer trinvis opdatering – Konvertér DateTime til heltal.

For andre datakilder skal parametrene RangeStart og RangeEnd overføres til datakilden på en måde, der muliggør filtrering. For filbaserede datakilder, hvor filer og mapper er organiseret efter dato, kan parametrene RangeStart og RangeEnd bruges til at filtrere filerne og mapperne for at vælge, hvilke filer der skal indlæses. For webbaserede datakilder kan parametrene RangeStart og RangeEnd integreres i HTTP-anmodningen. Følgende forespørgsel kan f.eks. bruges til trinvis opdatering af sporingerne 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 trinvis opdatering er konfigureret, udføres et Power Query-udtryk, der indeholder et dato-/klokkeslætsfilter baseret på parametrene RangeStart og RangeEnd, i forhold til datakilden. Hvis filteret er angivet i et forespørgselstrin efter den indledende kildeforespørgsel, er det vigtigt, at forespørgselsdelegering kombinerer det indledende forespørgselstrin med trinnene, der refererer til parametrene RangeStart og RangeEnd. I følgende forespørgselsudtryk kan du f.eks. folde , Table.SelectRows fordi den følger Sql.Database trinnet med det samme, og SQL Server understøtter foldning:

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"

Der er ikke noget krav om, at den endelige forespørgsel understøtter foldning. I følgende udtryk bruger vi f.eks. en ikke-foldbar NativeQuery, men integrerer parametrene RangeStart og RangeEnd 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

Men hvis politikken for trinvis opdatering omfatter hentning af data i realtid med DirectQuery, kan ikke-foldbare transformationer ikke bruges. Hvis det er en ren importtilstandspolitik uden data i realtid, kan forespørgselsmaksprogrammet kompensere og anvende filteret lokalt, hvilket kræver hentning af alle rækker til tabellen fra datakilden. Dette kan medføre, at trinvis opdatering er langsom, og processen kan løbe tør for ressourcer enten i Power BI-tjeneste 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 køres mod 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æftes uden at spore forespørgslerne. Hvis Power BI Desktop ikke kan bekræfte forespørgslerne, vises der en advarsel i dialogboksen Konfiguration af trinvis opdateringspolitik.

Screenshot of the 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 ikke, 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 konfigurerer 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 det er import eller DirectQuery, forespørge om data fra en enkelt kilde.

Andre datakildetyper

Ved hjælp af flere brugerdefinerede forespørgselsfunktioner og forespørgselslogik kan trinvis opdatering bruges sammen med andre typer datakilder, hvis filtre er baseret på RangeStart og RangeEnd kan overføres i en enkelt forespørgsel, f.eks. med datakilder, f.eks. Excel-projektmappefiler, der er gemt i en mappe, filer i SharePoint og RSS-kilder. Vær opmærksom på, 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.

Tidsgrænser

Uanset trinvis opdatering har Power BI Pro-modeller en opdateringstidsgrænse på to timer og understøtter ikke hentning af data i realtid med DirectQuery. For modeller 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 modellen alene, fordi tjenesten bevarer et snapshot af modellen 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 muligheden for, at disse datakildesystemer hurtigt kan returnere forespørgselsoutput. Tidsgrænsen er en sikkerhedsforanstaltning for at begrænse overforbrug 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 modellen, kan ressourceforbruget reduceres betydeligt. Samtidig er opdateringshandlinger bundet af de samme grænser på to timer og fem timer, selv med trinvis opdatering, medmindre de gennemgår XMLA-slutpunktet. 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 din model.

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. sql Server-dataadgangsfunktionen til at angive CommandTimeout til 2 timer. Hver periode, der er defineret af politikområderne, sender en forespørgsel, der overholder indstillingen for kommandotimeout:

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 modeller i Premium-kapaciteter, der sandsynligvis indeholder milliarder af rækker, kan den indledende opdateringshandling være boottrapped. Bootstrapping gør det muligt for tjenesten at oprette tabel- og partitionsobjekter for modellen, men indlæser og behandler ikke data i nogen af partitionerne. Ved hjælp af SQL Server Management Studio kan du angive partitioner, der skal behandles individuelt, sekventielt eller parallelt, for både at reducere mængden af data, der returneres i en enkelt forespørgsel, og også tilsidesætte tidsgrænsen på fem timer. Du kan få mere at vide under Avanceret trinvis opdatering – Undgå timeout ved indledende fuld opdatering.

Aktuel dato og klokkeslæt

Den aktuelle dato og det aktuelle klokkeslæt er baseret på systemdatoen på opdateringstidspunktet. Hvis planlagt opdatering er aktiveret for modellen i tjenesten, tages der hensyn til 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 f.eks. den aktuelle dato og det aktuelle klokkeslæt baseret på Pacific Time, ikke Coordinated Universal Time (UTC), som returnerer den næste dag. Opdateringshandlinger, der ikke er aktiveret via Power BI-tjeneste, f.eks. TMSL-opdateringskommandoen, skal du ikke overveje tidszonen for planlagt opdatering.

Screenshot of Scheduled refresh dialog showing the Time zone input field

Konfigurer trinvis opdatering og data i realtid

I dette afsnit beskrives vigtige begreber om konfiguration af trinvis opdatering og data i realtid. Når du er klar til mere detaljerede trinvise instruktioner, skal du se Konfigurer trinvis opdatering og data i realtid for semantiske modeller.

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 har publiceret til Power BI-tjeneste, kan du ikke publicere den samme model igen fra Power BI Desktop. Genpublicering fjerner alle eksisterende partitioner og data, der allerede findes i modellen. Hvis du publicerer til en Premium-kapacitet, kan efterfølgende ændringer af metadataskemaet foretages med værktøjer som ALM Toolkit med åben kildekode eller ved hjælp af TMSL. Du kan få mere at vide under Avanceret trinvis opdatering – Installation kun af metadata.
  • Når du har publicet på Power BI-tjeneste, kan du ikke downloade modellen tilbage som en .pbix til Power BI Desktop. Da modeller i tjenesten kan blive så store, er det upraktisk at downloade og åbne dem på en typisk stationær computer.
  • Når du henter data i realtid med DirectQuery, kan du ikke publicere modellen til et arbejdsområde, der ikke er Premium. Trinvis opdatering med data i realtid understøttes kun med Power BI Premium.

Opret parametre

Hvis du vil konfigurere trinvis opdatering i Power BI Desktop, skal du først oprette to parametre for dato/klokkeslæt i Power Query med de reserverede navne med forskel på store og små bogstaver RangeStart og RangeEnd. 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. RangeStart repræsenterer den ældste eller tidligste dato/klokkeslæt og RangeEnd repræsenterer den nyeste eller seneste dato/klokkeslæt. Når modellen er publiceret til tjenesten, RangeStart og RangeEnd den automatisk tilsidesættes 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. gennemsnit 10.000 nye rækker pr. dag. Hvis du vil begrænse antallet af rækker, der oprindeligt indlæses i modellen i Power BI Desktop, skal du angive en periode på to dage mellem RangeStart og RangeEnd.

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

Filtrer data

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

Screenshot of column context menu with Custom Filter selected

Med eksemplet FactInternetSales indlæses to dages data (ca. 20.000 rækker) i modellen, når du har oprettet filtre baseret på parametrene og anvendt trin.

Definer politik

Når der er anvendt filtre, og et undersæt af data er indlæst i modellen, kan du definere en politik for trinvis opdatering 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 og valgfrie indstillinger.

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

Table

Listen Vælg tabel er som standard den tabel, du har valgt i datavisning. Aktivér trinvis opdatering af tabellen med skyderen. Hvis Power Query-udtrykket for tabellen ikke indeholder et filter, der er baseret på parametrene RangeStart og RangeEnd , er til/fra-knappen ikke tilgængelig.

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 modellen 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 du f.eks. angiver fem år, gemmer tabellen de sidste fem hele år med historiske data i årspartitioner. Tabellen indeholder også rækker for det aktuelle år i partitioner for kvartal, måned eller dag op til og med opdateringsperioden.

For modeller i Premium-kapaciteter kan backderede 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 du f.eks. angiver en opdateringsperiode på tre dage med hver opdateringshandling, 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 tre-dages periode, hvor starten og slutningen afhænger af den aktuelle dato og det aktuelle klokkeslæt. Rækker med en dato/et klokkeslæt i de sidste tre dage op til det aktuelle opdateringstidspunkt opdateres. Med denne type politik kan du forvente, at vores FactInternetSales-modeltabel i tjenesten, som i gennemsnit er 10.000 nye rækker pr. dag, vil opdatere ca. 30.000 rækker med hver opdateringshandling.

Angiv en periode, der kun indeholder det mindste antal rækker, der kræves for at sikre nøjagtig rapportering. Når du definerer politikker for mere end én tabel, skal det samme RangeStart og RangeEnd parametre bruges, selvom der er defineret forskellige lagrings- 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 er inkluderet i en DirectQuery-partition og hentes fra datakilden med hver modelforespørgsel.

Hvis denne indstilling f.eks. er aktiveret for hver opdateringshandling, 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, hvor starten er afhængig af den aktuelle dato og det aktuelle klokkeslæt. Rækker med en dato/et klokkeslæt efter det aktuelle opdateringstidspunkt er også inkluderet. Med denne type politik indeholder modeltabellen FactInternetSales i tjenesten de seneste dataopdateringer.

Indstillingen Opdater kun hele dage sikrer, at alle rækker for hele dagen medtages i opdateringshandlingen. Denne indstilling er valgfri, medmindre du aktiverer indstillingen Hent de nyeste data i realtid med DirectQuery (kun Premium). Lad os f.eks. sige, at din opdatering er planlagt til at køre kl. 04: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 gasindustrien giver ingen mening med delvise dage. Et andet eksempel er opdatering af data fra et finansielt system, hvor data for den forrige måned godkendes på månedens tolvte kalenderdag. Du kan angive opdateringsperioden til én måned og planlægge opdateringen til at køre den tolvte dag i måneden. Når denne indstilling er valgt, opdateres dataene for januar f.eks. den 12. februar.

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

Indstillingen Registrer dataændringer muliggør endnu mere selektiv opdatering. Du kan vælge en dato-/klokkeslætskolonne, der kun bruges til at identificere og opdatere de dage, hvor dataene er blevet ændret. Denne indstilling forudsætter, at der findes en sådan kolonne i datakilden, som typisk er til overvågningsformål. Denne kolonne må ikke være den samme kolonne, der bruges til at partitionere dataene med parametrene RangeStart og RangeEnd . Den maksimale værdi 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, hvilket kan reducere de dage, der opdateres trinvist, fra tre til én.

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 Query-funktion.
  • 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 sidste opdatering i cachen i hukommelsen eller aktivere scenarier, hvor en konfigurations-/instruktionstabel forberedes af ETL-processer (extract-transform-load) til kun at markere de partitioner, der skal opdateres. I tilfælde som disse skal du bruge TMSL og/eller TOM til at tilsidesætte funktionsmåden for registrering af dataændringer for Premium-kapaciteter. 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å modellen.

Bemærk

Semantiske modeller 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 modellen vil vokse ud over 1 GB for modeller, der er publiceret til arbejdsområder, der er tildelt Premium-kapaciteter, kan du forbedre ydeevnen for opdateringshandlinger og sikre, at modellen ikke overskrider størrelsesgrænserne ved at aktivere Lagringsformat for store modeller, før du udfører den første opdateringshandling i tjenesten. Du kan få mere at vide under Store modeller i Power BI Premium.

Vigtigt

Når Power BI Desktop har publiceret modellen til tjenesten, kan du ikke downloade denne .pbix tilbage.

Opdater

Når du har publicet til tjenesten, udfører du en indledende opdateringshandling på modellen. Denne opdatering skal være en individuel (manuel) opdatering, så du kan overvåge status. Det kan tage lang tid at fuldføre den indledende opdateringshandling. Partitioner skal oprettes, historiske data indlæses, objekter som f.eks. relationer og hierarkier, der er bygget eller genopbygget, 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 meget mindre tid end den første opdatering.

Automatisk opdatering af rapport

For rapporter, der bruger en model med en trinvis opdateringspolitik til 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 indeholder de nyeste data uden forsinkelse. Du kan få mere at vide under Automatisk sideopdatering i Power BI.

Avanceret trinvis opdatering

Hvis din model er på en Premium-kapacitet med et XMLA-slutpunkt aktiveret, kan trinvis opdatering udvides yderligere for avancerede scenarier. Du kan f.eks. bruge SQL Server Management Studio til at få vist og administrere partitioner, starte den indledende opdateringshandling eller opdatere backdated historiske partitioner. Du kan få mere at vide under Avanceret trinvis opdatering med XMLA-slutpunktet.

Community

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