Del via

Retningslinjer for ytelse i Fabric Data Warehouse

Gjelder for:✅ Lager 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.

Hvis du vil overvåke ytelsen på lageret, kan du se Monitor Fabric Data Warehouse.

Optimalisering av datatype

Å velge de riktige datatypene er avgjørende for ytelse og lagringseffektivitet i lageret. Følgende retningslinjer bidrar til å sikre at skjemautformingen støtter raske spørringer, effektiv lagring og vedlikehold.

Hvis du vil ha mer informasjon om datatyper som støttes av Fabric Data Warehouse, kan du se Datatyper i Fabric Data Warehouse.

Tips

Hvis du bruker eksterne verktøy til å generere tabeller eller spørringer, for eksempel med en kode-første distribusjonsmetodikk, bør du nøye se gjennom kolonnedatatypene. Tegndatatypelengder og spørringer bør følge disse anbefalte fremgangsmåtene.

Sammenligne datatyper med datasemantikk

For å sikre både klarhet og ytelse er det viktig å justere hver kolonnes datatype med den faktiske karakteren og virkemåten 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 lagringsplass enn datatyper som tillater sifre til høyre for desimaltegnet. Som et resultat tillater de raskere aritmetiske operasjoner og sammenligningsoperasjoner og forbedrer indeksering og spørringsytelse.

Vær oppmerksom på verdiområder for hver heltallsdatatype som støttes av Fabric Data Warehouse. 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. Overklaring av presisjon øker lagringskravene og kan redusere ytelsen etter hvert som dataene vokser.

  • Forutse lagerets forventede vekst og behov. Hvis du for eksempel planlegger å lagre ikke mer enn fire sifre til høyre for desimaltegnet, bruker du desimal(9,4) eller desimaltall (19,4) for mest effektiv lagringsplass.
  • 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 presisjon og skalering(p,s), opprettes en desimaltallkolonne/ somdecimal(18,0). En desimal med en presisjon på 18 bruker 9 byte lagringsplass 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). Et hvilket som helst nisifret heltall kan for eksempel lagres som en heltallsdatatype for fire byte lagringsplass 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 er nøyaktig 9 numeriske tegn som kan starte med null.
  • Lengden n i datatypedeklarasjonen for kolonnen er lagringsbytene. Kodingen for Fabric Data Warehouse, latinske tegn og tall tar 1 byte lagringsplass for tegnsett med flerebyte, for eksempel UTF-8. 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 å innta data fra Azure Data Lake Storage til Fabric Data Warehouse på. 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 Data Warehouse støtter BULK INSERT også uttrykk 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 datasamlebånd, noe som gir 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

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

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 Data Warehouse hopper over kolonnene og radene som ikke er nødvendige 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

Unngå å bruke mange små INSERT, UPDATEog DELETE transaksjoner for å sikre effektiv filoppsett og optimal spørringsytelse i Fabric Data Warehouse. 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 lagrings- og databehandlingskostnader.
  • Større avhengighet av bakgrunnskomprimeringsprosesser.

Anbefalte tilnærminger:

  • Satsvise transaksjoner som skrives inn i Fabric Data Warehouse.
    • 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 Data Warehouse er datakomprimering en bakgrunnsoptimaliseringsprosess i Fabric Data Warehouse som slår sammen små, ineffektive parquetfiler til 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 Data Warehouse-motoren automatisk løser fragmentering over tid gjennom datakomprimering, kan ytelsen reduseres til prosessen fullføres. Datakomprimering kjøres automatisk uten brukerintervensjon for Fabric Data Warehouse.

Datakomprimering gjelder ikke for Lakehouse. For Lakehouse-tabeller som er tilgjengelige gjennom SQL Analytics-endepunkter, er det viktig å følge Anbefalte fremgangsmåter for Lakehouse og kjøre OPTIMALISER-kommandoen manuelt etter betydelige dataendringer for å opprettholde optimal lagringsoppsett.

V-order i Fabric Data Warehouse

V-Order er en skrivetidsoptimalisering til parkettfilformatet som muliggjør raske lesinger i Microsoft Fabric. V-order i Fabric Data Warehouse 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 lager med V-Ordre deaktivert for høy gjennomstrømming, datatransformasjon og inntasting av de underliggende dataene i et V-ordreaktivert datalager for bedre leseytelse. Hvis du vil ha mer informasjon, kan du se Deaktiver V-ordre på lager i Microsoft Fabric.

Klone tabeller i stedet for å kopiere tabeller

Tabellklonene i Fabric Data Warehouse gir en rask og effektiv måte å opprette 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.

Kloner med null kopier er ideelle for scenarioer som utvikling, testing og sikkerhetskopiering, og tilbyr en lagringseffektiv løsning med høy ytelse som bidrar til å redusere infrastrukturkostnadene.

  • 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ø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 Data Warehouse og Lakehouse SQL analytics endpoint use and automatically maintain histogram statistics, average column length statistics, and table cardinality statistics. Hvis du vil ha mer informasjon, kan du se Statistikk i Fabric Data Warehouse.

  • 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. Dette reduserer sannsynligheten for at spørringene må SELECT oppdatere statistikk først.
  • Prøv å definere tabellskjema som opprettholder datatypeparitet i vanlige kolonnesammenligninger. Hvis du for eksempel vet at kolonner ofte sammenlignes med hverandre i en WHERE setningsdel, eller brukes som JOIN ... ON predikat, må du kontrollere at datatypene samsvarer. Hvis det ikke er mulig å bruke nøyaktig samme datatyper, kan du bruke lignende datatyper som er kompatible for implisitt konvertering. Unngå eksplisitte datakonverteringer. Hvis du vil ha mer informasjon, kan du se Konvertering av datatype.

