Del via

Retningslinjer for ydeevne i Fabric Data Warehouse

Gælder for:✅ Warehouse i Microsoft Fabric

Denne artikel indeholder bedste praksis for dataindtagelse, tabelstyring, dataforberedelse, statistik og forespørgsler i lager- og SQL-analyseslutpunkter. Justering og optimering af ydeevnen kan give unikke udfordringer, men de giver også værdifulde muligheder for at maksimere funktionerne i dine dataløsninger.

Hvis du vil overvåge ydeevnen på dit lager, skal du se Overvåg Fabric Data Warehouse.

Optimering af datatype

Det er vigtigt for ydeevnen og lagereffektiviteten i dit lager at vælge de rigtige datatyper. Følgende retningslinjer hjælper med at sikre, at dit skemadesign understøtter hurtige forespørgsler, effektivt lager og vedligeholdelse.

Du kan få flere oplysninger om de datatyper, der understøttes af Fabric Data Warehouse, under Datatyper i Fabric Data Warehouse.

Tips

Hvis du bruger eksterne værktøjer til at generere tabeller eller forespørgsler, f.eks. med en kodebaseret udrulningsmetode, skal du omhyggeligt gennemse kolonnedatatyperne. Længder og forespørgsler for tegndatatyper skal følge disse bedste fremgangsmåder.

Tilpas datatyper til datasemantik

For at sikre både klarhed og ydeevne er det vigtigt at justere hver kolonnes datatype i forhold til den faktiske karakter og funktionsmåde af de data, den gemmer.

  • Brug dato, klokkeslæt eller datetime2(n) til tidsmæssige værdier i stedet for at gemme dem som strenge.
  • Brug heltalstyper til numeriske værdier, medmindre formatering (f.eks. foranstillede nuller) er påkrævet.
  • Brug tegntyper (tegn, varchar), når det er vigtigt at bevare formateringen (f.eks. tal, der kan begynde med nul, produktkoder, tal med tankestreger).

Brug heltalstyper til heltal

Når du gemmer værdier, f.eks. identifikatorer, tællere eller andre heltal, foretrækkes heltalstyper (smallint, int, bigint) frem for decimaltal/. Heltalstyper kræver mindre lagerplads end datatyper, der tillader cifre til højre for decimaltegnet. De muliggør derfor hurtigere aritmetiske handlinger og sammenligningshandlinger og forbedrer ydeevnen for indeksering og forespørgsler.

Vær opmærksom på værdiintervallerne for hver heltalsdatatype, der understøttes af Fabric Data Warehouse. Du kan få flere oplysninger , int, bigint, smallint (Transact-SQL).

Overvej brugen af decimal- og numerisk præcision og skalering

Hvis du skal bruge decimaltal/, skal du vælge den mindste præcision og skalering , der kan rumme dine data, når du opretter kolonnen. Præcision i forbindelse med overklaring øger lagerkravene og kan forringe ydeevnen i takt med, at dataene vokser.

  • Forudse dit lagers forventede vækst og behov. Hvis du f.eks. ikke vil gemme mere end fire cifre til højre for decimaltegnet, skal du bruge decimal(9,4) eller decimal(19,4) for at få det mest effektive lager.
  • Angiv altid præcision og skalering, når du opretter en numerisk decimalkolonne/. Når den oprettes i en tabel, der er defineret som bare decimal, uden at angive (p,s) for præcision og skalering, oprettes der en numerisk decimalkolonne/ som .decimal(18,0) En decimal med en præcision på 18 bruger 9 byte lagerplads pr. række. En skalering af 0 gemmer ikke data til højre for decimaltegnet. For mange virksomheder hele tal, smallint, int, bigint er meget mere effektive end decimal(18,0). Et hvilket som helst nicifret heltal kan f.eks. gemmes som en heltalsdatatype for 4 byte lagerplads pr. række.

Du kan få flere oplysninger under decimaler og numeriske (Transact-SQL).

Overvej, hvornår du skal bruge varchar over tegn

