Forstå og optimer opdatering af dataflow
Power BI-dataflow giver dig mulighed for at oprette forbindelse til, transformere, kombinere og distribuere data til downstream-analyser. Et vigtigt element i dataflow er opdateringsprocessen, som anvender de transformationstrin, du har oprettet i dataflowene, og opdaterer dataene i selve elementerne.
For at forstå kørselstider, ydeevne og om du får mest muligt ud af dit dataflow, kan du downloade opdateringshistorikken, når du har opdateret et dataflow.
Forstå opdateringer
Der er to typer opdateringer, der gælder for dataflow:
Fuld, hvilket udfører en komplet rydning og genindlæsning af dine data.
Trinvis (kun Premium), som behandler et undersæt af dine data baseret på tidsbaserede regler, udtrykt som et filter, som du konfigurerer. Filteret på datokolonnen opdeler dynamisk dataene i områder i Power BI-tjeneste. Når du har konfigureret den trinvise opdatering, ændrer dataflowet automatisk din forespørgsel, så den omfatter filtrering efter dato. Du kan redigere den automatisk genererede forespørgsel ved hjælp af Avanceret editor i Power Query for at finjustere eller tilpasse opdateringen. Hvis du medbringer dit eget Azure Data Lake Storage, kan du se tidsudsnit af dine data baseret på den opdateringspolitik, du har angivet.
Bemærk
Hvis du vil vide mere om trinvis opdatering, og hvordan det fungerer, skal du se Brug af trinvis opdatering med dataflow.
Trinvis opdatering muliggør store dataflow i Power BI med følgende fordele:
Opdateringerne er hurtigere efter den første opdatering på grund af følgende fakta:
- Power BI opdaterer de sidste N-partitioner , der er angivet af brugeren (hvor partitionen er dag/uge/måned osv.), eller
- Power BI opdaterer kun data, der skal opdateres. Opdatering af f.eks. kun de sidste fem dage i en 10-årig semantisk model.
- Power BI opdaterer kun data, der er ændret, så længe du angiver den kolonne, du vil kontrollere for ændringer.
Opdateringer er mere pålidelige – det er ikke længere nødvendigt at vedligeholde langvarige forbindelser til flygtige kildesystemer.
Ressourceforbruget reduceres – færre data, der skal opdateres, reducerer det samlede forbrug af hukommelse og andre ressourcer.
Power BI anvender så vidt muligt parallel behandling på partitioner, hvilket kan føre til hurtigere opdateringer.
Hvis en opdatering mislykkes, opdateres dataene ikke i nogen af disse opdateringsscenarier. Dine data er muligvis forældede, indtil den seneste opdatering er fuldført, eller du kan opdatere dem manuelt, og de kan derefter fuldføres uden fejl. Opdateringen sker ved en partition eller enhed, så hvis en trinvis opdatering mislykkes, eller hvis der er en fejl i et objekt, sker hele opdateringstransaktionen ikke. Sagt på en anden måde: Hvis en partition (trinvis opdateringspolitik) eller enhed mislykkes for et dataflow, mislykkes hele opdateringshandlingen, og ingen data opdateres.
Forstå og optimer opdateringer
Hvis du vil have en bedre forståelse af, hvordan en opdateringshandling for et dataflow udføres, skal du gennemse opdateringshistorikken for dataflowet ved at navigere til et af dine dataflow. Vælg Flere indstillinger (...) for dataflowet. Vælg derefter Indstillinger > Opdater historik. Du kan også vælge dataflowet i arbejdsområdet. Vælg derefter Flere indstillinger (...) > Opdater historik.
Opdateringshistorikken indeholder en oversigt over opdateringer, herunder typen – efter behov eller planlagt, varigheden og kørselsstatussen. Hvis du vil se detaljer i form af en CSV-fil, skal du vælge downloadikonet længst til højre for rækken med opdateringsbeskrivelsen. Den downloadede CSV indeholder de attributter, der er beskrevet i følgende tabel. Premium-opdateringer giver flere oplysninger baseret på de ekstra beregnings- og dataflowfunktioner i forhold til Pro-baserede dataflow, der er placeret på delt kapacitet. Derfor er nogle af følgende målepunkter kun tilgængelige i Premium.
| Element | Beskrivelse | Pro | Premium |
|---|---|---|---|
| Anmodet den | Der blev klikket på tidspunktet for planlagt opdatering, eller der blev klikket på opdater nu i lokaltid. | ✔ | ✔ |
| Navn på dataflow | Navnet på dit dataflow. | ✔ | ✔ |
| Opdateringsstatus for dataflow | Fuldført, Mislykket eller Sprunget over (for en enhed) er mulige statusser. Brug af sager som Linked Entities er årsager til, at man kan se sprunget over. | ✔ | ✔ |
| Enhedsnavn | Tabelnavn. | ✔ | ✔ |
| Partitionsnavn | Dette element afhænger af, om dataflowet er premium eller ej, og om Pro vises som NA, fordi det ikke understøtter trinvise opdateringer. Premium viser enten FullRefreshPolicyPartition eller IncrementalRefreshPolicyPartition-[DateRange]. | ✔ | |
| Opdateringsstatus | Opdateringsstatus for det enkelte objekt eller den enkelte partition, som giver status for det tidsudsnit af data, der opdateres. | ✔ | ✔ |
| Starttidspunkt | I Premium er dette element det tidspunkt, hvor dataflowet blev sat i kø til behandling for enheden eller partitionen. Denne tid kan variere, hvis dataflows har afhængigheder og skal vente på, at resultatsættet for et upstream-dataflow begynder behandlingen. | ✔ | ✔ |
| Sluttidspunkt | Sluttidspunktet er det tidspunkt, hvor dataflowobjektet eller -partitionen blev fuldført, hvis det er relevant. | ✔ | ✔ |
| Varighed | Den samlede forløbne tid for det dataflow, der skal opdateres, udtrykt i TT:MM:SS. | ✔ | ✔ |
| Behandlede rækker | For en given enhed eller partition er antallet af rækker, der er scannet eller skrevet af dataflowprogrammet. Dette element indeholder muligvis ikke altid data, der er baseret på den handling, du har udført. Data kan udelades, når beregningsprogrammet ikke bruges, eller når du bruger en gateway, når dataene behandles der. | ✔ | |
| Behandlede byte | For en given enhed eller partition, data, der er skrevet af dataflowprogrammet, udtrykt i byte. Når du bruger en gateway i dette bestemte dataflow, angives disse oplysninger ikke. |
✔ | |
| Maks. bekræftelse (KB) | Max Commit er den maksimale allokerede hukommelse, der er nyttig til diagnosticering af out-of-memory-fejl, når M-forespørgslen ikke er optimeret. Når du bruger en gateway på dette bestemte dataflow, angives disse oplysninger ikke. |
✔ | |
| Processortid | For en given enhed eller partition, tid, udtrykt i HH:MM:SS, som dataflowprogrammet brugte på at udføre transformationer. Når du bruger en gateway på dette bestemte dataflow, angives disse oplysninger ikke. |
✔ | |
| Ventetid | For en given enhed eller partition er den tid, som en enhed har brugt på ventestatus, baseret på arbejdsbelastningen på Premium-kapaciteten. | ✔ | |
| Beregningsprogram | Oplysninger om, hvordan opdateringshandlingen bruger beregningsprogrammet, for en given enhed eller partition. Værdierne er: -NA -Foldet -Cache - Cachelagret + foldet Disse elementer beskrives mere detaljeret senere i denne artikel. |
✔ | |
| Error | Hvis det er relevant, beskrives den detaljerede fejlmeddelelse pr. enhed eller partition. | ✔ | ✔ |
Vejledning til opdatering af dataflow
Opdateringsstatistikken indeholder værdifulde oplysninger, som du kan bruge til at optimere og fremskynde ydeevnen af dine dataflow. I de følgende afsnit beskriver vi nogle scenarier, hvad du skal holde øje med, og hvordan du optimerer baseret på de angivne oplysninger.
Orkestrering
Brug af dataflow i det samme arbejdsområde gør det nemt at organisere. Du kan f.eks. have dataflow A, B og C i et enkelt arbejdsområde og sammenkæde som A > B > C. Hvis du opdaterer kilden (A), opdateres downstreamenhederne også. Men hvis du opdaterer C, skal du opdatere andre uafhængigt af hinanden. Hvis du tilføjer en ny datakilde i dataflow B (som ikke er inkluderet i A), opdateres disse data heller ikke som en del af orkestrering.
Det kan være en god idé at sammenkæde elementer, der ikke passer til den administrerede orkestrering, som Power BI udfører. I disse scenarier kan du bruge API'erne og/eller bruge Power Automate. Du kan se API-dokumentationen og PowerShell-scriptettil programmatisk opdatering. Der er en Power Automate-connector, der gør det muligt at udføre denne procedure uden at skrive kode. Du kan se detaljerede eksempler med specifikke gennemgange af sekventielle opdateringer.
Overvågning
Ved hjælp af den forbedrede opdateringsstatistik, der er beskrevet tidligere i denne artikel, kan du få detaljerede oplysninger om opdatering pr. dataflow. Men hvis du gerne vil have vist dataflow med en oversigt over opdateringer i hele lejeren eller arbejdsområdet, kan du måske bruge API'erne eller PowerAutomate-skabelonerne til at oprette et overvågningsdashboard. På samme måde kan du bruge PowerAutomate-connectoren til at sende enkle eller komplekse meddelelser eller oprette dit eget brugerdefinerede program ved hjælp af API'erne.
Timeoutfejl
Det er ideelt at optimere den tid, det tager at udtrække, transformere og indlæse (ETL). I Power BI gælder følgende tilfælde:
- Nogle connectors har eksplicitte timeoutindstillinger, som du kan konfigurere. Du kan få flere oplysninger under Forbind orer i Power Query.
- Power BI-dataflows, der bruger Power BI Pro, kan også opleve timeout for langvarige forespørgsler i en enhed eller selve dataflowet. Denne begrænsning findes ikke i Power BI Premium-arbejdsområder.
Vejledning til timeout
Timeoutgrænserne for Power BI Pro-dataflow er:
- To timer på det individuelle enhedsniveau.
- Tre timer på hele dataflowniveauet.
Hvis du f.eks. har et dataflow med tre tabeller, kan ingen individuel tabel tage mere end to timer, og hele dataflowet får timeout, hvis varigheden overstiger tre timer.
Hvis du oplever timeout, kan du overveje at optimere dine dataflowforespørgsler og overveje at bruge forespørgselsdelegering på dine kildesystemer.
Overvej at opgradere til Premium pr. bruger, som ikke er underlagt disse timeouts, og som giver øget ydeevne på grund af mange funktioner i Power BI Premium pr. bruger.
Lange varigheder
Det kan tage længere tid at opdatere komplekse eller store dataflow, og det kan også være dårligt optimerede dataflow. Følgende afsnit indeholder en vejledning i, hvordan du afhjælper lange opdateringsvarigheder.
Vejledning til lange opdateringsvarigheder
Det første trin til at forbedre lange opdateringsvarigheder for dataflow er at oprette dataflow i henhold til de bedste fremgangsmåder. Bemærkelsesværdige mønstre omfatter:
- Brug sammenkædede objekter til data, der kan bruges senere i andre transformationer.
- Brug beregnede enheder til at cachelagre data, hvilket reducerer byrden ved indlæsning af data og dataindtagelse på kildesystemer.
- Opdel data i midlertidige dataflow og transformationsdataflow, og adskil ETL i forskellige dataflow.
- Optimer udvidelse af tabelhandlinger.
- Følg vejledningen til komplekse dataflow.
Derefter kan det hjælpe med at evaluere, om du kan bruge trinvis opdatering.
Brug af trinvis opdatering kan forbedre ydeevnen. Det er vigtigt, at partitionsfiltrene sendes til kildesystemet, når der sendes forespørgsler til opdateringshandlinger. Hvis du vil pushe filtrering ned, betyder det, at datakilden skal understøtte forespørgselsdelegering, eller du kan udtrykke forretningslogik via en funktion eller andre midler, der kan hjælpe Power Query med at fjerne og filtrere filer eller mapper. De fleste datakilder, der understøtter SQL-forespørgsler, understøtter forespørgselsdelegering, og nogle OData-feeds kan også understøtte filtrering.
Datakilder som flade filer, blobs og API'er understøtter dog normalt ikke filtrering. I tilfælde, hvor datakildens backend ikke understøtter filteret, kan den ikke skubbes ned. I sådanne tilfælde kompenserer miksprogrammet og anvender filteret lokalt, hvilket kan kræve, at den komplette semantiske model hentes fra datakilden. Denne handling kan medføre, at trinvis opdatering er langsom, og processen kan løbe tør for ressourcer enten i Power BI-tjeneste eller i datagatewayen i det lokale miljø, hvis den bruges.
På grund af de forskellige niveauer af understøttelse af forespørgselsdelegering for hver datakilde skal du udføre bekræftelse for at sikre, at filterlogikken er inkluderet i kildeforespørgslerne. For at gøre det nemmere forsøger Power BI at udføre denne bekræftelse for dig med trinvise foldningsindikatorer for Power Query Online. Mange af disse optimeringer er designtidsoplevelser, men efter en opdatering har du mulighed for at analysere og optimere ydeevnen for din opdatering.
Endelig kan du overveje at optimere dit miljø. Du kan optimere Power BI-miljøet ved at opskalere din kapacitet, tilpasse størrelsen på datagateways og reducere netværksventetiden med følgende optimeringer:
Når du bruger kapaciteter, der er tilgængelige med Power BI Premium eller Premium pr. bruger, kan du øge ydeevnen ved at øge din Premium-forekomst eller tildele indholdet til en anden kapacitet.
Der kræves en gateway, når Power BI har brug for at få adgang til data, der ikke er tilgængelige direkte via internettet. Du kan installere datagatewayen i det lokale miljø på en server i det lokale miljø eller på en virtuel maskine.
- Hvis du vil forstå gatewayarbejdsbelastninger og tilpasningsanbefalinger, skal du se Størrelse på datagateway i det lokale miljø.
- Evaluer også, om dataene først overføres til et midlertidigt dataflow, og referer til dem downstream ved hjælp af sammenkædede og beregnede enheder.
Netværksventetid kan påvirke opdateringsydeevnen ved at øge den tid, det tager for anmodninger at nå Power BI-tjeneste, og for at svar kan leveres. Lejere i Power BI tildeles til et bestemt område. Hvis du vil finde ud af, hvor din lejer er placeret, skal du se Find standardområdet for din organisation. Når brugere fra en lejer får adgang til Power BI-tjeneste, dirigeres deres anmodninger altid til det pågældende område. Når anmodninger når Power BI-tjeneste, kan tjenesten derefter sende ekstra anmodninger, f.eks. til den underliggende datakilde eller en datagateway – som også er underlagt netværksventetid.
- Værktøjer som Azure Speed Test giver en indikation af netværksventetid mellem klienten og Azure-området. For at minimere virkningen af netværksventetid skal du generelt bestræbe dig på at holde datakilder, gateways og din Power BI-klynge så tæt som muligt. Bopæl i samme område er at foretrække. Hvis netværksventetid er et problem, kan du prøve at finde gateways og datakilder tættere på din Power BI-klynge ved at placere dem på virtuelle maskiner, der hostes i cloudmiljøet.
Høj processortid
Hvis du ser høj processortid, har du sandsynligvis dyre transformationer, der ikke foldes. Den høje processortid er enten på grund af det antal anvendte trin, du har, eller den type transformationer, du foretager. Hver af disse muligheder kan resultere i højere opdateringstider.
Vejledning til høj processortid
Der er to muligheder for at optimere høj processortid.
Brug først forespørgselsdelegering i selve datakilden, hvilket skulle reducere belastningen af dataflowberegningsprogrammet direkte. Forespørgselsdelegering i datakilden gør det muligt for kildesystemet at udføre det meste af arbejdet. Dataflowet kan derefter passere gennem forespørgsler på kildens oprindelige sprog i stedet for at skulle udføre alle beregningerne i hukommelsen efter den indledende forespørgsel.
Det er ikke alle datakilder, der kan udføre forespørgselsdelegering, og selvom forespørgselsdelegering er mulig, kan der være dataflow, der udfører visse transformationer, der ikke kan foldes til kilden. I sådanne tilfælde er det forbedrede beregningsprogram en funktion, der introduceres af Power BI for potentielt at forbedre ydeevnen med op til 25 gange for transformationer specifikt.
Brug beregningsprogrammet til at maksimere ydeevnen
Selvom Power Query har designtidssynlighed i forespørgselsdelegering, indeholder kolonnen med beregningsprogrammet oplysninger om, hvorvidt selve det interne program bruges. Beregningsprogrammet er nyttigt, når du har et komplekst dataflow, og du udfører transformationer i hukommelsen. Denne situation er, hvor den forbedrede opdateringsstatistik kan være nyttig, da kolonnen med beregningsprogrammet indeholder oplysninger om, hvorvidt selve programmet blev brugt eller ej.
Følgende afsnit indeholder en vejledning i brug af beregningsprogrammet og dets statistikker.
Advarsel!
I designperioden kan foldeindikatoren i editoren vise, at forespørgslen ikke foldes, når der bruges data fra et andet dataflow. Kontrollér kildedataflowet, hvis forbedret beregning er aktiveret for at sikre, at foldning på kildedataflowet er aktiveret.
Vejledning til statusser for beregningsprogram
Det er nyttigt at aktivere det forbedrede beregningsprogram og forstå de forskellige statusser. Internt bruger det forbedrede beregningsprogram en SQL-database til at læse og gemme data. Det er bedst at få dine transformationer udført i forhold til forespørgselsprogrammet her. Følgende afsnit indeholder forskellige situationer og vejledning om, hvad du skal gøre for hver enkelt.
NA – Denne status betyder, at beregningsprogrammet ikke blev brugt, enten fordi:
- Du bruger Power BI Pro-dataflow.
- Du har eksplicit deaktiveret beregningsprogrammet.
- Du bruger forespørgselsdelegering på datakilden.
- Du udfører komplekse transformationer, der ikke kan gøre brug af det SQL-program, der bruges til at fremskynde forespørgsler.
Hvis du oplever lange varigheder og stadig får status som NA, skal du sørge for, at den er slået til og ikke ved et uheld slået fra. Et anbefalet mønster er at bruge midlertidige dataflow til indledningsvist at hente dine data ind i Power BI-tjeneste og derefter oprette dataflow oven på disse data, når de er i et midlertidigt dataflow. Dette mønster kan reducere belastningen på kildesystemer og sammen med beregningsprogrammet give et hastighedsboost til transformationer og forbedre ydeevnen.
Cachelagret – Hvis du ser den cachelagrede status, blev dataflowdataene gemt i beregningsprogrammet og kan refereres til som en del af en anden forespørgsel. Denne situation er ideel, hvis du bruger den som en sammenkædet enhed, fordi beregningsprogrammet cachelagrer disse data til brug downstream. De cachelagrede data behøver ikke at blive opdateret flere gange i det samme dataflow. Denne situation er også potentielt ideel, hvis du vil bruge den til DirectQuery.
Når den cachelagres, betaler påvirkningen af ydeevnen for den indledende indtagelse sig senere, i det samme dataflow eller i et andet dataflow i det samme arbejdsområde.
Hvis du har en stor varighed for enheden, kan du overveje at slå beregningsprogrammet fra. Hvis du vil cachelagre objektet, skriver Power BI det til lager og til SQL. Hvis det er en enhed med enkelt brug, er ydelsesfordelen for brugerne muligvis ikke værd at betale for dobbeltindtagelse.
Foldet – foldet betyder, at dataflowet kunne bruge SQL Compute til at læse data. Det beregnede objekt brugte tabellen fra SQL til at læse data, og den anvendte SQL er relateret til konstruktioner af deres forespørgsel.
Foldet status vises, hvis du første gang indlæste data i et midlertidigt dataflow, når du bruger datakilder i det lokale miljø eller cloudmiljøet, og der refereres til dem i dette dataflow. Denne status gælder kun for enheder, der refererer til et andet objekt. Det betyder, at dine forespørgsler blev kørt oven på SQL-programmet, og at de kan forbedres med SQL Compute. Hvis du vil sikre, at SQL-programmet behandler dine transformationer, skal du bruge transformationer, der understøtter SQL-foldning, f.eks. fletning (joinforbindelse), gruppér efter (sammenlægning) og tilføjelseshandlinger (foreningshandlinger) i Power Query-editor.
Cachelagret + foldet – Når du ser cachelagret + foldet, er det sandsynligt, at dataopdateringen er optimeret, da du har et objekt, der begge refererer til et andet objekt og refereres til af en anden enhed upstream. Denne handling kører også oven på SQL og kan derfor også forbedres med SQL-beregning. Hvis du vil sikre dig, at du får den bedst mulige ydeevne, skal du bruge transformationer, der understøtter SQL-foldning, f.eks. fletning (joinforbindelse), gruppér efter (sammenlægning) og tilføjelseshandlinger (forening) i Power Query-editor.
Vejledning til optimering af ydeevne for beregningsprogrammet
Følgende trin gør det muligt for arbejdsbelastninger at udløse beregningsprogrammet og dermed altid forbedre ydeevnen.
Beregnede og sammenkædede objekter i det samme arbejdsområde:
I forbindelse med indtagelse skal du fokusere på at få dataene ind i lageret så hurtigt som muligt. Brug kun filtre, hvis de reducerer den samlede semantiske modelstørrelse. Hold din transformationslogik adskilt fra dette trin. Derefter skal du adskille din transformation og forretningslogik i et separat dataflow i det samme arbejdsområde. Brug sammenkædede eller beregnede enheder. Det gør det muligt for programmet at aktivere og fremskynde dine beregninger. For en simpel analogi er det som tilberedning af mad i et køkken: tilberedning af mad er typisk et separat og særskilt trin fra indsamling af dine råvarer og en forudsætning for at sætte maden i ovnen. På samme måde skal du forberede din logik separat, før den kan drage fordel af beregningsprogrammet.
Sørg for, at du udfører de handlinger, der foldes, f.eks. fletninger, joinforbindelser, konvertering og andre.
Du kan også oprette dataflow i publicerede retningslinjer og begrænsninger.
Når beregningsprogrammet er slået til, men ydeevnen er langsom:
Udfør følgende trin, når du undersøger scenarier, hvor beregningsprogrammet er slået til, men hvor ydeevnen er dårlig:
- Begræns beregnede og sammenkædede objekter, der findes på tværs af arbejdsområdet.
- Hvis din første opdatering er, når beregningsprogrammet er slået til, skrives data i søen og i cachen. Denne dobbeltskrivning medfører, at opdateringerne bliver langsommere.
- Hvis du har et dataflow, der linker til flere dataflow, skal du sørge for at planlægge opdateringer af kildedataflowene, så de ikke alle opdateres på samme tid.
Overvejelser og begrænsninger
En Power BI Pro-licens har en opdateringsgrænse for dataflow på 8 opdateringer pr. dag.