Ytelsesretningslinjer i Fabric datalager

Gjelder for:✅ Warehouse i Microsoft Fabric

Denne artikkelen inneholder anbefalte fremgangsmåter for datainntak, tabellbehandling, dataforberedelse, statistikk og spørring i lagre og SQL-analyseendepunkter. Ytelsesjustering og optimalisering kan by på unike utfordringer, men de tilbyr også verdifulle muligheter til å maksimere mulighetene til dataløsningene dine.

For å overvåke ytelsen på lageret ditt, se Monitor Fabric Data warehouse.

Spørringsytelse

statistikk

Statistikk er vedvarende objekter som representerer data i tabellens kolonner. Spørringsoptimalisering bruker statistikk til å velge og estimere kostnaden for en spørringsplan. Fabric datalager og Lakehouse SQL-analyseendepunkter bruker og vedlikeholder automatisk histogramstatistikk, gjennomsnittlig kolonnelengdestatistikk og tabellkardinalitetsstatistikk. For mer informasjon, se Statistics in Fabric datalager.

• KOMMANDOENE CREATE STATISTICS og UPDATE STATISTICS T-SQL støttes for histogramstatistikk med én kolonne. Du kan dra nytte av disse hvis det er et stort nok vindu mellom tabelltransformasjonene og arbeidsbelastningen for spørringen, for eksempel under et vedlikeholdsvindu eller annen nedetid. Denne tilnærmingen reduserer sannsynligheten for at spørringene dine SELECT først må oppdatere statistikken.
• Prøv å definere tabellskjema som opprettholder datatypeparitet i vanlige kolonnesammenligninger. For eksempel, hvis du vet at kolonner ofte sammenlignes med hverandre i en WHERE klausul, eller brukes som JOIN ... ON predikat, sørg for at datatypene stemmer overens. Hvis det ikke er mulig å bruke nøyaktig samme datatyper, bruk lignende datatyper kompatible for implisitt konvertering. Unngå eksplisitte datakonverteringer. Hvis du vil ha mer informasjon, kan du se Konvertering av datatype.

Når du filtrerer lakehouse-tabeller i tidsstempelkolonnen før Apache Spark runtime 3.5.0, genereres ikke radgruppenivåstatistikk for tidsstempelkolonner. Denne mangelen på statistikk gjør det vanskelig for systemer, for eksempel Fabric Warehouse, å bruke radgruppeeliminering (også kalt datahopp eller predikat pushdown), som er ytelsesoptimalisering som hopper over irrelevante radgrupper under kjøring av spørring. Uten denne statistikken kan det hende at filtreringsspørringer som involverer tidsstempelkolonner, må skanne flere data, noe som fører til betydelig ytelsesreduksjon. Du kan oppgradere Apache Spark runtime i Fabric. Apache Spark 3.5.0 og nyere versjoner kan generere radgruppenivåstatistikk for tidsstempelkolonner. Deretter må du gjenopprette tabellen og innta dataene for å få generert statistikk på radgruppenivå.

Ytelse for kald hurtigbuffer

first execution av en spørring i Fabric datalager kan være uventet tregere enn påfølgende kjøringer. Denne nedgangen kalles en kaldstart. En kaldstart skjer på grunn av systeminitialisering eller skaleringsaktiviteter som forbereder miljøet for behandling.

Kulde starter vanligvis når:

• Systemet laster data fra OneLake inn i minnet fordi spørringen får tilgang til data for første gang, og dataene er ennå ikke cachet.
• Systemet genererer automatisk nødvendige statistikker fordi spørringen får tilgang til data for første gang.
• Systemet pauser automatisk noder etter en periode med inaktivitet for å redusere kostnadene, og legger til noder som en del av autoskaleringen. Det tar vanligvis mindre enn ett sekund å gjenoppta eller opprette noder.

Disse operasjonene kan øke spørringsvarigheten. Kalde starter kan være delvis. Noen beregningsnoder, data eller statistikk kan allerede være tilgjengelige eller bufret i minnet, mens spørringen venter på at andre skal bli tilgjengelige.

Minne- og diskcaching i Fabric datalager er fullstendig transparent og automatisk aktivert. Caching minimerer behovet for lesing av fjern storage intelligent ved å utnytte lokale cacher. Fabric datalager benytter raffinerte access-mønstre for å forbedre datalesing fra storage og øke spørringshastigheten. Hvis du vil ha mer informasjon, kan du se Caching in Fabric data warehousing.