Brug varchar(n) i stedet for char(n) for strengkolonner, medmindre udfyldning med fast længde udtrykkeligt er påkrævet. En varchar-kolonne gemmer kun den faktiske strenglængde pr. række plus en lille belastning og reducerer spildplads, hvilket forbedrer I/O-effektiviteten.

  • Brug varchar(n) til værdier som navne, adresser og beskrivelser, da de har meget variable værdier. Statistikker og estimering af forespørgselsomkostninger er mere nøjagtige, når datatypens længde er mere præcis i forhold til de faktiske data.
  • Brug char(n), når du ved, at strengen vil være en fast længde hver gang. Det giver f.eks. mening at gemme strengen 000000000 som et tegn(9), hvis strengen altid er præcis 9 numeriske tegn, der kan starte med et nul.
  • Længden n i kolonnedatatypeerklæringen er lagerbyte. I forbindelse med tegnsæt med flerebytetegn, f.eks. UTF-8, tager kodningen for Fabric Data Warehouse, latinske tegn og tal 1 byte lagerplads. Der er dog Unicode-tegn, der kræver mere end 1 byte, f.eks. japanske tegn, der kræver 3 byte at gemme, så antallet af Unicode-tegn, der faktisk er gemt, kan være mindre end datatypelængden n. Du kan få flere oplysninger under argumenterne char og varchar.

Undgå kolonner, der kan være null, når det er muligt

Definer kolonner, som NOT NULL når datamodellen tillader det. Som standard tillader NULL en kolonne i en tabel værdier. Kolonner, der kan være null, har følgende egenskaber:

  • De tilføjer metadataomkostninger.
  • Kan reducere effektiviteten af forespørgselsoptimeringer og statistikker.
  • Kan påvirke ydeevnen i analyseforespørgsler i stor skala.

Dataindtagelse og -forberedelse i et lager

KOPIÉR TIL

Kommandoen T-SQL COPY INTO er den anbefalede måde at indtage data fra Azure Data Lake Storage på i Fabric Data Warehouse. Du kan få flere oplysninger og eksempler under Indfødning af data til dit lager ved hjælp af COPY-sætningen.

Overvej følgende anbefalinger for at få den bedste ydeevne:

  • Filstørrelse: Sørg for, at hver fil, du indtager, ideelt set er mellem 100 MB og 1 GB for maksimeret gennemløb. Dette hjælper med at optimere indtagelsesprocessen og forbedre ydeevnen.
  • Antal filer: For at maksimere parallelitet og forespørgselsydeevne skal du forsøge at generere et højt antal filer. Prioriter oprettelse af så mange filer som muligt, samtidig med at du bevarer en minimumfilstørrelse på 100 MB.
  • Parallel indlæsning: Anvend flere COPY INTO sætninger, der kører parallelt for at indlæse data i forskellige tabeller. Denne fremgangsmåde kan reducere ETL/ELT-vinduet betydeligt på grund af parallelitet.
  • Kapacitetsstørrelse: For større datamængder kan du overveje at skalere ud til større Fabric Capacity for at få de ekstra beregningsressourcer, der er nødvendige for at imødekomme yderligere antal parallelle behandlingsmængder og større datamængder.

Fabric Data Warehouse understøtter BULK INSERT også sætning, der er et synonym for COPY INTO. Den samme anbefaling gælder for BULK INSERT sætningen.

CTAS eller INSERT

Brug CREATE TABLE AS SELECT (CTAS) eller INSERT kombineret med SELECT FROM Kommandoer til tabel/genvej i Lakehouse. Disse metoder kan være mere effektive og effektive end at bruge pipelines, hvilket giver mulighed for hurtigere og mere pålidelige dataoverførsler. Du kan få flere oplysninger og eksempler under Indfødning af data i dit lager ved hjælp af Transact-SQL.

Begrebet at øge antallet af parallelitet og skalering til større Fabric Capacity gælder også for CTAS/INSERT-handlinger for at øge gennemløbet.

Læs data fra Azure Data Lake Storage eller Blob Storage med OPENROWSET

Funktionen OPENROWSET giver dig mulighed for at læse CSV- eller Parquet-filer fra Azure Data Lake eller Azure Blob Storage uden at overføre dem til Warehouse. Du kan finde flere oplysninger og eksempler under Gennemse filindhold ved hjælp af funktionen OPENROWSET.