Tips

For Lakehouse-brukere kan ACE-Cardinality-statistikken bruke informasjon fra tabellenes Delta-loggfiler til å være mer nøyaktige. Sørg for at spark-genererte Delta-tabeller inkluderer tabellradantall med: spark.conf.set("spark.databricks.delta.stats.collect", "true"). Hvis du vil ha mer informasjon, kan du se Konfigurere og administrere automatisert tabellstatistikk i Fabric Spark.

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

Den første kjøringen av en spørring i Fabric Data Warehouse kan være uventet tregere enn etterfølgende kjøringer. Dette kalles en kald start, forårsaket av systemstart eller skaleringsaktiviteter som forbereder miljøet for behandling.

Kulde starter vanligvis når:

  • Data lastes inn fra OneLake i minnet fordi det åpnes for første gang, og er ennå ikke bufret.
  • Hvis data åpnes for første gang, blir kjøring av spørring forsinket til den nødvendige statistikken genereres automatisk.
  • Fabric Data Warehouse stanser automatisk noder etter en periode med inaktivitet for å redusere kostnadene, og legger til noder som en del av autoskalering. Det tar vanligvis mindre enn ett sekund å gjenoppta eller opprette noder.

Disse operasjonene kan øke spørringsvarigheten. Kalde starter kan være delvis. Enkelte databehandlingsnoder, data eller statistikker er kanskje allerede tilgjengelige eller bufret i minnet, mens spørringen venter på at andre skal komme tilgjengelig. Hvis du vil ha mer informasjon, kan du se Caching in Fabric data warehousing.

Du kan oppdage kald starteffekter forårsaket av henting av data fra ekstern lagring i minnet ved å spørre queryinsights.exec_requests_history-visningen . data_scanned_remote_storage_mb Kontroller kolonnen:

  • Verdien som ikke er null, data_scanned_remote_storage_mb angir en kald start. Data ble hentet fra OneLake under kjøringen av spørringen. 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ødvendig for å betjene spørringsresultatene.

Viktig!

Ikke døm spørringsytelsen basert på den første kjøringen. Kontroller data_scanned_remote_storage_mb alltid om spørringen ble påvirket av kald start. Etterfølgende kjøringer er ofte betydelig raskere og er representative for faktisk ytelse, noe som vil redusere gjennomsnittlig kjøringstid.

Spørringer på tabeller med strengkolonner

Bruk den minste strengkolonnelengden som kan romme verdier. Fabric Warehouse er stadig bedre; Du kan imidlertid oppleve suboptimal ytelse hvis du bruker store strengdatatyper, spesielt store objekter (LOB-er). 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 Data Warehouse T-SQL kan du 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 Data Warehouse er bygget på en moderne, skybasert arkitektur som kombinerer transaksjonsintegritet, øyeblikksbildeisolasjon og distribuert databehandling for å levere høy samtidighet og konsistens i stor skala. Hvis du vil ha mer informasjon, kan du se Transaksjoner i lagertabeller.

Fabric Data Warehouse støtter ACID-kompatible transaksjoner ved hjelp av øyeblikksbildeisolering. 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 Data Warehouse lagrer data i uforanderlige parkettfiler, er tilbakerullingene raske. Tilbakerullinger går ganske enkelt tilbake til tidligere filversjoner.
  • Automatisk datakomprimering og kontrollpunkt:Datakomprimering optimaliserer lagrings- 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 kontrollpunkt er det bare den nyeste kontrollpunktfilen og loggene etter at den er lest. 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 Data Warehouse bruker øyeblikksbildeisolasjon utelukkende. 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 ny forsøkslogikk med forsinkelse i datasamlebånd eller apper for å håndtere midlertidige konflikter.
    • Bruk eksponentiell backoff for å unngå retry stormer som forverrer forbigående nettverksavbrudd.
    • Hvis du vil ha mer informasjon, kan du se Mønster for nytt forsøk.
  • Overvåk låser og konflikter i lageret.

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:

  • Partisjon store tabeller 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 Data Warehouse, siden primærnøkkel og unike nøkkelbetingelser ikke håndheves, er ikke kolonner med disse begrensningene nødvendigvis gode kandidater for JOIN-er.

Spørringsplaner og spørringstips

I Fabric Data Warehouse genererer spørringsoptimaliseringen en plan for kjøring av spørringer for å finne den mest effektive måten å kjø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 til å vise planen uten å kjø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 Data Warehouse er bygget på en massivt parallell behandlingsarkitektur (MPP), der spørringer utføres på tvers av flere databehandlingsnoder. 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.

Tips

Følgende anbefalte fremgangsmåter gjelder for å bruke Spark til å behandle data i et lakehouse som kan spørres av SQL Analytics-endepunktet.

Utfør regelmessig tabellvedlikehold for Lakehouse-tabeller

I Microsoft Fabric optimaliserer Warehouse automatisk dataoppsett og utfører søppelinnsamling og komprimering. 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.

Hvis du vil optimalisere et bord i et Fabric Lakehouse, åpner du Lakehouse i Fabric-portalen. Høyreklikk på tabellen i Utforsker, og velg Vedlikehold. Velg alternativer fra siden Kjør vedlikeholdskommandoer , og velg deretter Kjør nå.

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

Stoffet bruker databehandling der Fabric-kapasiteten er plassert. Spørring av data, for eksempel i din egen Azure Data Lake Storage eller i OneLake, i et annet område resulterer i ytelseskostnader på grunn av nettverksventetid. 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.

Spørringsmetadatavisninger

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

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