Ytelseshensyn for SQL Analytics-endepunkt

SQL-analyseendepunktet gjør det mulig å spørre data i lakehouse ved å bruke T-SQL-språket og TDS-protokollen. Den utnytter Fabric datalager-motoren.

Tips

For omfattende veiledning på tvers av arbeidsbelastninger om optimalisering av Delta-tabeller for forbruk av SQL-analyser av endepunkter, inkludert anbefalinger om filstørrelse og radgrupper, se vedlikehold og optimalisering av kryssarbeidsbelastningstabeller.

Hvert lakehouse har ett SQL Analytics-endepunkt. Antall SQL-analyseendepunkter i et arbeidsområde samsvarer med antall lakehouses og speilede databaser som er klargjort i det ene arbeidsområdet.

En bakgrunnsprosess er ansvarlig for å skanne lakehouse for endringer og holde SQL-analyseendepunktet up-to-dato for alle endringer som er satt inn i lakehouses i et arbeidsområde. Fabric-plattformen håndterer synkroniseringsprosessen transparent. Når en endring oppdages i et lakehouse, oppdaterer en bakgrunnsprosess metadata, og SQL Analytics-endepunktet gjenspeiler endringene som er forpliktet til lakehouse-tabeller. Under normale driftsforhold er etterslepet mellom et lakehouse- og SQL Analytics-endepunkt mindre enn ett minutt. Den faktiske varigheten kan variere fra noen sekunder til minutter, avhengig av mange faktorer som denne artikkelen diskuterer. Bakgrunnsprosessen kjører mens SQL-analyseendepunktet er aktivt og stopper etter 15 minutter uten spørringsaktivitet.

Veiledning

Automatisk metadataoppdagelse sporer endringer som er forpliktet til lakehouses, og er en enkelt forekomst per Fabric-arbeidsområde. Hvis du observerer økt forsinkelse for synkronisering mellom lakehouses og SQL-analyse-endepunktet, kan det skyldes et stort antall lakehouses i ett arbeidsområde. I et slikt scenario kan du vurdere å migrere hvert innsjøhus til et eget arbeidsområde, da denne tilnærmingen tillater automatisk metadataoppdagelse å skalere.
Parkettfiler er uforanderlige etter utforming. Når det skjer en oppdatering eller en slettingsoperasjon, legger en Delta-tabell til nye Parquet-filer med endringssettet, noe som øker antall filer over tid, avhengig av hvor ofte oppdateringer og slettinger kommer. Hvis du ikke planlegger vedlikehold, skaper dette mønsteret til slutt leseoverhead, og denne tilstanden påvirker tiden det tar å synkronisere endringer til SQL-analyse-endepunktet. For å løse dette problemet, planlegg regelmessig vedlikehold av innsjøhusbord.
I noen scenarioer kan du observere at endringer som er dedikert til en lakehouse ikke er synlige i det tilhørende SQL-analyse-endepunktet. For eksempel kan du opprette en ny tabell i lakehouse, men den er ennå ikke oppført i SQL-analyse-endepunktet. Eller du kan committe et stort antall rader i en tabell i et lakehouse, men disse dataene er ennå ikke synlige i SQL-analyse-endepunktet. Du kan starte on-demand metadata-synkronisering i Fabric-portalen eller bruke Refresh SQL analytics endpoint metadata REST API.
Den automatiske synkroniseringsprosessen støtter ikke alle Delta-funksjoner. Hvis du vil ha mer informasjon om funksjonaliteten som støttes av hver motor i Fabric, kan du se Delta Lake-tabellformatet interoperabilitet.
Hvis det er et ekstremt stort volum av tabellendringer under Extract Transform and Load (ETL)-behandlingen, oppstår en forventet forsinkelse til alle endringene er behandlet.

Optimalisering av lakehouse-tabeller for å spørre SQL-analyseendepunktet

Når SQL-analyseendepunktet leser tabeller lagret i et lakehouse, avhenger spørringsytelsen sterkt av den fysiske utformingen av de underliggende Parquet-filene. Motoren paralleliserer skanningene på Parquet-filnivå. For mange små filer øker fil- og metadata-overhead, mens for få store filer kan begrense skanningsparallellismen.

For tabeller skrevet av Spark, bruk standardinnstillingene i Fabric Spark runtime 2.0 eller nyere. Disse kjøretidene muliggjør adaptiv målfilstørrelse som standard for å velge den mest optimale målfilstørrelsen per tabell, fra 128 MB for mindre tabeller opp til 1 GB for de største tabellene. Unngå å sette statiske mål eller vilkårlig radantallsgrense oppå standardkonfigurasjonene. En radbegrensning tar ikke hensyn til radbredde og kan lage små filer for smale tabeller.

