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.

Et stort antall små Parquet-filer skaper overhead og påvirker spørringsytelsen negativt. For å sikre forutsigbar og effektiv ytelse, oppretthold tabelllagring slik at hver Parquet-fil inneholder to millioner rader. Dette radantallet gir et balansert nivå av parallellisme uten å fragmentere datasettet i altfor små biter.

I tillegg til veiledning om radtall er filstørrelse like viktig. SQL-analyseendepunktet presterer best når Parquet-filene er store nok til å minimere filhåndteringskostnader, men ikke så store at de begrenser effektiviteten av parallell skanning. For de fleste arbeidsbelastninger er det best å holde individuelle Parquet-filer nær 400 MB. For å oppnå denne balansen, bruk følgende trinn:

1. Sett maxRecordsPerFile til 2 000 000 før dataendringer skjer.
2. Utfør dataendringene dine (datainntak, oppdateringer, slettinger).
3. Satt maxFileSize til 4 GB.
4. Kjør OPTIMIZE. For detaljer om bruk, OPTIMIZEse Run table maintenance fra Lakehouse.

Følgende skript gir en mal for disse stegene, og bør utføres på et innsjø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 å opprettholde sunne filstørrelser, kjør periodisk Delta-optimaliseringsoperasjoner som OPTIMIZE, spesielt for tabeller som mottar hyppige inkrementelle innsettinger, oppdateringer og slettinger. Disse vedlikeholdsoperasjonene komprimerer små filer til passende størrelser, noe som bidrar til å sikre at SQL-analyseendepunktet kan behandle spørringer effektivt. For å optimalisere tabeller som trenger vedlikehold intelligent, bruk en datapipeline og T-SQL-lagret sys.sp_get_table_health_metrics prosedyre for å avgjøre når en tabell trenger kommandoen 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 optimalisering 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