Du kan oppdage cold start-effekter forårsaket av å hente data fra fjern storage inn i minnet ved å spørre queryinsights.exec_requests_history-visningen. data_scanned_remote_storage_mb Kontroller kolonnen:

• En ikke-null verdi i data_scanned_remote_storage_mb indikerer kaldstart. Spørringskjøringen hentet data fra OneLake. Etterfølgende visninger bør være raskere i queryinsights.exec_requests_history.
• En nullverdi i data_scanned_remote_storage_mb er den perfekte tilstanden der alle dataene bufres. Ingen nodeendringer eller data fra OneLake var nødvendige for å levere spørringsresultatene.

Spørringer på tabeller med strengkolonner

Bruk den minste strengkolonnelengden som kan romme verdier. Fabric Warehouse blir stadig bedre; men du kan oppleve suboptimal ytelse hvis du bruker store strengdatatyper, spesielt store objekter (LOBs). For en customer_name kolonnes datatype bør du for eksempel vurdere forretningskrav og forventede data, og bruke en passende lengde n når du deklarerer varchar(n), for eksempel varchar(100), i stedet for varchar(8000) eller varchar(max). Statistikk og beregning av spørringskostnader er mer nøyaktige når datatypelengden er mer nøyaktig for de faktiske dataene.

• I Fabric datalager T-SQL, se veiledning for å velge riktig lengde for strengdatatyper.
• Tabellstrengkolonner i Lakehouse uten definert lengde i Spark gjenkjennes av Fabric Warehouse som varchar(8000). Hvis du vil ha optimal ytelse, kan du bruke CREATE TABLE setningen i SparkSQL til å definere strengkolonnen som varchar(n), der n er maksimal kolonnelengde som kan romme verdier.

Transaksjoner og samtidighet

Fabric datalager er bygget på en moderne, skybasert arkitektur som kombinerer transaksjonsintegritet, snapshot-isolasjon og distribuert beregning for å levere høy samtidighet og konsistens i stor skala. Hvis du vil ha mer informasjon, kan du se Transaksjoner i lagertabeller.

Fabric datalager støtter ACID-kompatible transaksjoner ved bruk av snapshot-isolasjon. Dette betyr:

• Lese- og skriveoperasjoner kan grupperes i én enkelt transaksjon ved hjelp av standard T-SQL (BEGIN TRANSACTION, COMMIT, ROLLBACK)
• Alt-eller-ingenting-semantikk: Hvis en transaksjon strekker seg over flere tabeller og én operasjon mislykkes, rulles hele transaksjonen tilbake.
• Les konsekvens: SELECT Spørringer i en transaksjon ser et konsekvent øyeblikksbilde av dataene, upåvirket av samtidige skrivinger.

Støtte for Fabric Warehouse-transaksjoner:

• Datadefinisjonsspråk (DDL) i transaksjoner: Du kan inkludere CREATE TABLE i en transaksjonsblokk.
• Transaksjoner på tvers av databaser: Støttes i samme arbeidsområde, inkludert lesing fra SQL Analytics-endepunkter.
• Parquet-basert tilbakerulling: Siden Fabric datalager lagrer data i uforanderlige Parquet-filer, er tilbakerullingene raske. Tilbakerullinger går ganske enkelt tilbake til tidligere filversjoner.
• Automatisk datakomprimering og sjekkpunkt: Datakomprimering optimaliserer storage- og leseytelsen ved å slå sammen små Parquet-filer og fjerne logisk slettede rader.
• Automatisk kontrollpunkt: Hver skriveoperasjon (INSERT, UPDATE, DELETE) tilføyer en ny JSON-loggfil til transaksjonsloggen for Delta Lake. Over tid kan dette resultere i hundrevis eller tusenvis av loggfiler, spesielt i strømming eller høyfrekvente inntaksscenarioer. Automatisk kontrollpunkt forbedrer effektiviteten for metadatalesing ved å oppsummere transaksjonslogger i én enkelt kontrollpunktfil. Uten kontrollpunkt må hver lese skanne hele transaksjonsloggloggloggen. Med sjekkpunkter er de eneste loggene som leses den siste sjekkpunktfilen og loggene etter den. Dette reduserer I/U og metadataanalyse drastisk, spesielt for store eller jevnlig oppdaterte tabeller.

