Del via

Ytelseshensyn for SQL Analytics-endepunkt

  • Artikkel

Gjelder for:✅ SQL Analytics-endepunkt i Microsoft Fabric

Sql Analytics-endepunktet gjør det mulig å spørre etter data i lakehouse ved hjelp av T-SQL-språk og TDS-protokoll. 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 Analytics-endepunktet oppdatert for alle endringene som er forpliktet til lakehouses i et arbeidsområde. Synkroniseringsprosessen administreres gjennomsiktig av Microsoft Fabric-plattformen. 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 tidsperioden kan variere fra noen få sekunder til minutter, avhengig av en rekke faktorer som er fjernet i denne artikkelen.

Automatisk generert skjema i SQL Analytics-endepunktet i Lakehouse

Sql Analytics-endepunktet administrerer de automatisk genererte tabellene, slik at brukerne av arbeidsområdet ikke kan endre dem. Brukere kan berike databasemodellen ved å legge til sine egne SQL-skjemaer, visninger, prosedyrer og andre databaseobjekter.

For hver Delta-tabell i Lakehouse genererer SQL Analytics-endepunktet automatisk en tabell i det aktuelle skjemaet. Hvis du vil ha automatisk genererte skjemadatatyper for SQL Analytics-endepunktet, kan du se Datatyper i Microsoft Fabric.

Tabeller i SQL Analytics-endepunktet opprettes med en mindre forsinkelse. Når du oppretter eller oppdaterer Delta Lake-tabellen i sjøen, opprettes/oppdateres SQL Analytics-endepunkttabellen som refererer til Delta Lake-tabellen, automatisk.

Hvor lang tid det tar å oppdatere tabellen, er relatert til hvor optimalisert Delta-tabellene er. Hvis du vil ha mer informasjon, kan du se gjennom tabelloptimalisering for Delta Lake og V-order for å lære mer om viktige scenarier, og en grundig veiledning om hvordan du effektivt opprettholder Delta-tabeller for maksimal ytelse.

Du kan manuelt fremtvinge en oppdatering av automatisk metadataskanning i Stoff-portalen. Velg Oppdater-knappen på Explorer-verktøylinjen for å oppdatere skjemaet på siden for SQL Analytics-endepunktet. Gå til Spørring i endepunktet for SQL-analyse, og se etter oppdateringsknappen, som vist i bildet nedenfor.

Skjermbilde fra Fabric-portalen som viser sql analytics-endepunktet Oppdater skjema-knappen.

Veiledning

  • Automatisk metadataoppdagelse sporer endringer som er forpliktet til lakehouses, og er en enkelt forekomst per Fabric-arbeidsområde. Hvis du observerer økt ventetid for at endringer skal synkroniseres mellom lakehouses og SQL Analytics-endepunkt, kan det skyldes et stort antall innsjøer i ett arbeidsområde. I et slikt scenario bør du vurdere å overføre hvert lakehouse til et eget arbeidsområde, da dette gjør at automatisk metadataoppdagelse kan skaleres.
  • Parkettfiler er uforanderlige etter utforming. Når det er en oppdatering eller en sletteoperasjon, vil en Delta-tabell legge til nye parquetfiler med endringene, noe som øker antall filer over tid, avhengig av hyppigheten av oppdateringer og slettinger. Hvis det ikke er planlagt vedlikehold, oppretter dette mønsteret til slutt en leseoversikt, og dette påvirker tiden det tar å synkronisere endringer til SQL Analytics-endepunktet. Hvis du vil løse dette, må du planlegge regelmessig vedlikehold av lakehouse-tabeller.
  • I noen scenarioer kan du se at endringer som er forpliktet til et lakehouse, ikke er synlige i det tilknyttede SQL Analytics-endepunktet. Du kan for eksempel ha opprettet en ny tabell i lakehouse, men den er ikke oppført i SQL Analytics-endepunktet. Du kan også ha forpliktet et stort antall rader til en tabell i et lakehouse, men disse dataene er ikke synlige i SQL Analytics-endepunktet. Vi anbefaler at du starter en behovsbetinget metadatasynkronisering, som utløses fra alternativet Oppdater bånd i SQL-spørringsredigeringsprogrammet. Dette alternativet tvinger en on-demand metadata synkronisering, i stedet for å vente på bakgrunnen metadata synkronisering for å fullføre.
  • Ikke alle Delta-funksjoner forstås av den automatiske synkroniseringsprosessen. Hvis du vil ha mer informasjon om funksjonaliteten som støttes av hver motor i Fabric, kan du se Delta Lake Interoperability.
  • Hvis det er en svært stor volumne av tabeller endringer under utpakking transformering og belastning (ETL) behandling, kan en forventet forsinkelse oppstå til alle endringene behandles.

Partisjonsstørrelseshensyn

Valget av partisjonskolonne for en deltatabell i et lakehouse påvirker også tiden det tar å synkronisere endringer i SQL Analytics-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. Vår anbefaling er å bruke en kolonne som vil resultere i en partisjon på minst (eller nær) 1 GB. Vi anbefaler at du følger anbefalte fremgangsmåter for vedlikehold av deltatabeller. optimalisering. Hvis du vil at et python-skript skal evaluere partisjoner, kan du 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 deltatabell av én eller flere grunner:

  • Hvis du velger en partisjon for en deltatabell med et høyt antall unike verdier, partisjoneres den av hver unike verdi og kan være overpartisjonert. Velg en partisjonskolonne som ikke har høy kardinalitet, og resulterer i individuell partisjonsstørrelse på minst 1 GB.
  • 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. Det kan for eksempel være lite antall endringer som kommer gjennom til lakehouse, og dette vil resultere i små parkettfiler. For å løse dette anbefaler vi at du implementerer regelmessig vedlikehold av lakehouse-bord.

Eksempelskript for partisjonsdetaljer

Bruk følgende notatblokk til å skrive ut en rapport som beskriver størrelse og detaljer for partisjoner som underbygger en deltatabell.

  1. Først må du angi ABSFF-banen for deltatabellen 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 sender ut alle partisjoner for deltatabellen.
  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.

Det fullstendige skriptet kan kopieres 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']}")

Relatert innhold