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. Den udnytter Fabric data warehouse-motoren.

Tip

For omfattende vejledning på tværs af arbejdsbelastninger i optimering af Delta-tabeller til forbrug af SQL-analyse-endpoints, inklusive anbefalinger til filstørrelse og rækkegrupper, se vedligeholdelse og optimering af tværarbejdstabel.

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. 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, mens SQL-analyse-endpointet er aktivt, og stopper efter 15 minutter uden forespørgselsaktivitet.

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 kan starte on-demand metadata-synkronisering i Fabric-portalen eller bruge Refresh SQL analytics endpoint metadata REST API.
  • 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. Motoren paralleliserer scanninger på Parquet-filniveau. For mange små filer øger fil- og metadata-overhead, mens for få store filer kan begrænse scanningsparallelitet.

For tabeller skrevet af Spark, brug standardindstillingerne i Fabric Spark runtime 2.0 eller nyere. Disse runtimes muliggør adaptiv målfilstørrelse som standard for at vælge den mest optimale målfilstørrelse efter tabel, fra 128 MB for mindre tabeller op til 1 GB for de største tabeller. Undgå at sætte statiske mål eller vilkårlig rækketælling-grænse oven på standardkonfigurationerne. En rækkebegrænsning tager ikke højde for rækkebredde og kan skabe små filer til smalle tabeller.

Hvis du bruger Fabric Spark runtime 1.3, kan du aktivere adaptiv målfilstørrelse og filniveau-komprimeringsmål, som er tilgængelige som opt-in-funktioner.

V-Order gavner primært Power BI Direct Lake og, selvom det kan forbedre komprimeringen for nogle arbejdsbelastninger, er det generelt ikke påkrævet eller anbefalet som standard for optimal ydeevne af SQL-analyse-endpoints.

Standard skriveindstillinger erstatter ikke tabelvedligeholdelse. Brug følgende metoder til at bevare et sundt layout, efterhånden som tabellerne ændrer sig:

  • Aktivér automatisk komprimering for arbejdsbelastninger, hvor den periodiske ekstra synkrone skrivelatens er acceptabel. Autokomprimering er en Spark-funktion, der kun kører, når der er for mange små filer i en tabel.
  • Planlæg periodiske OPTIMIZE jobs for arbejdsbelastninger, hvor den periodiske ekstra latenstid fra automatisk komprimering ikke overholder dataopdaterings-SLA'er.
  • Kør VACUUM i henhold til dine krav til opbevaring og tidsrejse for at fjerne filer, som Delta-loggen ikke længere refererer til. VACUUM Reducerer den tilbageholdte lagerplads, men forbedrer ikke det aktive fillayout.
  • Undgå høj-kardinalitet-partitionering og tilpassede writer-konfigurationer, der skaber mange små filer.

Hvis du ikke bruger automatisk komprimering, brug en datapipeline og T-SQL sys.sp_get_table_health_metrics stored procedure før kørsel OPTIMIZE. For en vejledning, se Optimer Lakehouse-tabeller baseret på sundhedstjek.

Bemærkning

For vejledning om generel vedligeholdelse af lakehouse-borde, se Run table maintenance fra Lakehouse.

Overvejelser i forbindelse med partitionsstørrelse

Partitionslayoutet påvirker, hvor lang tid SQL-analyseendpointet bruger på at opdage og synkronisere ændringer. Et stort antal partitioner eller små Parquet-filer øger overhead ved metadatascanning. Følg disse praksisser:

  • Undgå højkardinalitets-partitionkolonner, som kan oprette en partition for hver unik værdi. Vælg en kolonne, der producerer partitioner tæt på eller større end 1 GB. For mere information, se Delta Lake tabelopdeling.
  • Batch- og streaming-indtastning kan skabe små filer, når ændringerne er hyppige eller små. Brug regelmæssig vedligeholdelse af søhus-bordene til at komprimere disse filer.

For at evaluere størrelsen og filantallet af hver partition, brug eksempelscriptet til partitionsdetaljer.

Eksempelscript til partitionsoplysninger

Brug følgende notesbog til at printe en rapport, der detaljerer størrelse og detaljer om partitioner, der understøtter en Delta-tabel.

  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 udskriver alle partitioner for Delta-tabellen.
  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']}")

Relateret indhold

  • Last updated on