Overvejelser i forbindelse med ydeevnen for SQL-analyseslutpunkter

SQL analytics-endpointet gør det muligt at forespørge data i lakehouse ved at bruge 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-analyseendpointet up-to-dato for alle ændringer, der er dedikeret til lakehouses i et arbejdsområde. Microsoft Fabric-platformen håndterer synkroniseringsprocessen gennemsigtigt. 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, som denne artikel diskuterer. Baggrundsprocessen kører kun, når SQL-analyse-endpointet er aktivt, og den stopper efter 15 minutters inaktivitet.

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 denne tilgang tillader automatisk metadataopdagelse at skalere.
• Parquet-filer er uforanderlige af design. Når der sker en opdatering eller en sletningsoperation, tilføjer en Delta-tabel nye Parquet-filer til ændringsættet, hvilket øger antallet af filer over tid, afhængigt af hvor ofte opdateringer og sletninger sker. Hvis du ikke planlægger vedligeholdelse, skaber dette mønster til sidst en læseoverhead, og denne tilstand påvirker den tid, det tager at synkronisere ændringer til SQL analytics-endpointet. For at løse dette problem bør du planlægge regelmæssige vedligeholdelsesoperationer ved søhusens borde.
• I nogle scenarier kan du observere, at ændringer, der er dedikeret til et lakehouse, ikke er synlige i det tilknyttede SQL-analyse-endpoint. For eksempel kan du oprette en ny tabel i lakehouse, men den er endnu ikke opført i SQL-analyse-endpointet. Eller du kan committe et stort antal rækker til en tabel i et søhus, men disse data er endnu ikke synlige i SQL-analyse-endpointet. Du har mulighed for at starte on-demand metadata-synkronisering.
• Den automatiske synkroniseringsproces understøtter ikke alle Delta-funktioner. 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 tabelændringer under Extract Transform and Load (ETL)-behandlingen, opstår der 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 lagret i et lakehouse, afhænger forespørgselsydelsen i høj grad af den fysiske opbygning af de underliggende Parquet-filer.

Et stort antal små Parquet-filer skaber overhead og påvirker forespørgselsydelsen negativt. For at sikre forudsigelig og effektiv ydeevne, vedligehold tabellager, 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-analyse-endpointet præsterer bedst, når Parquet-filerne 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. Sat maxFileSize til 4 GB.
4. Kør OPTIMIZE. For detaljer om brug, OPTIMIZEse Run table maintenance fra Lakehouse.

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 (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

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

For at opretholde sunde filstørrelser skal du periodisk køre Delta-optimeringsoperationer såsom OPTIMIZE, især for tabeller, der modtager hyppige inkrementelle indsættelser, 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.

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. Brug en kolonne, der resulterer i en partition på mindst (eller tæt på) 1 GB. Følg bedste praksis for vedligeholdelse og optimeringaf delta-tabeller. For et Python-script til at evaluere partitioner, se Eksempel-script for partitionsdetaljer.

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 Delta-tabel med et højt antal unikke værdier, partitioneres tabellen efter hver unik værdi og kan blive 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 problem bør du indføre regelmæssig vedligeholdelse af søhusborde.

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 ABFSS-stien for din delta-tabel 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.

Du kan kopiere det komplette script 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']}")

Automatisk genereret skema i SQL Analytics-slutpunktet for Lakehouse

For hver Delta-tabel i Lakehouse genererer SQL-analyseslutpunktet automatisk en tabel i det relevante skema. SQL analytics endpoint-motoren er baseret på Fabric data warehouse-motoren.

For mere information, se SQL analytics endpoint metadata sync. Du kan også programmatisk tvinge en opdatering af den automatiske metadatascanning ved at bruge Refresh SQL endpoint metadata REST API.

Relateret indhold

• Vedligeholdelse og optimering af tavler på tværs af arbejdsbelastninger
• Tabeloptimering af Delta Lake og V-Order
• Komprimering af tabel
• Juster filstørrelse
• Lakehouse SQL-analyse-endpoint brugstilfælde