Når du læser data ved hjælp af funktionen OPENROWSET, skal du overveje følgende anbefalinger for at få den bedste ydeevne:

  • Parket: Prøv at bruge Parquet i stedet for CSV, eller konvertér CSV til Parquet, hvis du ofte forespørger filerne. Parquet er et kolonneformat. Da data er komprimeret, er filstørrelserne mindre end CSV-filer, der indeholder de samme data. Fabric Data Warehouse springer de kolonner og rækker over, der ikke er nødvendige i en forespørgsel, hvis du læser Parquet-filer.
  • Filstørrelse: Sørg for, at hver fil, du indtager, ideelt set er mellem 100 MB og 1 GB for maksimeret gennemløb. Dette hjælper med at optimere indtagelsesprocessen og forbedre ydeevnen. Det er bedre at have lige store filer.
  • Antal filer: For at maksimere parallelitet og forespørgselsydeevne skal du forsøge at generere et højt antal filer. Prioriter oprettelse af så mange filer som muligt, samtidig med at du bevarer en minimumfilstørrelse på 100 MB.
  • Partition: Partitioner dine data ved at gemme partitioner i forskellige mapper eller filnavne, hvis arbejdsbelastningen filtrerer dem efter partitionskolonner.
  • Skøn: Prøv at angive ROWS_PER_BATCH , så det svarer til antallet af rækker i de underliggende filer, hvis du føler, at du ikke får den forventede ydeevne.
  • Kapacitetsstørrelse: I forbindelse med større datamængder kan du overveje at skalere ud til større SKU for at få flere beregningsressourcer, der er nødvendige for at imødekomme et ekstra antal parallelle behandlingsmængder og større datamængder.

Undgå trickle inserts, updates og deletes

Hvis du vil sikre et effektivt fillayout og optimal ydeevne af forespørgsler i Fabric Data Warehouse, skal du undgå at bruge mange små INSERTtransaktioner , UPDATEog DELETE . Disse ændringer på rækkeniveau genererer en ny Parquet-fil for hver handling, hvilket resulterer i et stort antal små filer og fragmenterede rækkegrupper. Denne fragmentering medfører:

  • Øget ventetid for forespørgsler pga. ineffektiv filscanning.
  • Højere lager- og beregningsomkostninger.
  • Større afhængighed af baggrundskomprimeringsprocesser.

Anbefalede fremgangsmåder:

  • Batchposteringer, der skriver til Fabric Data Warehouse.
    • I stedet for mange små INSERT sætninger kan du f.eks. samle data før fase og indsætte data i én INSERT sætning.
  • Brug COPY INTO til masseindsætninger, og udfør opdateringer og sletninger i batches, når det er muligt.
  • Bevar mindst en importeret filstørrelse på 100 MB for at sikre effektiv rækkegruppedannelse.
  • Du kan finde flere vejledninger og bedste praksis for dataindtagelse under Bedste fremgangsmåder til indfødning af data i et lager.

Datakomprimering

I Fabric Data Warehouse er datakomprimering en baggrundsoptimeringsproces i Fabric Data Warehouse, der fletter små ineffektive Parquet-filer til færre, større filer. Disse filer oprettes ofte af hyppige trickle INSERT- , UPDATEeller DELETE -handlinger. Datakomprimering reducerer filfragmentering, forbedrer effektiviteten af rækkegrupper og forbedrer den overordnede ydeevne af forespørgsler.

Selvom Fabric Data Warehouse-programmet automatisk løser fragmentering over tid via datakomprimering, kan ydeevnen forringes, indtil processen er fuldført. Datakomprimering kører automatisk uden brugerinput for Fabric Data Warehouse.

Datakomprimering gælder ikke for Lakehouse. I forbindelse med Lakehouse-tabeller, der åbnes via SQL Analytics-slutpunkter, er det vigtigt at følge Bedste praksis for Lakehouse og manuelt køre kommandoen OPTIMIZE efter betydelige dataændringer for at bevare det optimale lagerlayout.

Undladelse af datakomprimering

Fabric Data Warehouse undgår på intelligent og aktiv måde skrive-skrivekonflikter mellem baggrundskomprimeringsopgaver og brugerhandlinger. Fra og med oktober 2025 er datakomprimering aktiveret.

