Evaluere og optimalisere Microsoft Fabric-kapasiteten
Denne artikkelen forklarer hvordan du evaluerer og optimaliserer belastningen på Microsoft Fabric-kapasitetene dine. Den beskriver også strategier for å håndtere overbelastningssituasjoner, og gir deg veiledning for å optimalisere databehandling for hver av stoffopplevelsene.
Selv om fabric-kapasitetsmodellen forenkler oppsettet og muliggjør samarbeid, er det stor sjanse for å tømme de delte databehandlingsressursene for en kapasitet. Det kan også være tilfelle at du betaler for flere ressurser enn det som er nødvendig. Disse situasjonene kan oppstå når utformingen av noen stoffopplevelser ikke følger anbefalte fremgangsmåter.
Det er viktig å redusere risikoen for å tømme delte ressurser, Fabric , som en administrert tjeneste - automatisk adresserer slike situasjoner på to måter.
- Sprengning og utjevning sikrer at CPU-intensive aktiviteter fullføres raskt uten å kreve en høyere SKU (og kan kjøres når som helst på dagen).
- Begrensning av forsinkelser eller avviser operasjoner når en kapasitet opplever vedvarende og høy etterspørsel etter CPU (over SKU-grensen).
Utjevning reduserer sannsynligheten for begrensning (selv om begrensning fortsatt kan forekomme). Utjevning er hvordan bruk tildeles mot grenser, men det er uavhengig av utførelsen av jobber. Utjevning endrer ikke ytelsen, den sprer bare regnskapet for forbrukt databehandling over en lengre periode, slik at en større SKU ikke er nødvendig for å håndtere toppberegningen.
Hvis du vil vite mer om Fabric-kapasitet, kan du se Microsoft Fabric-konsepter og -lisenser og stoffkapasiteter – alt du trenger å vite om hva som er nytt og hva som kommer.
Det kan være en utfordring å planlegge størrelsen på en kapasitet. Det er fordi den nødvendige beregningen kan variere mye på grunn av operasjonene som utføres, hvor godt de utføres (for eksempel effektiviteten til en DAX-spørring eller Python-koden i en notatblokk), eller nivået på samtidighet.
Hvis du vil hjelpe deg med å finne riktig kapasitetsstørrelse, kan du klargjøre prøveversjonskapasiteter eller betal-etter-bruk F-SKU-er for å måle den faktiske kapasitetsstørrelsen som kreves før du kjøper en F SKU-reservert forekomst.
Tips
Det er alltid en god strategi å starte i det små og deretter gradvis øke størrelsen på kapasiteten etter behov.
Du bør overvåke utnyttelsen for å få mest mulig ut av kapasitetene dine. Det er først og fremst viktig å forstå at stoffoperasjoner enten er interaktive eller bakgrunner. DAX-spørringer fra en Power BI-rapport er for eksempel behovsbetingede forespørsler som er interaktive operasjoner, mens semantiske modelloppdateringer er bakgrunnsoperasjoner. Hvis du vil ha mer informasjon om operasjoner og hvordan de bruker ressurser i Fabric, kan du se Stoffoperasjoner.
Overvåking kan vise deg at begrensning finner sted. Begrensning kan skje når det er mange eller langvarige interaktive operasjoner. Vanligvis blir bakgrunnsoperasjoner relatert til SQL- og Spark-opplevelser jevnet ut, noe som betyr at de er spredt over en 24-timers periode.
Måledataappen for stoffkapasitet er den beste måten å overvåke og visualisere nylig utnyttelse på. Appen bryter ned til elementtype (semantisk modell, notatblokk, datasamlebånd og andre), og hjelper deg med å identifisere elementer eller operasjoner som bruker høye databehandlingsnivåer (slik at de kan optimaliseres).
Administratorer kan bruke administratorovervåkingsarbeidsområdet til å lære om ofte brukte elementer (og generell innføring). De kan også bruke overvåkingshuben til å vise gjeldende og nylige aktiviteter i leieren. Mer informasjon om enkelte operasjoner kan også være tilgjengelig fra Log Analytics eller de lokale datagatewayloggene.
Når en kapasitet er svært utnyttet og begynner å vise begrensning eller avvisning, finnes det tre strategier for å løse den: optimalisere, skalere opp og skalere ut.
Det er en god praksis å konfigurere varsler for å lære når kapasitetsutnyttelsen overskrider en angitt terskel. Vurder også å bruke arbeidsbelastningsspesifikke innstillinger for å begrense størrelsen på operasjoner (for eksempel tidsavbrudd for Power BI-spørring eller radgrenser eller innstillinger for Spark-arbeidsområdet).
Innholdsopprettere bør alltid optimalisere utformingen av stoffelementene sine for å sikre at det er effektivt og bruker minst mulig databehandlingsressurser. Spesifikk veiledning for hver stoffopplevelse gis senere i denne artikkelen.
Du skalerer en kapasitet for midlertidig eller permanent å øke SKU-størrelsen (med mer databehandlingskapasitet). Oppskalering sikrer at det er tilstrekkelige databehandlingsressurser tilgjengelig for alle elementer på en kapasitet og for å unngå begrensning.
Du kan også endre størrelse på, stanse midlertidig og gjenoppta FKU-er for stoff for å justere med forbruksmønstre.
Du skalerer ut ved å flytte noen av arbeidsområdene eller elementene til en annen stoffkapasitet for å spre arbeidsbelastningen. Det kan være et godt alternativ når ulike kapasitetsstrategier, innstillinger eller administratorer kreves. Klargjøring av flere kapasiteter er også en god strategi for å isolere databehandling for elementer med høy prioritet, og også for selvbetjent eller utviklingsinnhold. Lederne i organisasjonen forventer for eksempel svært responsive rapporter og instrumentbord. Disse rapportene og instrumentbordene kan ligge i en egen kapasitet dedikert til lederrapportering.
Du kan også vurdere å flytte Power BI-arbeidsområder til delt kapasitet, forutsatt at forbrukere har Power BI Pro-lisenser som lar dem fortsette å få tilgang til innholdet.
surge-beskyttelse bidrar til å begrense overforbruk av kapasiteten ved å begrense den totale mengden databehandlingsbakgrunnsjobber som forbruker. Dette reduserer total databehandling, slik at interaktive forsinkelser eller avvisninger er mindre sannsynlige. Det hjelper også kapasiteten med å komme seg raskere hvis det er en periode med begrensninger eller avvisninger. Du konfigurerer overspenningsbeskyttelse for hver kapasitet. Overspenningsvern bidrar til å forhindre begrensninger og avslag, men er ikke en erstatning for kapasitetsoptimalisering, oppskalering og skalering.
Når overspenningsbeskyttelse er aktiv, blir bakgrunnsjobber avvist. Dette betyr at det har innvirkning på kapasiteten din selv når overspenningsbeskyttelse er aktivert. Ved å bruke overspenningsbeskyttelse justerer du kapasiteten for å holde deg innenfor et område av bruk som best balanserer databehandlingsbehov innenfor kapasiteten. Hvis du vil beskytte kritiske løsninger fullt ut, anbefales det å isolere dem i en kapasitet med riktig størrelse.
Opplevelsene og elementene i Fabric fungerer annerledes, slik at du ikke nødvendigvis optimaliserer dem på samme måte. Denne delen viser stoffelementer etter erfaring, og handlinger du kan utføre for å optimalisere dem.
Fabric Data Warehouse
Datalageret bruker en serverløs arkitektur, og nodene administreres automatisk av tjenesten. Kapasitetsbruk beregnes basert på aktive kapasitetsenheter per spørring sekunder i stedet for hvor lang tid frontend- og backend-nodene er klargjort.
Alle datalageroperasjoner er bakgrunnsoperasjoner, og de blir jevnet ut over en 24-timers periode.
Sql Analytics-endepunktet har som mål å gi en ytelse som standardopplevelse . For dette formål er det færre alternativer for spørringsjustering som er tilgjengelige sammenlignet med SQL Server eller Azure Synapse Analytics dedikerte SQL-utvalg.
Her er noen punkter du bør vurdere for å minimere databehandling.
- Skriv spørringer ved hjelp av den mest optimale T-SQL mulig. Når det er mulig, kan du begrense antall kolonner, beregninger, aggregasjoner og andre operasjoner som unødvendig kan øke bruken av spørringsressurser.
- Utform tabeller for å bruke de minste datatypene som er mulig. Valget av datatype kan ha stor innvirkning på spørringsplanene som genereres av SQL-motoren. Hvis du for eksempel reduserer et
VARCHARfelt fra lengde 500 til 25 eller endresDECIMAL(32, 8)til, kan det føre tilDECIMAL(10, 2)en betydelig reduksjon i ressurser som er tildelt en spørring. - Bruk utforming av stjerneskjema til å redusere antall rader som leses og minimere spørringskoblinger.
- Sørg for at statistikken finnes og at de er oppdaterte. Statistikk spiller en viktig rolle i genereringen av den mest optimale utførelsesplanen. De opprettes automatisk under kjøring, men du må kanskje oppdatere dem manuelt, spesielt etter at dataene er lastet inn eller oppdatert. Vurder å opprette statistikk ved hjelp
FULLSCANav alternativet i stedet for å stole på den automatisk genererte statistikken som bruker sampling. - Bruk innebygde visninger til å overvåke spørringer og bruk, spesielt når du feilsøker problemer.
- Den sys.dm_exec_requests dynamiske administrasjonsvisningen (DMV) gir informasjon om alle aktivt kjørende spørringer, men den lagrer ingen historisk informasjon. Stoffverktøykassen inneholder en spørring som bruker denne DMV-en, og gjør spørringsresultatet brukervennlig ved å koble til andre visninger for å gi detaljer som spørringsteksten.
- Spørringsinnsikt, som er en funksjon i datalager for stoff, gir en helhetlig visning av historisk spørringsaktivitet på endepunktet for SQL-analyse. Spesielt gir queryinsights.exec_requests_history-visningen informasjon om hver fullstendige SQL-forespørsel. Den presenterer alle relevante detaljer for hver spørringskjøring som kan korreleres med operasjons-ID-ene som finnes i måledataappen for kapasitet. De viktigste kolonnene for overvåking av kapasitetsbruk er: distributed_statement_id, kommando (spørringstekst), start_time og end_time.
De Dataingeniør- og Data Science-opplevelsene bruker Spark-databehandling til å behandle, analysere og lagre data i et Fabric Lakehouse. Spark-databehandling er konfigurert og målt i form av vCores. Fabric bruker imidlertid CUs som et mål på databehandling som forbrukes av ulike elementer, inkludert Spark-notatblokker, Spark-jobbdefinisjoner og lakehouse-jobber.
I Spark oversettes én CU til to spark vCores av databehandling. Når en kunde for eksempel kjøper en F64 SKU, er 128 spark v-kjerner tilgjengelige for Spark-opplevelser.
Alle Spark-operasjoner er bakgrunnsoperasjoner, og de er jevnet ut over en 24-timers periode.
Hvis du vil ha mer informasjon, kan du se Fakturering og bruksrapportering i Fabric Spark.
Her er noen punkter du bør vurdere for å minimere databehandling.
- Prøv alltid å skrive effektiv Spark-kode. Hvis du vil ha mer informasjon, kan du se Optimalisere Apache Spark-jobber i Azure Synapse Analytics og Behovet for optimalisering av skriving på Apache Spark.
- Reserver nødvendige eksekutorer for Spark-jobbene dine for å frigjøre ressurser for andre Spark-jobber eller -arbeidsbelastninger. Ellers øker du sjansen for at Spark-jobber mislykkes med en HTTP 430-status, noe som betyr for mange forespørsler om kapasiteten. Du kan vise antallet eksekutorer som er tilordnet til en notatblokk i stoffovervåkingshuben, der du også kan bestemme det faktiske antallet eksekutorer som brukes av notatblokken. Spark-jobber reserverer bare de nødvendige nodene og tillater parallelle innsendinger innenfor SKU-grenser.
- Spark-utvalget kan bare konfigureres til å bruke maksimalt antall vCores som støttes av SKU-en. Du kan imidlertid skalere ut datatekniske arbeidsbelastninger ved å godta parallelle Spark-jobber innenfor SKU-grenser. Denne tilnærmingen kalles ofte burst-faktor, og den aktiveres som standard for Spark-arbeidsbelastninger på kapasitetsnivå. Hvis du vil ha mer informasjon, kan du se Samtidighetsbegrensning og kø.
- Aktive Spark-økter kan påløpe CU-utnyttelse på en kapasitet. Derfor er det viktig å stoppe aktive Spark-økter når de ikke er i bruk. Vær oppmerksom på at standard utløpstid for Spark-økt er satt til 20 minutter. Brukere kan endre tidsavbruddet for økten i en notatblokk eller spark-jobbdefinisjonen.
CU-forbruk for KQL-database beregnes basert på antall sekunder databasen er aktiv og antallet vCores som brukes. Når databasen for eksempel bruker fire vCores og er aktiv i 10 minutter, bruker du 2400 (4 x 10 x 60) sekunder med CU.
Alle KQL-databaseoperasjoner er interaktive operasjoner.
En autoskalamekanisme brukes til å bestemme størrelsen på KQL-databasen. Den sikrer at den mest kostnadsoptimaliserte og beste ytelsen oppnås basert på bruksmønstre.
Hvis du vil tillate at data blir tilgjengelige for andre Fabric-motorer, synkroniseres KQL-databasen med OneLake. Basert på antall lese- og skrivetransaksjoner som KQL-databasen utfører, brukes CUs fra kapasiteten din. Den benytter OneLake Read and Write-målere, som tilsvarer lese- og skriveoperasjoner på Azure Data Lake Storage (ADLS) Gen2-kontoer.
Denne delen handler om optimaliseringer for dataflyter og datasamlebånd i Data Factory.
Alle operasjoner er bakgrunnsoperasjoner, og de blir jevnet ut over en 24-timers periode.
Her er noen punkter du bør vurdere for å minimere databehandling.
- Unngå ineffektiv Power Query-logikk for å minimere og optimalisere dyre datatransformasjoner, for eksempel fletting og sortering.
- Prøv å oppnå spørringsdelegering når det er mulig. Det kan forbedre ytelsen til dataflytene ved å redusere mengden data som må overføres mellom datakilden og målet. Når spørringsdelegering ikke forekommer, henter Power Query alle dataene fra datakilden og utfører transformasjoner lokalt, noe som kan være ineffektivt og tregt.
- Deaktiver oppsamling når du arbeider med små datavolumer og/eller utfører enkle transformasjoner. Oppsamling kan være nødvendig i noen tilfeller, for eksempel når du laster inn et datalager.
- Unngå å oppdatere data oftere enn datakilden krever. Hvis datakilden for eksempel bare oppdateres én gang hver 24. time, gir ikke oppdatering av dataene hver time mer verdi. Vurder i stedet å oppdatere dataene med riktig frekvens for å sikre at de er oppdaterte og nøyaktige.
Power BI-operasjoner er enten interaktive eller bakgrunner.
Følgende interaktive operasjoner resulterer vanligvis i høy databehandlingsbruk.
- Semantiske modeller som ikke følger anbefalte fremgangsmåter. De kan for eksempel ikke ta i bruk stjerneskjemautforming med én-til-mange-relasjoner. Eller de kan inkludere komplekse og dyre sikkerhetsfiltre på radnivå (RLS). Vurder å bruke Tabellredigering og Beste praksisanalyse for å finne ut om anbefalte fremgangsmåter følges.
- DAX-mål er ineffektive.
- Rapportsider inneholder for mange visualobjekter, noe som kan føre til treg visuell oppdatering.
- Rapportvisualobjekter viser resultater med høy kardinalitet (for mange rader eller kolonner), eller de inneholder for mange mål.
- Kapasiteten opplever høy samtidighet fordi det er for mange brukere for kapasitetsstørrelsen. Vurder å aktivere spørringsskala for å forbedre brukeropplevelsen for semantiske modeller med høy samtidighet (men det resulterer ikke i mer total databehandling).
Følgende bakgrunnsoperasjoner resulterer vanligvis i høy databehandlingsbruk.
- Ineffektive eller altfor komplekse datatransformasjoner i Power Query-logikken.
- Fravær av spørringsdelegering eller trinnvis oppdatering for store faktatabeller.
- Rapportsprengning, som er når et høyt antall Power BI-rapporter eller paginerte rapporter genereres samtidig.
- Konsepter og lisenser for Microsoft Fabric
- Blogg: Stoffkapasitet – alt du trenger å vite om hva som er nytt og hva som kommer
Har du flere spørsmål? Prøv å spørre Fabric Community.