Både komprimering og kontrollpunkt er avgjørende for tabelltilstand, spesielt i langvarige miljøer med høy samtidighet.

Samtidighetskontroll og isolasjon

Fabric datalager bruker utelukkende snapshot-isolasjon. Forsøk på å endre isolasjonsnivået via T-SQL ignoreres.

Anbefalte fremgangsmåter med transaksjoner

• Bruk eksplisitte transaksjoner klokt. Alltid COMMIT eller ROLLBACK. Ikke la transaksjonene være åpne.
  • Hold transaksjonene kortvarige. Unngå langvarige transaksjoner som holder låser unødvendig, spesielt for eksplisitte transaksjoner som inneholder DDLer. Dette kan føre til strid med SELECT setninger om systemkatalogvisninger (for eksempel sys.tables) og kan forårsake problemer med Fabric-portalen som er avhengig av systemkatalogvisninger.
• Legg til retry-logikk med forsinkelse i pipelines eller apper for å håndtere forbigående konflikter.
  • Bruk eksponentiell backoff for å unngå retry stormer som forverrer forbigående nettverksavbrudd.
  • For mer informasjon, se Retry pattern.
• Overvåk låser og konflikter i lageret.
  • Bruk sys.dm_tran_locks til å undersøke gjeldende låser.

Redusere returnerte datasettstørrelser

Spørringer med stor datastørrelse i mellomliggende spørringskjøring eller i det endelige spørringsresultatet kan oppleve mer problem med spørringsytelse. Hvis du vil redusere størrelsen på det returnerte datasettet, bør du vurdere følgende strategier:

• Partisjons- eller klyngetabeller (Liquid Clustering) store bord i Lakehouse.
• Begrens antallet kolonner som returneres. SELECT * kan være kostbart.
• Begrens antall rader som returneres. Utfør så mye datafiltrering på lageret som mulig, ikke i klientprogrammer.
  • Prøv å filtrere før du blir med for å redusere datasettet tidlig i kjøringen av spørringen.
  • Filtrer etter kolonner med lav kardinalitet for å redusere store datasett tidlig før JOIN-er.
  • Kolonner med høy kardinalitet er ideelle for filtrering og JOIN-er. Disse brukes ofte i WHERE setninger og drar nytte av at predikat brukes på tidligere stadium i spørringskjøring for å filtrere ut data.
• I Fabric datalager, siden primærnøkkel- og unike nøkkelbegrensninger ikke håndheves, er kolonner med disse begrensningene ikke nødvendigvis gode kandidater for JOINs.

Spørringsplaner og spørringstips

I Fabric datalager genererer spørringsoptimalisatoren en spørringsutførelsesplan for å finne den mest effektive måten å utføre en SQL-spørring på. Avanserte brukere kan vurdere å undersøke problemer med spørringsytelsen med spørringsplanen eller ved å legge til spørringstips.

• Brukere kan bruke SHOWPLAN_XML i SQL Server Management Studio for å se planen uten å utføre spørringen.
• Valgfrie spørringstips kan legges til i en SQL-setning for å gi flere instruksjoner til spørringsoptimalisering før plangenerering. Å legge til spørringstips krever avansert kunnskap om spørringsarbeidsbelastninger, og brukes derfor vanligvis etter at andre anbefalte fremgangsmåter er implementert, men problemet vedvarer.

Ikke-skalerbare operasjoner

Fabric datalager er bygget på en massivt parallell prosesseringsarkitektur (MPP), hvor spørringer utføres på tvers av flere beregningsnoder. I enkelte scenarioer er kjøring av enkeltnode blokkjustert:

• Hele kjøringen av spørringsplanen krever bare én databehandlingsnode.
• Et planundertre kan passe innenfor én databehandlingsnode.
• Hele spørringen eller delen av spørringen må kjøres på én enkelt node for å tilfredsstille spørringssemantikken. For eksempel operasjoner TOP , global sortering, spørringer som krever sorteringsresultater fra parallelle kjøringer for å gi ett enkelt resultat, eller sammenføyning av resultater for det siste trinnet.

I slike tilfeller kan brukere motta en advarsel om at én eller flere ikke-skalerbare operasjoner oppdages, og spørringen kan kjøre sakte eller mislykkes etter en lang kjøring.