Hvis du bruker Fabric Spark runtime 1.3, aktiver adaptiv målfilstørrelse og filnivå-komprimeringsmål, som er tilgjengelige som opt-in-funksjoner.

V-Order gagner primært Power BI Direct Lake, og selv om det kan forbedre komprimeringen for enkelte arbeidsbelastninger, er det vanligvis ikke nødvendig eller anbefalt som standard for optimal ytelse på SQL-analyseendepunkter.

Standard skriveinnstillinger erstatter ikke tabellvedlikehold. Bruk følgende metoder for å bevare et sunt oppsett når tabellene endres:

Aktiver automatisk komprimering for arbeidsbelastninger hvor den periodiske ekstra synkrone skrivelatensen er akseptabel. Automatisk komprimering er en Spark-funksjon som bare kjøres når det er for mange små filer i en tabell.
Planlegg periodiske OPTIMIZE jobber for arbeidsbelastninger der den periodiske ekstra forsinkelsen fra automatisk komprimering ikke oppfyller dataoppdaterings-SLA-ene.
Kjør VACUUM i henhold til dine krav til oppbevaring og tidsreise for å fjerne filer som Delta-loggen ikke lenger refererer til. VACUUM reduserer lagret lagring, men forbedrer ikke det aktive filoppsettet.
Unngå partisjonering med høy kardinalitet og tilpassede skriverkonfigurasjoner som lager mange små filer.

Hvis du ikke bruker automatisk komprimering, for å identifisere tabeller som trenger vedlikehold, bruk en datapipeline og T-SQL-lagret sys.sp_get_table_health_metrics prosedyre før du kjører OPTIMIZE. For en veiledning, se Optimaliser Lakehouse-tabeller basert på helsesjekker.

Bemerkning

For veiledning om generell vedlikehold av lakehouse-tabeller, se Run table maintenance fra Lakehouse.

Partisjonsstørrelseshensyn

Partisjonsoppsettet påvirker hvor lang tid SQL-analyseendepunktet bruker på å oppdage og synkronisere endringer. Et stort antall partisjoner eller små Parquet-filer øker overhead for metadata-skanning. Følg disse praksisene:

Unngå partisjonskolonner med høy kardinalitet, som kan lage en partisjon for hver unike verdi. Velg en kolonne som produserer partisjoner nær eller større enn 1 GB. For mer informasjon, se Delta Lake-tabelloppdeling.
Batch- og streaming-inntasting kan skape små filer når endringene er hyppige eller små. Bruk regelmessig vedlikehold av lakehouse-tabeller for å komprimere disse filene.

For å evaluere størrelsen og filantallet til hver partisjon, bruk eksempelskriptet for partisjonsdetaljer.

Eksempelskript for partisjonsdetaljer

Bruk følgende notatbok til å skrive ut en rapport som beskriver størrelse og detaljer om partisjoner som ligger til grunn for en Delta-tabell.

Først, oppgi ABFSS-stien for Delta-tabellen din i variabelen delta_table_path.
- Du kan få ABFSS-banen til en deltatabell fra Fabric Portal Explorer. Høyreklikk tabellnavnet, og velg COPY PATH deretter fra listen over alternativer.
Skriptet gir ut alle partisjoner for Delta-tabellen.
Skriptet itererer gjennom hver partisjon for å beregne total størrelse og antall filer.
Skriptet sender ut detaljene for partisjoner, filer per partisjoner og størrelse per partisjon i GB.

Du kan kopiere hele skriptet fra følgende kodeblokk:

# Purpose: Print out details of partitions, files per partitions, and size per partition in GB.
from notebookutils import mssparkutils

# Define ABFSS path for your delta table. You can get ABFSS path of a delta table by simply right-clicking on table name and selecting COPY PATH from the list of options.
delta_table_path = "abfss://<workspace id>@<onelake>.dfs.fabric.microsoft.com/<lakehouse id>/Tables/<tablename>"

# List all partitions for given delta table
partitions = mssparkutils.fs.ls(delta_table_path)

# Initialize a dictionary to store partition details
partition_details = {}

# Iterate through each partition
for partition in partitions:
  if partition.isDir:
      partition_name = partition.name
      partition_path = partition.path
      files = mssparkutils.fs.ls(partition_path)
      
      # Calculate the total size of the partition

      total_size = sum(file.size for file in files if not file.isDir)
      
      # Count the number of files

      file_count = sum(1 for file in files if not file.isDir)
      
      # Write partition details

      partition_details[partition_name] = {
          "size_bytes": total_size,
          "file_count": file_count
      }
      
# Print the partition details
for partition_name, details in partition_details.items():
  print(f"{partition_name}, Size: {details['size_bytes']:.2f} bytes, Number of files: {details['file_count']}")

Tilbakemeldinger

Var denne siden nyttig?

Sist oppdatert 2026-09-16