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. Den faktiske varighed kan variere fra få sekunder til minutter afhængigt af mange faktorer, der diskuteres i denne artikel. Baggrundsprocessen kører kun, når SQL-analyse-endpointet er aktivt, og den stoppes efter 15 minutters inaktivitet.

Automatisk genereret skema i SQL Analytics-slutpunktet for Lakehouse

SQL Analytics-slutpunktet administrerer de automatisk genererede tabeller, så brugerne af arbejdsområdet ikke kan ændre dem. Brugerne kan forbedre databasemodellen ved at tilføje deres egne SQL-skemaer, visninger, procedurer og andre databaseobjekter.

For hver Delta-tabel i Lakehouse genererer SQL-analyseslutpunktet automatisk en tabel i det relevante skema. Du kan finde automatisk genererede skemadatatyper for SQL-analyseslutpunktet under Datatyper i Microsoft Fabric.

Tabeller i SQL Analytics-slutpunktet oprettes med en mindre forsinkelse. Når du opretter eller opdaterer Delta Lake-tabellen i søen, oprettes/opdateres SQL-analyse-endpointtabellen, der refererer til Delta-søtabellen, automatisk.

Den tid, det tager at opdatere tabellen, er relateret til, hvor optimerede Delta-tabellerne er. Du kan finde flere oplysninger ved at gennemse Delta Lake-tabeloptimering og V-Order for at få mere at vide om vigtige scenarier og en detaljeret vejledning til, hvordan du effektivt vedligeholder Delta-tabeller for at opnå maksimal ydeevne.

Du kan gennemtvinge en opdatering af den automatiske metadatascanning manuelt på Fabric-portalen. På siden for SQL Analytics-slutpunktet skal du vælge knappen Opdater på værktøjslinjen i Stifinder for at opdatere skemaet. Gå til Forespørg dit SQL Analytics-slutpunkt, og søg efter opdateringsknappen, som vist på følgende billede.

Skærmbillede fra Fabric-portalen, der viser knappen Opdater skema for SQL Analytics-slutpunktet.

Du kan også gennemtvinge en programmatisk opdatering af den automatiske metadatascanning ved hjælp af REST API'en Opdater SQL-slutpunktmetadata.

Vejledning

  • Automatisk registrering af metadata sporer ændringer, der er bekræftet i lakehouses, og er en enkelt forekomst pr. Fabric-arbejdsområde. Hvis du observerer øget latenstid for ændringer til synkronisering mellem lakehouses og SQL-analyse-endpointet, 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 observere, at ændringer, der er dedikeret til et lakehouse, ikke er synlige i det tilknyttede SQL-analyse-endpoint. Du kan f.eks. have oprettet en ny tabel i lakehouse, men den er endnu ikke angivet i SQL Analytics-slutpunktet. Eller du kan have dedikeret et stort antal rækker til en tabel i et lakehouse, men disse data er endnu ikke synlige i SQL-analyse-endpointet. Vi anbefaler, at du starter en synkronisering af metadata efter behov, der udløses fra indstillingen Opdater bånd i SQL-forespørgselseditoren eller REST API'en Opdater SQL-slutpunktmetadata. Denne indstilling gennemtvinger synkronisering af metadata efter behov i stedet for at vente på, at synkroniseringen af metadata i baggrunden afsluttes.
  • Det er ikke alle Delta-funktioner, der forstås af den automatiske synkroniseringsproces. Du kan få flere oplysninger om de funktioner, der understøttes af hvert program i Fabric, under Delta Lake-tabelformat interoperabilitet.
  • Hvis der er et ekstremt stort antal ændringer i tabeller under Extract Transform and Load (ETL)-behandlingen, kan der opstå en forventet forsinkelse, indtil alle ændringer er behandlet.

Optimering af lakehouse-tabeller til forespørgsler på SQL-analyse-endpointet

Når SQL-analyse-endpointet læser tabeller, der er gemt i et lakehouse, påvirkes forespørgselsydelsen i høj grad af den fysiske opbygning af de underliggende parquet-filer.

Et stort antal små parquetfiler skaber overhead og påvirker forespørgselsydelsen negativt. For at sikre forudsigelig og effektiv ydeevne anbefaler vi at vedligeholde tabellagring, så hver parquet-fil indeholder to millioner rækker. Dette rækkeantal giver et balanceret niveau af parallelisme uden at fragmentere datasættet i alt for små afsnit.

Ud over vejledning om rækketal er filstørrelse lige så vigtig. SQL analytics-endpointet præsterer bedst, når parquet-filer er store nok til at minimere filhåndteringsomkostninger, men ikke så store, at de begrænser effektiviteten af parallel scanning. For de fleste arbejdsbelastninger er det bedst at holde individuelle parquet-filer tæt på 400 MB. For at opnå denne balance skal du bruge følgende trin:

  1. Sæt maxRecordsPerFile til 2.000.000, før dataændringer sker.
  2. Udfør dine dataændringer (dataindlæsning, opdateringer, sletninger).
  3. Sæt maxFileSize til 400 MB.
  4. Kør OPTIMIZE. For detaljer om brug OPTIMIZEaf , se Table maintenance operations.

Følgende script giver en skabelon for disse trin og bør udføres på et søhus:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

For at opretholde sunde filstørrelser bør brugere periodisk køre Delta-optimeringsoperationer som OPTIMIZE, især for tabeller, der modtager hyppige inkrementelle skrivninger, opdateringer og sletninger. Disse vedligeholdelsesoperationer komprimerer små filer til passende størrelser, hvilket hjælper med at sikre, at SQL-analyse-endpointet kan behandle forespørgsler effektivt.

Notat

For vejledning om generel vedligeholdelse af lakehouse-tabeller, se Udfør ad-hoc table maintenance på en Delta-tabel med Lakehouse.

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 individuelle partitioner på mindst 1 GB hver.
  • 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. For eksempel kan der komme et lille antal ændringer ind i søhuset, hvilket resulterer 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']}")

Relateret indhold

  • Last updated on