• Vurder å redusere størrelsen på spørringens filtrerte datasett.
• Hvis spørringssemantikken ikke krever kjøring av enkeltnode, kan du prøve å fremtvinge en distribuert spørringsplan med FORCE DISTRIBUTED PLAN, for eksempel OPTION (FORCE DISTRIBUTED PLAN);.

Spør endepunktet for SQL-analyse

Du kan bruke SQL Analytics-endepunktet til å spørre Lakehouse-tabeller som ble fylt ut med Spark SQL, uten å kopiere eller innta data til lageret.

Følgende anbefalte fremgangsmåter gjelder for spørring av lagerdata i Lakehouse via SQL Analytics-endepunktet. Hvis du vil ha mer informasjon om sql analytics-endepunktytelse, kan du se ytelsesvurderinger for SQL Analytics-endepunktet.

Utfør regelmessig tabellvedlikehold for Lakehouse-tabeller

I Microsoft Fabric optimaliserer Warehouse automatisk dataoppsett, og utfører søppelrydding og kompaktering. For en Lakehouse har du mer kontroll over bordvedlikehold. Tabelloptimalisering og støvsuging er nødvendig og kan redusere skannetiden som kreves for store datasett betydelig. Tabellvedlikehold i Lakehouse strekker seg også til snarveier og kan hjelpe deg med å forbedre ytelsen der betydelig.

Optimalisere lakehouse-tabeller eller snarveier med mange små filer

Det å ha mange små filer oppretter overhead for å lese filmetadata. Bruk OPTIMALISER-kommandoen i Stoff-portalen eller en notatblokk til å kombinere små filer til større filer. Gjenta denne prosessen når antall filer endres betraktelig.

• For å optimalisere et bord manuelt i en Fabric Lakehouse, åpne Lakehouse i Fabric-portalen. I Utforsker, høyreklikk på tabellen og velg Vedlikehold. Velg alternativer fra siden Kjør vedlikeholdskommandoer , og velg deretter Kjør nå.
• For å optimalisere tabeller som trenger vedlikehold intelligent, bruk en datapipeline og T-SQL-lagret sys.sp_get_table_health_metrics prosedyre for å avgjøre når en tabell trenger kommandoen OPTIMIZE . For en veiledning, se Optimaliser Lakehouse-tabeller basert på helsesjekker.

Spørring av lakehouse-tabeller eller snarveier i samme område

Stoffet bruker databehandling der Fabric-kapasiteten er plassert. Å spørre data, for eksempel i din egen Azure Data Lake Storage eller i OneLake, i en annen region, resulterer i ytelsesbelastning på grunn av nettverksforsinkelse. Kontroller at dataene er i samme område. Vurder å beholde bare små tabeller som dimensjonstabeller i et eksternt område, avhengig av ytelseskravene.

Filtrere lakehouse-tabeller og snarveier i de samme kolonnene

Hvis du ofte filtrerer tabellrader på bestemte kolonner, bør du vurdere å partisjonere tabellen.

Partisjonering fungerer bra for kolonner med lav kardinalitet eller kolonner med forutsigbar kardinalitet, for eksempel år eller datoer. Hvis du vil ha mer informasjon, kan du se Opplæring i Lakehouse – Klargjøre og transformere lakehouse-data og laste inn data til Lakehouse ved hjelp av partisjon.

Gruppering fungerer bra for kolonner med høy selektivitet. Hvis du har andre kolonner som du ofte bruker til filtrering, bortsett fra partisjonering av kolonner, bør du vurdere å gruppere tabellen ved hjelp av optimalisering med Spark SQL-syntaksen ZORDER BY. Hvis du vil ha mer informasjon, kan du se Tabelloptimalisering for Delta Lake.

Dataklynging

Du kan også utføre dataklynging på spesifikke kolonner i CREATE TABLE og CREATE TABLE AS SELECT (CTAS) T-SQL-setningene. Dataklynging fungerer ved å lagre rader med lignende verdier på tilstøtende steder på storage under inntaket.

