Dela via

Prestandaöverväganden för SQL-analysslutpunkter

  • Artikel

Gäller för:✅ SQL-analysslutpunkt i Microsoft Fabric

Med SQL-analysslutpunkten kan du köra frågor mot data i lakehouse med T-SQL-språket och TDS-protokollet. Varje lakehouse har en SQL-analysslutpunkt. Antalet SQL-analysslutpunkter i en arbetsyta matchar antalet lakehouses och speglade databaser som etablerats på den arbetsytan.

En bakgrundsprocess ansvarar för att genomsöka Lakehouse efter ändringar och hålla SQL-analysslutpunkten uppdaterad för alla ändringar som har gjorts i lakehouses på en arbetsyta. Synkroniseringsprocessen hanteras transparent av Microsoft Fabric-plattformen. När en ändring identifieras i ett lakehouse uppdaterar en bakgrundsprocess metadata och SQL-analysslutpunkten återspeglar de ändringar som har gjorts i Lakehouse-tabeller. Under normala driftsförhållanden är fördröjningen mellan en lakehouse- och SQL-analysslutpunkt mindre än en minut.

Automatiskt genererat schema i SQL-analysslutpunkten för Lakehouse

SQL Analytics-slutpunkten hanterar de automatiskt genererade tabellerna så att arbetsytans användare inte kan ändra dem. Användare kan utöka databasmodellen genom att lägga till egna SQL-scheman, vyer, procedurer och andra databasobjekt.

För varje Delta-tabell i Lakehouse genererar SQL-analysslutpunkten automatiskt en tabell i dbo schemat. Information om automatiskt genererade schemadatatyper för SQL-analysslutpunkten finns i Datatyper i Microsoft Fabric.

Tabeller i SQL-analysslutpunkten skapas med en mindre fördröjning. När du har skapat eller uppdaterat Delta Lake-tabellen i sjön skapas/uppdateras sql-analysslutpunktstabellen som refererar till Delta Lake-tabellen automatiskt inom 10 sekunder.

Hur lång tid det tar att uppdatera tabellen är relaterad till hur optimerade Delta-tabellerna är. Mer information finns i Delta Lake-tabelloptimering och V-Order för att lära dig mer om viktiga scenarier och en djupgående guide om hur du effektivt underhåller Delta-tabeller för maximal prestanda.

Du kan framtvinga en uppdatering av den automatiska metadatagenomsökningen manuellt i Fabric-portalen. På sidan för SQL-analysslutpunkten väljer du knappen Uppdatera i explorer-verktygsfältet för att uppdatera schemat. Gå till Fråga din SQL-analysslutpunkt och leta efter uppdateringsknappen, som du ser i följande bild.

Skärmbild från Fabric-portalen som visar knappen Uppdateringsschema för SQL-analysslutpunkt.

Vägledning

  • Automatisk metadataidentifiering spårar ändringar som har checkats in i lakehouses och är en enda instans per infrastrukturarbetsyta. Om du observerar ökad svarstid för ändringar som ska synkroniseras mellan lakehouses och SQL-analysslutpunkten kan det bero på ett stort antal sjöhus på en arbetsyta. I ett sådant scenario bör du överväga att migrera varje lakehouse till en separat arbetsyta eftersom automatisk metadataidentifiering kan skalas.
  • Parquet-filer är oföränderliga avsiktligt. När det finns en uppdatering eller en borttagningsåtgärd lägger en Delta-tabell till nya parquet-filer med ändringsuppsättningen, vilket ökar antalet filer över tid, beroende på uppdaterings- och borttagningsfrekvensen. Om inget underhåll har schemalagts skapar det här mönstret så småningom läskostnader och det påverkar den tid det tar att synkronisera ändringar i SQL-analysslutpunkten. Du kan åtgärda detta genom att schemalägga regelbundna underhållsåtgärder för lakehouse-tabeller.
  • I vissa scenarier kan du observera att ändringar som görs i ett lakehouse inte visas i den associerade SQL-analysslutpunkten. Du kanske till exempel har skapat en ny tabell i Lakehouse, men den visas inte i SQL-analysslutpunkten. Eller så kanske du har checkat in ett stort antal rader i en tabell i ett lakehouse, men dessa data visas inte i SQL-analysslutpunkten. Vi rekommenderar att du initierar en metadatasynkronisering på begäran som utlöses från menyfliksalternativet Uppdatera i SQL-frågeredigeraren. Det här alternativet tvingar fram en synkronisering av metadata på begäran i stället för att vänta på att synkroniseringen av bakgrundsmetadata ska slutföras.

Överväganden för partitionsstorlek

Valet av partitionskolumn för en deltatabell i ett lakehouse påverkar också den tid det tar att synkronisera ändringar i SQL-analysslutpunkten. Antalet och storleken på partitioner i partitionskolumnen är viktiga för prestanda:

  • En kolumn med hög kardinalitet (mestadels eller helt gjord av unika värden) resulterar i ett stort antal partitioner. Ett stort antal partitioner påverkar prestandan för metadataidentifieringssökningen negativt efter ändringar. Om kardinaliteten för en kolumn är hög väljer du en annan kolumn för partitionering.
  • Storleken på varje partition kan också påverka prestanda. Vår rekommendation är att använda en kolumn som skulle resultera i en partition på minst (eller nära) 1 GB. Vi rekommenderar att du följer metodtipsen för underhåll av deltatabeller. optimering. Ett Python-skript för att utvärdera partitioner finns i Exempelskript för partitionsinformation.

En stor mängd små parquet-filer ökar den tid det tar att synkronisera ändringar mellan en lakehouse och dess associerade SQL-analysslutpunkt. Du kan få ett stort antal parquet-filer i en deltatabell av en eller flera skäl:

  • Om du väljer en partition för en deltatabell med ett stort antal unika värden partitioneras den efter varje unikt värde och kan vara överpartitionerad. Välj en partitionskolumn som inte har hög kardinalitet och resulterar i en enskild partitionsstorlek på minst 1 GB.
  • Datainmatningshastigheter för batch- och direktuppspelning kan också resultera i små filer beroende på frekvens och storlek på ändringar som skrivs till ett sjöhus. Det kan till exempel finnas en liten mängd ändringar som kommer till lakehouse och detta skulle resultera i små parquet-filer. För att åtgärda detta rekommenderar vi att du implementerar regelbundet underhåll av lakehouse-tabeller.

Exempelskript för partitionsinformation

Använd följande notebook-fil för att skriva ut en rapport med information om storlek och information om partitioner som ligger till grund för en deltatabell.

  1. Först måste du ange ABSFF-sökvägen för deltatabellen i variabeln delta_table_path.
    • Du kan hämta ABFSS-sökvägen till en deltatabell från Infrastrukturportalutforskaren. Högerklicka på tabellnamnet och välj COPY PATH sedan i listan med alternativ.
  2. Skriptet matar ut alla partitioner för deltatabellen.
  3. Skriptet itererar genom varje partition för att beräkna den totala storleken och antalet filer.
  4. Skriptet matar ut information om partitioner, filer per partitioner och storlek per partition i GB.

Det fullständiga skriptet kan kopieras från följande kodblock:

# 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']}")

Relaterat innehåll