Del via


Overvejelser i forbindelse med ydeevnen for SQL-analyseslutpunkter

Gælder for:✅ SQL Analytics-slutpunkt i Microsoft Fabric

SQL Analytics-slutpunktet giver dig mulighed for at forespørge om data i lakehouse ved hjælp af T-SQL-sproget og TDS-protokollen. Hver lakehouse har ét SQL Analytics-slutpunkt. Antallet af SQL-analyseslutpunkter i et arbejdsområde svarer til antallet af lakehouses og spejlede databaser , der er klargjort i det pågældende arbejdsområde.

En baggrundsproces er ansvarlig for at scanne lakehouse for ændringer og holde SQL Analytics-slutpunktet opdateret for alle de ændringer, der er anvendt på lakehouses i et arbejdsområde. Synkroniseringsprocessen administreres gennemsigtigt af Microsoft Fabric-platformen. Når der registreres en ændring i et lakehouse, opdateres metadata i en baggrundsproces, og SQL Analytics-slutpunktet afspejler de ændringer, der er bekræftet i lakehouse-tabeller. Under normale driftsforhold er mellemliggende tid mellem et lakehouse- og SQL Analytics-slutpunkt mindre end ét minut.

Vejledning

  • Automatisk registrering af metadata sporer ændringer, der er bekræftet i lakehouses, og er en enkelt forekomst pr. Fabric-arbejdsområde. Hvis du iagttager øget ventetid for ændringer, der skal synkroniseres mellem lakehouses og SQL Analytics-slutpunktet, kan det skyldes et stort antal lakehouses i ét arbejdsområde. I et sådant scenarie kan du overveje at migrere hvert lakehouse til et separat arbejdsområde, da det gør det muligt at skalere automatisk registrering af metadata.
  • Parquet-filer er uforanderlige af design. Når der er en opdatering eller en sletningshandling, tilføjer en Delta-tabel nye parquetfiler med ændringssættet, hvilket øger antallet af filer over tid, afhængigt af hyppigheden af opdateringer og sletninger. Hvis der ikke er planlagt nogen vedligeholdelse, medfører dette mønster en belastning for læsning, og det påvirker den tid, det tager at synkronisere ændringer i SQL Analytics-slutpunktet. Du kan løse dette ved at planlægge almindelige vedligeholdelseshandlinger for lakehouse-tabellen.
  • I nogle scenarier kan du se, at ændringer, der er anvendt i et lakehouse, ikke er synlige i det tilknyttede SQL Analytics-slutpunkt. Du kan f.eks. have oprettet en ny tabel i lakehouse, men den er ikke angivet i SQL Analytics-slutpunktet. Eller du har muligvis gemt et stort antal rækker i en tabel i et lakehouse, men disse data er ikke synlige i SQL Analytics-slutpunktet. Vi anbefaler, at du starter en synkronisering af metadata efter behov, der udløses fra indstillingen Opdater bånd i SQL-forespørgselseditoren. Denne indstilling gennemtvinger synkronisering af metadata efter behov i stedet for at vente på, at synkroniseringen af metadata i baggrunden afsluttes. Skærmbillede fra Fabric-portalen for knappen til opdatering efter behov på værktøjslinjen for SQL Analytics-slutpunktet.

Overvejelser i forbindelse med partitionsstørrelse

Valget af partitionskolonne til en deltatabel i et lakehouse påvirker også den tid, det tager at synkronisere ændringer i SQL Analytics-slutpunktet. Antallet og størrelsen af partitioner i partitionskolonnen er vigtige for ydeevnen:

  • En kolonne med høj kardinalitet (hovedsageligt eller udelukkende lavet af entydige værdier) resulterer i et stort antal partitioner. Et stort antal partitioner påvirker ydeevnen af metadataregistreringsscanningen negativt for ændringer. Hvis kardinaliteten for en kolonne er høj, skal du vælge en anden kolonne til partitionering.
  • Størrelsen på hver partition kan også påvirke ydeevnen. Vores anbefaling er at bruge en kolonne, der vil resultere i en partition på mindst (eller tæt på) 1 GB. Vi anbefaler, at du følger bedste praksis for vedligeholdelse af deltatabeller. optimering. Hvis du vil have et Python-script til at evaluere partitioner, skal du se Eksempelscript for at få flere oplysninger om partitioner.

En stor mængde små parketfiler øger den tid, det tager at synkronisere ændringer mellem et lakehouse og det tilknyttede SQL Analytics-slutpunkt. Du kan ende med at have et stort antal parketfiler i en deltatabel af en eller flere årsager:

  • Hvis du vælger en partition til en deltatabel med et højt antal entydige værdier, partitioneres den af hver entydige værdi og kan være overpartitioneret. Vælg en partitionskolonne, der ikke har en høj kardinalitet, og resulterer i en individuel partitionsstørrelse på mindst 1 GB.
  • Dataindtagelseshastigheder for batch- og streamingdata kan også resultere i små filer, afhængigt af hyppigheden og størrelsen af ændringer, der skrives til et lakehouse. Der kan f.eks. være en lille mængde ændringer, der kommer igennem til lakehouse, og det vil resultere i små parketfiler. For at løse dette anbefaler vi, at du implementerer almindelig vedligeholdelse af lakehouse-bord.

Eksempelscript til partitionsoplysninger

Brug følgende notesbog til at udskrive en rapport med detaljer om størrelse og detaljer om partitioner, der understøtter en deltatabel.

  1. Først skal du angive ABSFF-stien til deltatabellen i variablen delta_table_path.
    • Du kan hente ABFSS-stien til en deltatabel fra Fabric Portal Explorer. Højreklik på tabelnavnet, og vælg COPY PATH derefter på listen over indstillinger.
  2. Scriptet skriver alle partitioner for deltatabellen.
  3. Scriptet gentages gennem hver partition for at beregne den samlede størrelse og antallet af filer.
  4. Scriptet skriver oplysninger om partitioner, filer pr. partition og størrelse pr. partition i GB.

Det komplette script kan kopieres fra følgende kodeblok:

# 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']}")