• Dataklynging bruker en romutfyllende kurve for å organisere data på en måte som bevarer lokalitet over flere dimensjoner, noe som betyr at rader med lignende verdier over klyngingskolonner lagres fysisk tett sammen. Denne tilnærmingen forbedrer spørringsytelsen dramatisk ved å utføre filhopp og redusere antall filer som skannes.
• Dataklyngemetadata er innebygd i manifestet under inntasting, noe som gjør at warehouse-motoren kan ta intelligente beslutninger om hvilke filer som skal access under brukerhenvendelser. Denne metadataen, kombinert med hvordan rader med lignende verdier lagres sammen, sikrer at spørringer med filterpredikater kan hoppe over hele filer og radgrupper som faller utenfor predikatets omfang.

For eksempel: hvis en spørring kun retter seg mot 10% av en tabells data, sikrer klynging at kun filer som inneholder dataene innenfor filterets område blir skannet, noe som reduserer I/O- og databehandlingsforbruk. Større tabeller drar mer nytte av dataklynging, ettersom fordelene med filhopp øker med datavolumet.

• For fullstendig informasjon om dataklynging, se Dataklynging i Fabric datalager.
• For en veiledning om dataklynging og hvordan man måler dens positive effekt på ytelse, se Bruk dataklynging i Fabric datalager.

Optimalisering av datatype

Å velge riktige datatyper er essensielt for ytelse og storage-effektivitet i lageret ditt. Følgende retningslinjer bidrar til å sikre at skjemadesignet ditt støtter raske spørringer, effektiv storage og vedlikeholdbarhet.

For mer informasjon om datatyper støttet av Fabric datalager, se Datatyper i Fabric datalager.

Sammenligne datatyper med datasemantikk

For å sikre både clarity og ytelse er det viktig å tilpasse hver kolonnes datatype til den faktiske naturen og oppførselen til dataene den lagrer.

• Bruk dato, klokkeslett eller datetime2(n) for tidsmessige verdier i stedet for å lagre dem som strenger.
• Bruk heltallstyper for numeriske verdier, med mindre formatering (for eksempel foranstilte nuller) er nødvendig.
• Bruk tegntyper (tegn, varchar) når du beholder formatering er viktig (for eksempel tall som kan begynne med null, produktkoder, tall med bindestreker).

Bruk heltallstyper for heltall

Når du lagrer verdier som identifikatorer, tellere eller andre heltall, foretrekker du heltallstyper (smallint, int, bigint) over desimaltall/. Heltallstyper krever mindre storage enn datatyper som tillater sifre til høyre for desimalpunktet. Som et resultat tillater de raskere aritmetiske operasjoner og sammenligningsoperasjoner og forbedrer indeksering og spørringsytelse.

Vær oppmerksom på verdiområdene for hver heltallsdatatype som støttes av Fabric datalager. Hvis du vil ha mer informasjon, int, bigint, smallint (Transact-SQL).

Vurder bruk av desimal og numerisk presisjon og skalering

Hvis du må bruke desimaltall/, velger du den minste presisjonen og skalaen som har plass til dataene, når du oppretter kolonnen. Overprovisjonspresisjon øker behovet for storage og kan forringe ytelsen etter hvert som dataene vokser.

• Forutse lagerets forventede vekst og behov. For eksempel, hvis du planlegger å lagre maksimalt fire sifre til høyre for desimalpunktet, bruk desimal(9,4) eller desimal(19,4) for mest effektive storage.
• Angi alltid presisjon og skalering når du oppretter endesimaltallkolonne/. Når den opprettes i en tabell som er definert som bare decimal, uten å angi (p,s), opprettes en desimaltallkolonne/ somdecimal(18,0). En desimal med en presisjon på 18 bruker 9 byte storage per rad. En skala 0 som ikke lagrer data til høyre for desimaltegnet. For mange bedriftstall er smallint, int, bigint mye mer effektive enn decimal(18,0). For eksempel kan ethvert ni-sifret heltall lagres som en heltall datatype for 4 byte storage per rad.

Hvis du vil ha fullstendig informasjon, kan du se desimaltall og numerisk (Transact-SQL).

Vurder når du skal bruke varchar over char

Bruk varchar(n) i stedet for tegn(n) for strengkolonner, med mindre utfylling med fast lengde er eksplisitt nødvendig. En varchar-kolonne lagrer bare den faktiske strenglengden per rad, pluss en liten overhead, og reduserer bortkastet plass, noe som forbedrer I/U-effektiviteten.

