Forstå og optimalisere oppdatering av dataflyter
Med Power BI-dataflyter kan du koble til, transformere, kombinere og distribuere data for nedstrøms analyse. Et viktig element i dataflyter er oppdateringsprosessen, som bruker transformasjonstrinnene du forfattet i dataflytene, og oppdaterer dataene i selve elementene.
Hvis du vil forstå kjøretider, ytelse og om du får mest mulig ut av dataflyten, kan du laste ned oppdateringsloggen etter at du har oppdatert en dataflyt.
Forstå oppdateringer
Det finnes to typer oppdateringer som gjelder for dataflyter:
Full, som utfører en fullstendig tømming og omlasting av dataene.
Trinnvis (bare Premium), som behandler et delsett av dataene basert på tidsbaserte regler, uttrykt som et filter, som du konfigurerer. Filteret i datokolonnen partisjonerer dataene dynamisk i områder i Power Bi-tjeneste. Når du har konfigurert den trinnvise oppdateringen, endrer dataflyten automatisk spørringen til å inkludere filtrering etter dato. Du kan redigere den automatisk genererte spørringen ved hjelp av avansert redigering i Power Query for å finjustere eller tilpasse oppdateringen. Hvis du tar med din egen Azure Data Lake Storage, kan du se tidssektorer av dataene dine basert på oppdateringspolicyen du har angitt.
Merk
Hvis du vil lære mer om trinnvis oppdatering og hvordan det fungerer, kan du se Bruke trinnvis oppdatering med dataflyter.
Trinnvis oppdatering muliggjør store dataflyter i Power BI med følgende fordeler:
Oppdateringer er raskere etter den første oppdateringen, på grunn av følgende fakta:
- Power BI oppdaterer de siste N-partisjonene som er angitt av brukeren (der partisjonen er dag/uke/måned og så videre), eller
- Power BI oppdaterer bare data som må oppdateres. Hvis du for eksempel oppdaterer bare de siste fem dagene av en 10-årig semantisk modell.
- Power BI oppdaterer bare data som er endret, så lenge du angir kolonnen du vil se etter endringer.
Oppdateringer er mer pålitelige – det er ikke lenger nødvendig å opprettholde langvarige tilkoblinger til flyktige kildesystemer.
Ressursforbruket reduseres – mindre data for oppdatering reduserer det totale forbruket av minne og andre ressurser.
Der det er mulig, bruker Power BI parallell behandling på partisjoner, noe som kan føre til raskere oppdateringer.
Hvis en oppdatering mislykkes, oppdateres ikke dataene i noen av disse oppdateringsscenarioene. Dataene kan være foreldet til den siste oppdateringen er fullført, eller du kan oppdatere dem manuelt, og det kan deretter fullføres uten feil. Oppdatering skjer på en partisjon eller enhet, så hvis en trinnvis oppdatering mislykkes, eller en enhet har en feil, skjer ikke hele oppdateringstransaksjonen. Sagt på en annen måte, hvis en partisjon (trinnvis oppdateringspolicy) eller enhet mislykkes for en dataflyt, mislykkes hele oppdateringsoperasjonen, og ingen data blir oppdatert.
Forstå og optimalisere oppdateringer
Hvis du vil forstå hvordan en dataflytoppdateringsoperasjon utføres, kan du se gjennom oppdateringsloggen for dataflyten ved å navigere til en av dataflytene. Velg Flere alternativer (...) for dataflyten. Velg deretter Innstillinger > Oppdateringslogg. Du kan også velge dataflyten i arbeidsområdet. Velg deretter Flere alternativer (...) > Oppdateringslogg.
Oppdateringsloggen gir en oversikt over oppdateringer, inkludert typen – ved behov eller planlagt, varigheten og kjørestatusen. Hvis du vil se detaljer i form av en CSV-fil, velger du nedlastingsikonet helt til høyre i raden for oppdateringsbeskrivelsen. Den nedlastede CSV-en inneholder attributtene som er beskrevet i tabellen nedenfor. Premium-oppdateringer gir mer informasjon basert på de ekstra databehandlings- og dataflytfunksjonene, kontra Pro-baserte dataflyter som ligger på delt kapasitet. Som sådan er noen av følgende måledata bare tilgjengelige i Premium.
| Element | Bekrivelse | Fordel | Premium |
|---|---|---|---|
| Forespurt | Tidsoppdatering ble planlagt eller oppdatering ble nå klikket, i lokal tid. | ✔ | ✔ |
| Dataflytnavn | Navnet på dataflyten. | ✔ | ✔ |
| Oppdateringsstatus for dataflyt | Fullførte, mislykkede eller hoppet over (for en enhet) er mulige statuser. Brukstilfeller som koblede enheter er årsaker til at man kan se hoppet over. | ✔ | ✔ |
| Entitynavn | Tabellnavn. | ✔ | ✔ |
| Partisjonsnavn | Dette elementet er avhengig av om dataflyten er premium eller ikke, og hvis Pro vises som NA fordi det ikke støtter trinnvise oppdateringer. Premium viser enten FullRefreshPolicyPartition eller IncrementalRefreshPolicyPartition-[DateRange]. | ✔ | |
| Oppdateringsstatus | Oppdateringsstatus for den individuelle enheten eller partisjonen, som gir status for den tidssnittet med data som oppdateres. | ✔ | ✔ |
| Starttid | I Premium er dette elementet tidspunktet dataflyten ble lagt i kø for behandling for enheten eller partisjonen. Denne gangen kan variere hvis dataflyter har avhengigheter og må vente på at resultatsettet med en oppstrøms dataflyt begynner å behandles. | ✔ | ✔ |
| Sluttidspunkt | Sluttidspunkt er tidspunktet dataflytenheten eller partisjonen er fullført, hvis aktuelt. | ✔ | ✔ |
| Varighet | Total brukt tid for dataflyten som skal oppdateres uttrykt i HH:MM:SS. | ✔ | ✔ |
| Rader behandlet | For en gitt enhet eller partisjon skannes eller skrives antall rader av dataflytmotoren. Dette elementet inneholder kanskje ikke alltid data basert på operasjonen du utførte. Data kan utelates når databehandlingsmotoren ikke brukes, eller når du bruker en gateway når dataene behandles der. | ✔ | |
| Byte behandlet | For en gitt enhet eller partisjon, data skrevet av dataflytmotoren, uttrykt i byte. Når du bruker en gateway på denne bestemte dataflyten, er ikke denne informasjonen angitt. |
✔ | |
| Maksimal utføring (KB) | Maksimalt utføring er det maksimale utføringsminnet som er nyttig for diagnostisering av minnefeil når M-spørringen ikke er optimalisert. Når du bruker en gateway på denne bestemte dataflyten, oppgis ikke denne informasjonen. |
✔ | |
| Prosessortid | For en gitt enhet eller partisjon, tid, uttrykt i HH:MM:SS at dataflytmotoren brukte på å utføre transformasjoner. Når du bruker en gateway på denne bestemte dataflyten, oppgis ikke denne informasjonen. |
✔ | |
| Ventetid | For en gitt enhet eller partisjon, tiden en enhet brukte i ventestatus, basert på arbeidsbelastning på Premium-kapasiteten. | ✔ | |
| Databehandlingsmotor | Detaljer om hvordan oppdateringsoperasjonen bruker databehandlingsmotoren for en gitt enhet eller partisjon. Verdiene er: -NA -Brettet -Bufret - Bufret + brettet Disse elementene beskrives mer detaljert senere i denne artikkelen. |
✔ | |
| Error | Hvis det er aktuelt, beskrives den detaljerte feilmeldingen per enhet eller partisjon. | ✔ | ✔ |
Veiledning for oppdatering av dataflyt
Oppdateringsstatistikken gir verdifull informasjon du kan bruke til å optimalisere og øke ytelsen til dataflytene. I de følgende avsnittene beskriver vi noen scenarioer, hva du bør se opp for, og hvordan du optimaliserer basert på informasjonen som er oppgitt.
Iverksetting
Bruk av dataflyter i samme arbeidsområde gir enkel orkestrering. Som et eksempel kan det hende du har dataflyter A, B og C i ett enkelt arbeidsområde og kjeder som A > B > C. Hvis du oppdaterer kilden (A), oppdateres også nedstrømsenheter. Hvis du oppdaterer C, må du imidlertid oppdatere andre uavhengig av hverandre. Hvis du legger til en ny datakilde i dataflyt B (som ikke er inkludert i A), oppdateres ikke dataene som en del av orkestreringen.
Det kan være lurt å kjede elementer sammen som ikke passer til den administrerte orkestreringen Power BI utfører. I disse scenarioene kan du bruke API-ene og/eller bruke Power Automate. Du kan referere til API-dokumentasjonenog PowerShell-skriptet for programmatisk oppdatering. Det finnes en Power Automate-kobling som gjør det mulig å gjøre denne prosedyren uten å skrive kode. Du kan se detaljerte eksempler, med spesifikke gjennomganger for sekvensielle oppdateringer.
Overvåking
Ved hjelp av den forbedrede oppdateringsstatistikken som er beskrevet tidligere i denne artikkelen, kan du få detaljert informasjon om oppdatering per dataflyt. Men hvis du vil se dataflyter med oversikt over hele leieren eller arbeidsområdet for oppdateringer, kanskje for å bygge et instrumentbord for overvåking, kan du bruke API-er eller PowerAutomate-maler. På samme måte, for brukstilfeller som å sende enkle eller komplekse varsler, kan du bruke PowerAutomate-koblingen eller bygge ditt eget egendefinerte program ved hjelp av API-ene.
Tidsavbruddsfeil
Optimalisering av tiden det tar å utføre uttrekkings-, transformerings- og belastningsscenarioer (ETL) er ideelt. I Power BI gjelder følgende tilfeller:
- Noen koblinger har eksplisitte innstillinger for tidsavbrudd som du kan konfigurere. Hvis du vil ha mer informasjon, kan du se Koble til orer i Power Query.
- Power BI-dataflyter, som bruker Power BI Pro, kan også oppleve tidsavbrudd for langvarige spørringer i en enhet eller dataflyter selv. Denne begrensningen finnes ikke i Power BI Premium-arbeidsområder.
Veiledning for tidsavbrudd
Tidsavbruddsterskler for Power BI Pro-dataflyter er:
- To timer på det individuelle enhetsnivået.
- Tre timer på hele dataflytnivået.
Hvis du for eksempel har en dataflyt med tre tabeller, kan ingen enkelttabell ta mer enn to timer, og hele dataflyten blir tidsavbrutt hvis varigheten overskrider tre timer.
Hvis du opplever tidsavbrudd, bør du vurdere å optimalisere dataflytspørringene og vurdere å bruke spørringsdelegering på kildesystemene.
Vurder å oppgradere til Premium per bruker separat, som ikke er underlagt disse tidsavbruddene, og gir økt ytelse på grunn av mange Funksjoner i Power BI Premium per bruker.
Lange varigheter
Komplekse eller store dataflyter kan ta mer tid å oppdatere, det samme kan dårlig optimaliserte dataflyter. Avsnittene nedenfor gir veiledning om hvordan du reduserer lange varigheter for oppdateringer.
Veiledning for lange varigheter for oppdateringer
Det første trinnet for å forbedre varigheten for lange oppdateringer for dataflyter, er å bygge dataflyter i henhold til anbefalte fremgangsmåter. Bemerkelsesverdige mønstre inkluderer:
- Bruk koblede enheter for data som kan brukes senere i andre transformasjoner.
- Bruk beregnede enheter til å bufre data, noe som reduserer datainnlasting og datainntaksbyrde på kildesystemer.
- Del data inn i oppsamling av dataflyter og transformasjonsdataflyter, og del ETL-en i ulike dataflyter.
- Optimaliser utvidelse av tabelloperasjoner.
- Følg veiledning for komplekse dataflyter.
Deretter kan det hjelpe å vurdere om du kan bruke trinnvis oppdatering.
Bruk av trinnvis oppdatering kan forbedre ytelsen. Det er viktig at partisjonsfiltrene sendes til kildesystemet når spørringer sendes til oppdateringsoperasjoner. Hvis du vil sende filtrering ned, må datakilden støtte spørringsdelegering, eller du kan uttrykke forretningslogikk gjennom en funksjon eller andre metoder som kan hjelpe Power Query med å eliminere og filtrere filer eller mapper. De fleste datakilder som støtter SQL-spørringer, støtter spørringsdelegering, og noen OData-feeder kan også støtte filtrering.
Datakilder som flate filer, blober og API-er støtter imidlertid vanligvis ikke filtrering. I tilfeller der datakildens bakende ikke støtter filteret, kan det ikke skyves ned. I slike tilfeller kompenserer og bruker mash-up-motoren filteret lokalt, noe som kan kreve henting av den fullstendige semantiske modellen fra datakilden. Denne operasjonen kan føre til at trinnvis oppdatering går tregt, og prosessen kan gå tom for ressurser enten i Power Bi-tjeneste eller i den lokale datagatewayen, hvis den brukes.
Gitt de ulike nivåene av støtte for spørringsdelegering for hver datakilde, bør du utføre bekreftelse for å sikre at filterlogikken er inkludert i kildespørringene. For å gjøre dette enklere, prøver Power BI å utføre denne bekreftelsen for deg, med trinndelegeringsindikatorer for Power Query Online. Mange av disse optimaliseringene er utformingstidsopplevelser, men etter at en oppdatering oppstår, har du mulighet til å analysere og optimalisere oppdateringsytelsen.
Til slutt bør du vurdere å optimalisere miljøet. Du kan optimalisere Power BI-miljøet ved å skalere opp kapasiteten, endre størrelse på datagatewayer og redusere nettverksventetid med følgende optimaliseringer:
Når du bruker kapasiteter som er tilgjengelige med Power BI Premium eller Premium per bruker, kan du øke ytelsen ved å øke Premium-forekomsten eller tilordne innholdet til en annen kapasitet.
En gateway kreves når Power BI trenger tilgang til data som ikke er tilgjengelig direkte over Internett. Du kan installere den lokale datagatewayen på en lokal server eller på en virtuell maskin.
- Hvis du vil forstå gateway-arbeidsbelastninger og skaleringsanbefalinger, kan du se Lokal datagateway-størrelse.
- Evaluer også å hente dataene først inn i en oppsamlingsdataflyt, og referere til dem nedstrøms ved hjelp av koblede og beregnede enheter.
Nettverksventetid kan påvirke oppdateringsytelsen ved å øke tiden som kreves for forespørsler om å nå Power Bi-tjeneste, og for svar som skal leveres. Leiere i Power BI er tilordnet til et bestemt område. Hvis du vil finne ut hvor leieren befinner seg, kan du se Finne standardområdet for organisasjonen. Når brukere fra en leier får tilgang til Power Bi-tjeneste, rutes alltid forespørslene deres til området. Når forespørsler kommer til Power Bi-tjeneste, kan tjenesten deretter sende ekstra forespørsler, for eksempel til den underliggende datakilden eller en datagateway, som også er underlagt nettverksventetid.
- Verktøy som Azure Speed Test gir en indikasjon på nettverksventetid mellom klienten og Azure-området. Hvis du generelt vil minimere virkningen av nettverksventetid, bør du arbeide for å holde datakilder, gatewayer og Power BI-klyngen så nært som mulig. Å være bosatt i samme område er å foretrekke. Hvis nettverksventetid er et problem, kan du prøve å finne gatewayer og datakilder nærmere Power BI-klyngen ved å plassere dem i skybaserte virtuelle maskiner.
Høy prosessortid
Hvis du ser høy prosessortid, har du sannsynligvis dyre transformasjoner som ikke brettes. Den høye prosessortiden er enten på grunn av antall brukte trinn du har, eller typen transformasjoner du gjør. Hver av disse mulighetene kan resultere i høyere oppdateringstider.
Veiledning for høy prosessortid
Det finnes to alternativer for optimalisering av høy prosessortid.
Først må du bruke spørringsdelegering i selve datakilden, noe som bør redusere belastningen på dataflytdatabehandlingsmotoren direkte. Spørringsdelegering i datakilden gjør det mulig for kildesystemet å gjøre det meste av arbeidet. Dataflyten kan deretter sende gjennom spørringer på det opprinnelige språket i kilden, i stedet for å måtte utføre alle beregningene i minnet etter den første spørringen.
Ikke alle datakilder kan utføre spørringsdelegering, og selv når spørringsdelegering er mulig, kan det være dataflyter som utfører visse transformasjoner som ikke kan brettes til kilden. I slike tilfeller er den forbedrede databehandlingsmotoren en funksjon introdusert av Power BI for å potensielt forbedre ytelsen med opptil 25 ganger, spesielt for transformasjoner.
Bruk databehandlingsmotoren til å maksimere ytelsen
Selv om Power Query har utformingstidssynlighet i spørringsdelegering, gir beregningsmotorkolonnen detaljer om hvorvidt den interne motoren brukes. Databehandlingsmotoren er nyttig når du har en kompleks dataflyt, og du utfører transformasjoner i minnet. Denne situasjonen er der den forbedrede oppdateringsstatistikken kan være nyttig, siden databehandlingsmotorkolonnen gir detaljer om hvorvidt selve motoren ble brukt eller ikke.
Avsnittene nedenfor gir veiledning om hvordan du bruker databehandlingsmotoren og dens statistikk.
Advarsel!
I løpet av utformingstiden kan det hende at foldingsindikatoren i redigeringsprogrammet viser at spørringen ikke brettes når du bruker data fra en annen dataflyt. Kontroller kildedataflyten hvis forbedret databehandling er aktivert for å sikre at folding på kildedataflyten er aktivert.
Veiledning om databehandlingsmotorstatuser
Det er nyttig å slå på den forbedrede databehandlingsmotoren og forstå de ulike statusene. Internt bruker den forbedrede databehandlingsmotoren en SQL-database til å lese og lagre data. Det er best å la transformasjonene kjøre mot spørringsmotoren her. Avsnittene nedenfor gir ulike situasjoner og veiledning om hva du skal gjøre for hver av dem.
NA - Denne statusen betyr at databehandlingsmotoren ikke ble brukt, enten fordi:
- Du bruker Power BI Pro-dataflyter.
- Du har eksplisitt slått av databehandlingsmotoren.
- Du bruker spørringsdelegering på datakilden.
- Du utfører komplekse transformasjoner som ikke kan brukes av SQL-motoren som brukes til å øke hastigheten på spørringer.
Hvis du opplever lange varigheter og fremdeles får statusen NA, må du kontrollere at den er slått på og at den ikke er slått av ved et uhell. Et anbefalt mønster er å bruke oppsamlingsdataflyter til å hente dataene inn i Power Bi-tjeneste, og deretter bygge dataflyter oppå disse dataene, etter at de er i en oppsamlingsdataflyt. Dette mønsteret kan redusere belastningen på kildesystemer og, sammen med databehandlingsmotoren, gi en hastighetsøkning for transformasjoner og forbedre ytelsen.
Bufret – Hvis du ser den bufrede statusen, ble dataflytdataene lagret i databehandlingsmotoren og tilgjengelig for referanse som en del av en annen spørring. Denne situasjonen er ideell hvis du bruker den som en koblet enhet, fordi databehandlingsmotoren bufrer dataene for bruk nedstrøms. De bufrede dataene trenger ikke oppdateres flere ganger i samme dataflyt. Denne situasjonen er også potensielt ideell hvis du vil bruke den for DirectQuery.
Når hurtigbufret, lønner ytelsespåvirkningen på innledende inntak seg senere, i samme dataflyt eller i en annen dataflyt i samme arbeidsområde.
Hvis du har en stor varighet for enheten, bør du vurdere å slå av databehandlingsmotoren. Hvis du vil bufre enheten, skriver Power BI den til lagring og SQL. Hvis det er en enhet for engangsbruk, kan det hende at ytelsesfordelen for brukere ikke er verdt straffen for dobbeltinntaket.
Foldet – Foldet betyr at dataflyten kunne bruke SQL-databehandling til å lese data. Den beregnede enheten brukte tabellen fra SQL til å lese data, og SQL-en som brukes, er relatert til konstruksjonene av spørringen.
Foldet status vises hvis du, når du bruker lokale datakilder eller skydatakilder, først lastet inn data i en oppsamlingsdataflyt og refererte til dette i denne dataflyten. Denne statusen gjelder bare for enheter som refererer til en annen enhet. Det betyr at spørringene ble kjørt oppå SQL-motoren, og de har potensial til å bli forbedret med SQL-databehandling. Hvis du vil sikre at SQL-motoren behandler transformasjonene dine, bruker du transformasjoner som støtter SQL-folding, for eksempel fletting (sammenføyning), grupper etter (aggregasjon) og tilføyingshandlinger (union) i Power Query-redigering.
Bufret + Foldet - Når du ser bufret + brettet, er det sannsynlig at dataoppdateringen er optimalisert, da du har en enhet som både refererer til en annen enhet og refereres til av en annen enhet oppstrøms. Denne operasjonen kjører også på toppen av SQL, og har som sådan også potensialet for forbedring med SQL-databehandling. Hvis du vil være sikker på at du får best mulig ytelse, kan du bruke transformasjoner som støtter SQL-folding, for eksempel fletting (sammenføyning), grupper etter (aggregasjon) og tilføyingshandlinger (union) i Power Query-redigering.
Veiledning for optimalisering av databehandlingsmotorytelse
Følgende trinn gjør det mulig for arbeidsbelastninger å utløse databehandlingsmotoren, og dermed alltid forbedre ytelsen.
Beregnede og koblede enheter i samme arbeidsområde:
For inntak kan du fokusere på å få dataene inn i lagringen så raskt som mulig, bare bruke filtre hvis de reduserer den totale semantiske modellstørrelsen. Hold transformasjonslogikken atskilt fra dette trinnet. Deretter skiller du transformasjonen og forretningslogikken i en egen dataflyt i samme arbeidsområde. Bruk koblede eller beregnede enheter. Dette gjør det mulig for motoren å aktivere og akselerere beregningene dine. For en enkel analogi er det som matlaging på et kjøkken: matlaging er vanligvis et separat og distinkt skritt fra å samle råingrediensene dine, og en forutsetning for å sette maten i ovnen. På samme måte må du klargjøre logikken separat før den kan dra nytte av databehandlingsmotoren.
Sørg for at du utfører operasjonene som brettes, for eksempel flettinger, sammenføyninger, konvertering og andre.
Bygg også dataflyter innenfor publiserte retningslinjer og begrensninger.
Når databehandlingsmotoren er på, men ytelsen er treg:
Gjør følgende når du undersøker scenarier der databehandlingsmotoren er på, men du ser dårlig ytelse:
- Begrens beregnede og koblede enheter som finnes på tvers av arbeidsområdet.
- Hvis den første oppdateringen er med databehandlingsmotoren aktivert, blir data skrevet i innsjøen og i hurtigbufferen. Denne dobbeltskrivingen fører til at oppdateringer blir tregere.
- Hvis du har en dataflyt som kobler til flere dataflyter, må du kontrollere at du planlegger oppdateringer av kildedataflytene slik at de ikke alle oppdateres samtidig.
Hensyn og begrensninger
En Power BI Pro-lisens har en oppdateringsgrense for dataflyter på åtte oppdateringer per dag.