Komprimeringskontrol for delte låse, der opbevares af brugerforespørgsler. Hvis datakomprimering registrerer en lås, før den begynder, venter den og prøver igen senere. Hvis datakomprimering starter og registrerer en lås, før den bekræftes, afbrydes komprimeringen for at undgå en skrivekonflikt med brugerforespørgslen.

Skrive-/skrivekonflikter med Fabric Data Warehouse-baggrundsdatakomprimeringstjenesten er stadig mulige. Det er muligt at oprette en skrive-skrive-konflikt med datakomprimering, f.eks. hvis et program bruger en eksplicit transaktion og udfører ikke-modstridende arbejde (som INSERT) før en modstridende handling (UPDATE, DELETE, MERGE). Datakomprimering kan bekræftes, hvilket medfører, at den eksplicitte transaktion senere mislykkes på grund af en konflikt. Du kan finde flere oplysninger om skrive-/skrive- eller opdateringskonflikter under Transaktioner i lagerstedstabeller i Microsoft Fabric.

V-Order i Fabric Data Warehouse

V-Order er en optimering af skrivetid til parquetfilformatet, der muliggør hurtig læsning i Microsoft Fabric. V-Order i Fabric Data Warehouse forbedrer forespørgselsydeevnen ved at anvende sortering og komprimering på tabelfiler.

Som standard er V-Order aktiveret på alle lagre for at sikre, at læsehandlinger, især analytiske forespørgsler, er så hurtige og effektive som muligt.

V-Order introducerer dog en lille indtagelsesbelastning, der er mærkbar i skrivetunge arbejdsbelastninger. Derfor bør deaktivering af V-Order kun tages i betragtning for lagre, der er strengt skrivetunge og ikke bruges til hyppige forespørgsler. Det er vigtigt at bemærke, at når V-Order er deaktiveret på et lager, kan den ikke aktiveres igen.

Før brugerne beslutter sig for at deaktivere V-Order, skal de grundigt teste deres arbejdsbelastningsydeevne for at sikre, at afvejningen er berettiget. Et almindeligt mønster er at bruge et midlertidigt lager med V-Order deaktiveret til dataindtagelse med høj gennemløb, datatransformation og indfødning af de underliggende data i et V-Order-aktiveret Data Warehouse for at opnå bedre læseydeevne. Du kan få flere oplysninger under Deaktiver V-Order on Warehouse i Microsoft Fabric.

Klon tabeller i stedet for at kopiere tabeller

Tabelkloninger i Fabric Data Warehouse er en hurtig og effektiv måde at oprette tabeller på uden at kopiere data. Med en tilgang til kloning med nul kopiering er det kun tabellens metadata, der duplikeres, mens der refereres direkte til de underliggende datafiler fra OneLake. Dette giver brugerne mulighed for at oprette ensartede, pålidelige tabelkopier næsten med det samme, uden at der er brug for fuld dataduplikering.

Kloner med nul kopiering er ideelle til scenarier som f.eks. udvikling, test og sikkerhedskopiering, hvilket giver en højtydende og lagereffektiv løsning, der hjælper med at reducere infrastrukturomkostningerne.

  • Klonede tabeller kopierer også alle vigtige sikkerhedsfunktioner fra kilden, herunder Row-Level Security (RLS), Column-Level Security (CLS) og DDM (Dynamic Data Masking), uden at det er nødvendigt at anvende politikker igen efter kloning.
  • Kloner kan oprettes på et bestemt tidspunkt inden for dataopbevaringsperioden, hvilket understøtter tidsrejsefunktioner.
  • Klonede tabeller findes uafhængigt af deres kilde, ændringer af kilden påvirker ikke klonen, og ændringer af klonen påvirker ikke kilden. Enten kan kilden eller klonen slippes uafhængigt af hinanden.

Forespørgselsydeevne

Statistik