• Bruk varchar(n) for verdier som navn, adresser og beskrivelser, da de har mye variable verdier. Statistikk og beregning av spørringskostnader er mer nøyaktige når datatypelengden er mer nøyaktig for de faktiske dataene.
• Bruk tegn(n) når du vet at strengen vil være en fast lengde hver gang. Det er for eksempel fornuftig å lagre strengen 000000000 som et tegn(9) hvis strengen alltid består av nøyaktig 9 numeriske tegn som kan starte med en null.
• Lengden n i kolonnens datatypedeklarasjon er de storage bytene. For multibyte-kodingstegnsett som UTF-8, kodingen for Fabric datalager, tar latinske tegn og tall 1 byte storage. Det finnes imidlertid Unicode-tegn som krever mer enn 1 byte, for eksempel japanske tegn som krever tre byte for lagring, slik at antall Unicode-tegn som faktisk er lagret, kan være mindre enn datatypelengden n. Hvis du vil ha mer informasjon, kan du se tegn- og varchar-argumenter.

Unngå kolonner som kan nullstilles når det er mulig

Definer kolonner som NOT NULL når datamodellen tillater det. Som standard tillater NULL en kolonne i en tabell verdier. Kolonner som kan nullstilles, har følgende egenskaper:

• De legger til metadata overhead.
• Kan redusere effektiviteten av spørringsoptimaliseringer og statistikk.
• Kan påvirke ytelsen i analysespørringer i stor skala.

Datainntak og forberedelse til et lager

KOPIER INN

Kommandoen T-SQL COPY INTO er den anbefalte måten å importere data fra Azure Data Lake Storage inn i Fabric datalager. Hvis du vil ha mer informasjon og eksempler, kan du se Inntak av data i lageret ved hjelp av COPY-setningen.

Vurder følgende anbefalinger for best ytelse:

• Filstørrelse: Sørg for at hver fil du inntar er ideelt mellom 100 MB og 1 GB for maksimert gjennomstrømming. Dette bidrar til å optimalisere inntaksprosessen og forbedre ytelsen.
• Antall filer: For å maksimere parallellitet og spørringsytelse, kan du ta sikte på å generere et høyt antall filer. Prioriter oppretting av så mange filer som mulig, samtidig som du opprettholder en minimumsfilstørrelse på 100 MB.
• Parallell innlasting: Bruk flere COPY INTO setninger som kjører parallelt for å laste inn data i forskjellige tabeller. Denne tilnærmingen kan redusere ETL/ELT-vinduet betydelig på grunn av parallellitet.
• Kapasitetsstørrelse: For større datavolumer bør du vurdere å skalere ut til større stoffkapasitet for å få de ekstra databehandlingsressursene som trengs for å imøtekomme flere parallelle prosesseringer og større datavolumer.

Fabric datalager støtter også BULK INSERT-setningen som er et synonym for COPY INTO. Den samme anbefalingen gjelder for BULK INSERT setningen.

CTAS eller INSERT

Bruk CREATE TABLE AS SELECT (CTAS) eller INSERT kombinert med SELECT FROM Lakehouse-tabell-/snarveikommandoer. Disse metodene kan være mer effektive og effektive enn å bruke pipelines, noe som tillater raskere og mer pålitelige dataoverføringer. Hvis du vil ha mer informasjon og eksempler, kan du se Inntak av data i lageret ved hjelp av Transact-SQL.

Konseptet med å øke antall parallelliteter og skalering til større stoffkapasitet gjelder også for CTAS/INSERT-operasjoner for å øke gjennomstrømmingen.

Les data fra Azure Data Lake Storage eller Blob Storage med OPENROWSET

Funksjonen OPENROWSET gjør det mulig å lese CSV- eller Parquet-filer fra Azure Data Lake eller Azure Blob storage, uten å sende dem til Warehouse. Hvis du vil ha mer informasjon og eksempler, kan du se Bla gjennom filinnhold ved hjelp av OPENROWSET-funksjonen.

For mer informasjon og eksempler på å spørre eksterne data, se Søk i eksterne data lake-filer ved å bruke Fabric datalager eller SQL analytics endpoint.

Når du leser data ved hjelp av OPENROWSET-funksjonen, bør du vurdere følgende anbefalinger for best ytelse:

