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.

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 bare når SQL-analyseendepunktet er aktivt, og den stopper etter 15 minutter uten aktivitet.

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 har muligheten til å starte on-demand metadata-synkronisering.
• 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.

Du trenger ikke V-Order for bedre ytelse på SQL-analyse-endepunktene, siden Spark skriver parquet-filer som er Snappy-komprimert for å redusere både lese- og skrive-I/O.

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.

Partisjonsstørrelseshensyn

Valget av partisjonskolonne for en Delta-tabell i et lakehouse påvirker også tiden det tar å synkronisere endringer til SQL-analyse-endepunktet. Antall partisjoner og størrelse på partisjonskolonnen er viktig for ytelsen:

• En kolonne med høy kardinalitet (for det meste eller helt laget av unike verdier) resulterer i et stort antall partisjoner. Et stort antall partisjoner påvirker ytelsen til metadataoppdagelsesskanningen negativt for endringer. Hvis kardinaliteten for en kolonne er høy, velger du en annen kolonne for partisjonering.
• Størrelsen på hver partisjon kan også påvirke ytelsen. Bruk en kolonne som resulterer i en partisjon på minst (eller nær) 1 GB. Følg beste praksis for vedlikehold og partisjonering av Delta-tabeller. For et Python-skript for å evaluere partisjoner, se Eksempelskript for partisjonsdetaljer.

Et stort antall parquetfiler i liten størrelse øker tiden det tar å synkronisere endringer mellom et lakehouse og tilhørende SQL Analytics-endepunkt. Du kan ende opp med et stort antall parkettfiler i en Delta-tabell av én eller flere grunner:

• Hvis du velger en partisjon for en Delta-tabell med høyt antall unike verdier, blir tabellen delt opp etter hver unik verdi og kan bli over-partisjonert. Velg en partisjonskolonne som ikke har høy kardinalitet, og resulterer i individuelle partisjoner minst 1 GB hver.
• Satsvise datainntak og strømming av data kan også føre til små filer avhengig av hyppigheten og størrelsen på endringene som skrives til et lakehouse. For eksempel kan det komme et lite volum av endringer inn til innsjøhuset, noe som resulterer i små parkettfiler. For å løse dette problemet, innfør regelmessig vedlikehold av innsjøhusbord.

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.

1. 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.
2. Skriptet gir ut alle partisjoner for Delta-tabellen.
3. Skriptet itererer gjennom hver partisjon for å beregne total størrelse og antall filer.
4. 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']}")

Automatisk generert skjema i SQL Analytics-endepunktet i Lakehouse

For hver Delta-tabell i Lakehouse genererer SQL Analytics-endepunktet automatisk en tabell i det aktuelle skjemaet. SQL-analyse-endepunktmotoren er basert på Fabric datalager-motoren.

For mer informasjon, se SQL analytics endpoint metadata sync. Du kan også programmatisk tvinge frem en oppdatering av den automatiske metadataskanningen ved å bruke Refresh SQL endpoint metadata REST API.

Relatert innhold

• Vedlikehold og optimalisering av kryss-arbeidsbelastningstabeller
• Delta Lake-tabelloptimalisering og V-orden
• Komprimering av tabell
• Juster filstørrelse
• Lakehouse SQL-analyse-endepunktsbrukstilfeller