Statistikker er permanente objekter, der repræsenterer data i kolonnerne i tabellerne. Forespørgselsoptimering bruger statistikker til at vælge og beregne omkostningerne for en forespørgselsplan. Brug af Fabric Data Warehouse- og Lakehouse SQL-analyseslutpunkt og vedligeholder automatisk histogramstatistik, statistik over gennemsnitlig kolonnelængde og statistik over tabelkardinalitet. Du kan få flere oplysninger under Statistik i Fabric Data Warehouse.

  • T-SQL-kommandoerne CREATE STATISTICS og UPDATE STATISTICS understøttes for histogramstatistik med en enkelt kolonne. Du kan udnytte disse, hvis der er et stort nok vindue mellem dine tabeltransformationer og din forespørgselsarbejdsbelastning, f.eks. under et vedligeholdelsesvindue eller anden nedetid. Dette reducerer sandsynligheden for, at dine SELECT forespørgsler først skal opdatere statistikker.
  • Prøv at definere tabelskema, der bevarer datatypeparitet i almindelige kolonnesammenligninger. Hvis du f.eks. ved, at kolonner ofte sammenlignes med hinanden i en WHERE delsætning eller bruges som JOIN ... ON prædikat, skal du sørge for, at datatyperne stemmer overens. Hvis det ikke er muligt at bruge nøjagtigt de samme datatyper, skal du bruge lignende datatyper, der er kompatible til implicit konvertering. Undgå eksplicitte datakonverteringer. Du kan få flere oplysninger under Konvertering af datatype.

Tips

For Lakehouse-brugere kan den ACE-Cardinality statistik bruge oplysninger fra dine tabellers Delta-logfiler til at være mere nøjagtige. Sørg for, at dine Spark-genererede Delta-tabeller indeholder tabelrækkeantal med: spark.conf.set("spark.databricks.delta.stats.collect", "true"). Du kan få flere oplysninger under Konfigurer og administrer automatiseret tabelstatistik i Fabric Spark.

Når du filtrerer lakehouse-tabeller på tidsstempelkolonnen før Apache Spark-kørsel 3.5.0, genereres der ikke statistik på rækkegruppeniveau for tidsstempelkolonner. Denne mangel på statistikker gør det vanskeligt for systemer, f.eks. Fabric Warehouse, at anvende eliminering af rækkegrupper (også kendt som data, der springer over eller prædikerer pushdown), hvilket er optimering af ydeevnen, der springer irrelevante rækkegrupper over under udførelse af forespørgsler. Uden disse statistikker kan filtrering af forespørgsler, der involverer tidsstempelkolonner, være nødvendigt at scanne flere data, hvilket medfører en betydelig forringelse af ydeevnen. Du kan opgradere Apache Spark-runtime i Fabric. Apache Spark 3.5.0 og nyere versioner kan generere statistikker på rækkegruppeniveau for tidsstempelkolonner. Du skal derefter genoprette tabellen og indtage dataene for at få genereret statistik på rækkegruppeniveau.

Ydeevne for kold cache

Den første udførelse af en forespørgsel i Fabric Data Warehouse kan være uventet langsommere end efterfølgende kørsler. Dette kaldes en kold start, der skyldes systeminitialisering eller skaleringsaktiviteter, der forbereder miljøet til behandling.

Kulden starter typisk, når:

  • Data indlæses fra OneLake i hukommelsen, fordi de åbnes for første gang og endnu ikke cachelagres.
  • Hvis data tilgås for første gang, forsinkes udførelsen af forespørgsler, indtil de nødvendige statistikker genereres automatisk.
  • Fabric Data Warehouse afbryder automatisk noder midlertidigt efter en periode med inaktivitet for at reducere omkostningerne og tilføjer noder som en del af automatisk skalering. Det tager typisk mindre end et sekund at genoptage eller oprette noder.

Disse handlinger kan øge forespørgslens varighed. Koldstart kan være delvis. Nogle beregningsnoder, data eller statistikker er muligvis allerede tilgængelige eller cachelagret i hukommelsen, mens forespørgslen venter på, at andre bliver tilgængelige. Du kan få flere oplysninger under Cachelagring i Fabric-datawarehousing.

Du kan registrere kolde starteffekter, der skyldes, at du henter data fra fjernlageret til hukommelsen ved at forespørge den queryinsights.exec_requests_history visning. Kontrollér kolonnen data_scanned_remote_storage_mb :

  • Værdien i, der ikke er nul, data_scanned_remote_storage_mb angiver en kold start. Data blev hentet fra OneLake under udførelse af forespørgslen. Efterfølgende visninger skal være klart hurtigere i queryinsights.exec_requests_history.
  • En nulværdi i data_scanned_remote_storage_mb er den perfekte tilstand, hvor alle data cachelagres. Der var ikke behov for nodeændringer eller data fra OneLake for at levere forespørgselsresultaterne.