• Parkett: Prøv å bruke Parquet i stedet for CSV, eller konverter CSV til Parquet, hvis du ofte spør etter filene. Parquet er et kolonneformat. Fordi dataene er komprimert, er filstørrelsene mindre enn CSV-filer som inneholder de samme dataene. Fabric datalager hopper over kolonner og rader som ikke trengs i en spørring hvis du leser Parquet-filer.
• Filstørrelse: Sørg for at hver fil du inntar er ideelt mellom 100 MB og 1 GB for maksimert gjennomstrømming. Dette bidrar til å optimalisere inntaksprosessen og forbedre ytelsen. Det er bedre å ha like store filer.
• Antall filer: For å maksimere parallellitet og spørringsytelse, kan du ta sikte på å generere et høyt antall filer. Prioriter oppretting av så mange filer som mulig, samtidig som du opprettholder en minimumsfilstørrelse på 100 MB.
• Deling: Partisjoner dataene ved å lagre partisjoner i forskjellige mapper eller filnavn hvis arbeidsbelastningen filtrerer dem etter partisjonskolonner.
• Vurdering: Prøv å angi ROWS_PER_BATCH at det skal samsvare med antall rader i de underliggende filene hvis du føler at du ikke får forventet ytelse.
• Kapasitetsstørrelse: For større datavolumer bør du vurdere å skalere ut til større SKU for å få mer databehandlingsressurser som trengs for å imøtekomme ekstra antall parallellbehandling og større datavolumer.

Unngå trickle-innsettinger, oppdateringer og slettinger

For å sikre effektiv filoppsett og optimal spørringsytelse i Fabric datalager, unngå å bruke mange små transaksjoner INSERT, UPDATE og DELETE. Disse endringene på radnivå genererer en ny parquetfil for hver operasjon, noe som resulterer i et stort antall små filer og fragmenterte radgrupper. Denne fragmenteringen fører til:

• Økt ventetid for spørring på grunn av ineffektiv filskanning.
• Høyere storage- og beregningskostnader.
• Større avhengighet av bakgrunnskomprimeringsprosesser.

Anbefalte tilnærminger:

• Batch-transaksjoner som skrives inn i Fabric datalager.
  • For eksempel, i stedet for mange små INSERT setninger, forhåndsfasedata sammen og sett inn data i én INSERT setning.
• Bruk COPY INTO for masseinnlegg og utfør oppdateringer og slettinger i grupper når det er mulig.
• Opprettholde en minimum importert filstørrelse på 100 MB for å sikre effektiv radgruppedannelse.
• Hvis du vil ha mer veiledning og anbefalte fremgangsmåter for datainntak, kan du se Anbefalte fremgangsmåter for å innta data i et lager.

Datakomprimering

I Fabric datalager er datakomprimering en bakgrunnsoptimaliseringsprosess som slår sammen små, ineffektive Parquet-filer med færre, større filer. Ofte opprettes disse filene av hyppig trickle INSERTeller UPDATEDELETE operasjoner. Datakomprimering reduserer filfragmisering, forbedrer radgruppeeffektiviteten og forbedrer den generelle spørringsytelsen.

Selv om Fabric datalager-motoren automatisk løser fragmentering over tid gjennom datakomprimering, kan ytelsen forverres til prosessen er fullført. Datakomprimering kjører automatisk uten brukerinngripen for Fabric datalager.

Datakomprimering gjelder ikke for Lakehouse. For Lakehouse-tabeller som nås via SQL-analyseendepunkter, er det viktig å følge Lakehouse beste praksis og manuelt kjøre kommandoen OPTIMIZE etter betydelige dataendringer for å opprettholde optimal storage layout.

Forkjøpsrett for datapakking

Fabric datalager unngår intelligent og aktivt skrivekonflikter mellom bakgrunnskomprimeringsoppgaver og brukeroperasjoner. Fra og med oktober 2025 er forkjøpsrett for datapakking aktivert.

Komprimeringssjekker for delte låser som holdes av brukerspørringer. Hvis datakomprimering oppdager en lås før den begynner, venter den og prøver igjen senere. Hvis datakomprimering starter og oppdager en lås før den utføres, avbrytes komprimering for å unngå skrivekonflikt med brukerspørringen.