Vigtige oplysninger

Bedøm ikke forespørgselsydeevnen baseret på den første udførelse. Kontrollér data_scanned_remote_storage_mb altid, om forespørgslen blev påvirket af kold start. Efterfølgende udførelser er ofte betydeligt hurtigere og repræsenterer den faktiske ydeevne, hvilket vil sænke den gennemsnitlige udførelsestid.

Forespørgsler på tabeller med strengkolonner

Brug den mindste strengkolonnelængde, der kan rumme værdier. Fabric Warehouse bliver konstant bedre; Du kan dog opleve en ikke-optimal ydeevne, hvis du bruger store strengdatatyper, især store objekter (LOB'er). For en customer_name kolonnes datatype skal du f.eks. overveje dine forretningsmæssige krav og forventede data og bruge en passende længde n , når du erklærer varchar(n), f.eks . varchar(100), i stedet for varchar(8000) eller varchar(max). Statistikker og estimering af forespørgselsomkostninger er mere nøjagtige, når datatypens længde er mere præcis i forhold til de faktiske data.

  • I Fabric Data Warehouse T-SQL kan du se vejledning til, hvordan du vælger den relevante længde for strengdatatyper.
  • Lakehouse-tabelstrengkolonner uden defineret længde i Spark genkendes af Fabric Warehouse som varchar(8000). Du opnår optimal ydeevne ved at bruge sætningen CREATE TABLE i SparkSQL til at definere strengkolonnen som varchar(n), hvor n er den maksimale kolonnelængde, der kan rumme værdier.

Transaktioner og samtidighed

Fabric Data Warehouse er bygget på en moderne, cloudbaseret arkitektur, der kombinerer transaktionsintegritet, snapshotisolation og distribueret beregning for at levere høj samtidighed og ensartethed i stor skala. Du kan få flere oplysninger under Transaktioner i lagertabeller.

Fabric Data Warehouse understøtter ACID-kompatible transaktioner ved hjælp af snapshotisolering. Det betyder:

  • Læse- og skrivehandlinger kan grupperes i en enkelt transaktion ved hjælp af standard-T-SQL (BEGIN TRANSACTION, COMMIT, ROLLBACK)
  • Alt eller intet-semantik: Hvis en transaktion strækker sig over flere tabeller, og én handling mislykkes, annulleres hele transaktionen.
  • Læs konsistens: SELECT Forespørgsler i en transaktion ser et ensartet snapshot af dataene, der ikke påvirkes af samtidige skrivninger.

Understøttelse af Fabric Warehouse-transaktioner:

  • DDL (Data Definition Language) i transaktioner: Du kan inkludere CREATE TABLE i en transaktionsblok.
  • Transaktioner på tværs af databaser: Understøttes i det samme arbejdsområde, herunder læsninger fra SQL Analytics-slutpunkter.
  • Parquet-baseret annullering: Da Fabric Data Warehouse gemmer data i uforanderlige Parquet-filer, er annulleringer hurtige. Annulleringer vender ganske enkelt tilbage til tidligere filversioner.
  • Automatisk datakomprimering og kontrolpunkt:Datakomprimering optimerer lagrings- og læseydeevnen ved at flette små Parquet-filer og fjerne logisk slettede rækker.
  • Automatisk kontrol: Hver skrivehandling (INSERT, UPDATE, DELETE) føjer en ny JSON-logfil til Delta Lake-transaktionsloggen. Med tiden kan dette resultere i hundreder eller tusindvis af logfiler, især i streamingscenarier eller scenarier med høj frekvensindtagelse. Automatisk kontrol forbedrer effektiviteten af læsning af metadata ved at opsummere transaktionslogge i en enkelt kontrolpunktfil. Uden kontrolpunkter skal alle læsninger scanne hele transaktionsloggens historik. Med kontrolpunkter er de eneste logfiler, der læses, den seneste kontrolpunktsfil og logfilerne efter den. Dette reducerer I/O- og metadataparsing drastisk, især for store eller ofte opdaterede tabeller.

Både komprimering og kontrol er afgørende for tabeltilstanden, især i miljøer med lang eller høj samtidighed.

Samtidighedskontrol og isolation

Fabric Data Warehouse bruger udelukkende snapshotisolation. Forsøg på at ændre isolationsniveauet via T-SQL ignoreres.

Bedste fremgangsmåder i forbindelse med transaktioner

  • Brug eksplicitte transaktioner med omhu. Altid COMMIT eller ROLLBACK. Lad ikke transaktioner være åbne.
    • Bevar kortlivede transaktioner. Undgå langvarige transaktioner, der indeholder låse unødigt, især for eksplicitte transaktioner, der indeholder DDLs. Dette kan medføre strid med SELECT sætninger i systemkatalogvisninger (f.eks. sys.tables) og kan medføre problemer med Fabric-portalen, der er afhængig af systemkatalogvisninger.
  • Tilføj logik for nye forsøg med forsinkelse i pipelines eller apps for at håndtere midlertidige konflikter.
    • Brug eksponentiel backoff for at undgå nye forsøgsstorme, der forværrer midlertidige netværksafbrydelser.
    • Du kan finde flere oplysninger under Forsøg mønster igen.
  • Overvåg låse og konflikter på lageret.

Reducer størrelsen på returnerede datasæt

Forespørgsler med stor datastørrelse i mellemliggende udførelse af forespørgsler eller i det endelige forespørgselsresultat kan opleve et større problem med forespørgselsydeevnen. Hvis du vil reducere størrelsen på det returnerede datasæt, skal du overveje følgende strategier:

  • Partitioner store tabeller i Lakehouse.
  • Begræns antallet af returnerede kolonner. SELECT * kan være dyrt.
  • Begræns antallet af returnerede rækker. Udfør så meget datafiltrering på lageret som muligt, ikke i klientprogrammer.
    • Prøv at filtrere, før du tilmelder dig, for at reducere datasættet tidligt i udførelsen af forespørgslen.
    • Filtrer efter kolonner med lav kardinalitet for at reducere store datasæt tidligt før JOIN'er.
    • Kolonner med høj kardinalitet er ideelle til filtrering og JOID'er. Disse bruges ofte i WHERE delsætninger og drager fordel af, at prædikat anvendes på et tidligere tidspunkt i udførelse af forespørgsler for at filtrere data fra.
  • Da primære nøgle- og entydige nøglebegrænsninger ikke gennemtvinges i Fabric Data Warehouse, er kolonner med disse begrænsninger ikke nødvendigvis gode kandidater til JOID'er.

Forespørgselsplaner og forespørgselstip

I Fabric Data Warehouse genererer forespørgselsoptimeringsprogrammet en plan for udførelse af forespørgsler for at bestemme den mest effektive måde at udføre en SQL-forespørgsel på. Erfarne brugere kan overveje at undersøge problemer med forespørgselsydeevnen med forespørgselsplanen eller ved at tilføje forespørgselstip.

  • Brugerne kan bruge SHOWPLAN_XML i SQL Server Management Studio til at få vist planen uden at udføre forespørgslen.
  • Valgfrie forespørgselstip kan føjes til en SQL-sætning for at give flere instruktioner til forespørgselsoptimering, før der oprettes en plan. Tilføjelse af forespørgselstip kræver avanceret viden om forespørgselsarbejdsbelastninger, og de bruges derfor typisk, når der er implementeret andre bedste fremgangsmåder, men problemet fortsætter.

Ikke-skalerbare handlinger

Fabric Data Warehouse er bygget på en arkitektur med omfattende parallel behandling (MPP), hvor forespørgsler udføres på tværs af flere beregningsnoder. I nogle scenarier er udførelse af en enkelt node berettiget:

  • Hele udførelsen af forespørgselsplanen kræver kun én beregningsnode.
  • En planundertræ kan være inden for én beregningsnode.
  • Hele forespørgslen eller en del af forespørgslen skal udføres på en enkelt node for at opfylde forespørgslens semantik. F.eks TOP . handlinger, global sortering, forespørgsler, der kræver sortering af resultater fra parallelle udførelser for at producere et enkelt resultat eller sammenføjning af resultater for det sidste trin.

I disse tilfælde kan brugerne modtage en advarselsmeddelelse "En eller flere ikke-skalerbare handlinger registreres", og forespørgslen kan køre langsomt eller mislykkes efter en lang udførelse.

  • Overvej at reducere størrelsen af forespørgslens filtrerede datasæt.
  • Hvis forespørgslens semantik ikke kræver udførelse af en enkelt node, kan du prøve at gennemtvinge en distribueret forespørgselsplan med FORCE DISTRIBUTED PLAN, f.eks OPTION (FORCE DISTRIBUTED PLAN);. .

Forespørg SQL Analytics-slutpunktet

Du kan bruge SQL Analytics-slutpunktet til at forespørge Lakehouse-tabeller, der er udfyldt med Spark SQL, uden at kopiere eller indtage data til lageret.

Følgende bedste fremgangsmåder gælder for forespørgsler om lagerdata i Lakehouse via SQL Analytics-slutpunktet. Du kan finde flere oplysninger om ydeevnen for SQL-slutpunkter under Overvejelser i forbindelse med ydeevnen af SQL-analyseslutpunkt.

Tips

Følgende bedste praksis gælder for brug af Spark til at behandle data i et lakehouse, der kan forespørges af SQL Analytics-slutpunktet.

Udfør almindelig tabelvedligeholdelse for Lakehouse-tabeller

I Microsoft Fabric optimerer lageret automatisk datalayout og udfører affaldsindsamling og komprimering. For en Lakehouse har du mere kontrol over bordvedligeholdelse. Tabeloptimering og støvsugning er nødvendige og kan reducere scanningstiden betydeligt for store datasæt. Tabelvedligeholdelse i Lakehouse udvides også til genveje og kan hjælpe dig med at forbedre ydeevnen betydeligt der.

Optimer lakehouse-tabeller eller -genveje med mange små filer

Hvis du har mange små filer, opstår der problemer med læsning af filmetadata. Brug kommandoen OPTIMIZE på Fabric-portalen eller i en notesbog til at kombinere små filer til større filer. Gentag denne proces, når antallet af filer ændres betydeligt.

Hvis du vil optimere et bord i et Fabric Lakehouse, skal du åbne Lakehouse på Fabric-portalen. Højreklik på tabellen i Stifinder, og vælg Vedligeholdelse. Vælg indstillinger på siden Kør vedligeholdelseskommandoer , og vælg derefter Kør nu.

Forespørgsels lakehouse-tabeller eller -genveje, der er placeret i det samme område

Fabric bruger beregning, hvor Fabric-kapaciteten er placeret. Forespørgsler om data, f.eks. i dit eget Azure Data Lake Storage eller i OneLake, i et andet område resulterer i ydeevnespild på grund af netværksventetid. Sørg for, at dataene er i det samme område. Afhængigt af dine krav til ydeevnen kan du overveje kun at bevare små tabeller, f.eks. dimensionstabeller, i et fjernområde.

Filtrer lakehouse-tabeller og -genveje på de samme kolonner

Hvis du ofte filtrerer tabelrækker efter bestemte kolonner, kan du overveje at partitionere tabellen.

Partitionering fungerer godt for kolonner med lav kardinalitet eller kolonner med forudsigelig kardinalitet, f.eks. år eller datoer. Du kan få flere oplysninger under Lakehouse-selvstudium – Forbered og transformér lakehouse-data og Indlæs data til Lakehouse ved hjælp af partition.

Klyngedannelse fungerer godt for kolonner med høj selektivitet. Hvis du har andre kolonner, som du ofte bruger til filtrering, bortset fra partitioneringskolonner, kan du overveje at gruppere tabellen ved hjælp af optimer med Spark SQL-syntaksen ZORDER BY. Du kan få flere oplysninger under Tabeloptimering af Delta Lake.

Forespørgselsmetadatavisninger

Du kan få flere oplysninger om visningerne queryinsightsunder Forespørgselsindsigt i Fabric-datawarehousing.

Du kan få flere oplysninger om dmv'er for forespørgselslivscyklus under Overvåg forbindelser, sessioner og anmodninger ved hjælp af DMV'er.

Relateret indhold

  • Last updated on