Skrive-skrive-konflikter med Fabric datalager bakgrunnsdatakomprimeringstjeneste er fortsatt mulig. Det er mulig å opprette en skrive-skrive-konflikt med datakomprimering, for eksempel hvis en applikasjon bruker en eksplisitt transaksjon og utfører ikke-motstridende arbeid (som INSERT) før en motstridende operasjon (UPDATE, DELETE, MERGE). Datakomprimering kan utføres, noe som fører til at den eksplisitte transaksjonen senere mislykkes på grunn av en konflikt. For mer informasjon om skriv-skrive- eller oppdateringskonflikter, se Transaksjoner i lagertabeller i Microsoft Fabric.

V-Order i Fabric datalager

V-Order er en skrivetidsoptimalisering av parquet-filformatet som muliggjør raske lesinger i Microsoft Fabric. V-Order i Fabric datalager forbedrer spørringsytelsen ved å bruke sortering og komprimering på tabellfiler.

Som standard aktiveres V-ordre på alle lagre for å sikre at leseoperasjoner, spesielt analytiske spørringer, er så raske og effektive som mulig.

V-Order introduserer imidlertid en liten inntakskostnad, merkbar i skrivetunge arbeidsbelastninger. Derfor bør deaktivering av V-ordre bare vurderes for lagre som er strengt skriveintensive og ikke brukes til hyppig spørring. Det er viktig å være oppmerksom på at når V-Ordre er deaktivert på et lager, kan den ikke aktiveres på nytt.

Før de bestemmer seg for å deaktivere V-Order, bør brukerne teste arbeidsbelastningsytelsen grundig for å sikre at avveiningen er berettiget. Et vanlig mønster er å bruke et staging-lager med V-Order deaktivert for høygjennomstrømming, datatransformasjon, og å importere underliggende data til et V-Order-aktivert datalager for bedre leseytelse. For mer informasjon, se Disable V-Order on Warehouse in Microsoft Fabric.

Klone tabeller i stedet for å kopiere tabeller

tabellkloner i Fabric datalager gir en rask og effektiv måte å lage tabeller på uten å kopiere data. Med en kloningsmetode uten kopier, er bare tabellens metadata duplisert, mens de underliggende datafilene refereres direkte fra OneLake. Dette gjør det mulig for brukere å opprette konsekvente, pålitelige tabellkopier nesten umiddelbart, uten overhead av full dataduplisering.

Zero-copy kloner er ideelle for scenarier som utvikling, testing og sikkerhetskopiering, og tilbyr en høyytelses, storage-effektiv løsning som bidrar til å redusere infrastrukturkostnader.

• Klonede tabeller kopierer også alle viktige sikkerhetsfunksjoner fra kilden, inkludert Row-Level Security (RLS), Column-Level Security (CLS) og Dynamic Data Masking (DDM), uten behov for å bruke policyer på nytt etter kloning.
• Kloner kan opprettes fra et bestemt tidspunkt i dataoppbevaringsperioden, som støtter tidsreiser.
• Klonede tabeller finnes uavhengig av kilden, endringer i kilden påvirker ikke klone, og endringer i klone påvirker ikke kilden. Enten kilden eller klone kan slippes uavhengig.

Spørringsmetadatavisninger

• Kjøringslogg for spørring (30 dager)

  • queryinsights.exec_requests_history
  • queryinsights.exec_sessions_history

• Aggregert innsikt

  • queryinsights.long_running_queries
  • queryinsights.frequently_run_queries

Hvis du vil ha mer informasjon om queryinsightsvisningene, kan du se Spørringsinnsikt i datalager for stoff.

• DMVer for spørringslivssyklus
  • sys.dm_exec_connections
  • sys.dm_exec_sessions
  • sys.dm_exec_requests

Hvis du vil ha mer informasjon om DMVer for spørringslivssyklus, kan du se Overvåke tilkoblinger, økter og forespørsler ved hjelp av DMV-er.

Relatert innhold

• Delta Lake i Microsoft Fabric oversikt
• Vedlikehold og optimalisering av kryss-arbeidsbelastningstabeller
• Tabelloptimalisering for Delta Lake og V-order
• Komprimering av tabell
• Vedlikehold av Lakehouse-bord
• Overvåk Fabric Data Warehouse
• Hva er Microsoft Fabric Capacity Metrics-appen?
• Søk innsikt
• Statistikk i Fabric datalager
• Inntak av data i lageret ved hjelp av COPY-setningen
• Søkeakselerasjon i Fabric datalager