Prestandaöverväganden för SQL-analysslutpunkter

Med SQL-analysslutpunkten kan du köra frågor mot data i lakehouse med hjälp av T-SQL-språket och TDS-protokollet.

Varje lakehouse har en SQL-analysslutpunkt. Antalet SQL-analysslutpunkter i en arbetsyta matchar antalet lakehouses och etablerade speglade databaser i den aktuella arbetsytan.

En bakgrundsprocess ansvarar för att genomsöka lakehouset efter ändringar och hålla SQL-analysslutpunkten uppdaterad med alla ändringar som checkas in i lakehouses i en arbetsyta. Fabric-plattformen hanterar synkroniseringsprocessen transparent. 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. Den faktiska tiden kan variera från några sekunder till minuter beroende på många faktorer som beskrivs i den här artikeln. Bakgrundsprocessen körs bara när SQL-analysslutpunkten är aktiv och stoppas efter 15 minuters inaktivitet.

Guidance

• Automatisk metadataupptäckt spårar ändringar som har godkänts i lakehouses och är en enda instans per Fabric-arbetsyta. Om du märker ökad latens för att ändringar synkroniseras mellan lakehouses och SQL-analysslutpunkten kan det bero på ett stort antal lakehouses i en arbetsyta. I en sådan situation bör du överväga att migrera varje lakehouse till en separat arbetsyta, eftersom detta tillvägagångssätt gör att automatisk identifiering av metadata kan skalas upp.
• Parquet-filer är oföränderliga genom design. 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å frekvensen för uppdateringar och borttagningar. Om du inte schemalägger underhåll skapar det här mönstret så småningom en ökad läsbelastning, och detta påverkar hur lång tid det tar att synkronisera ändringar till SQL Analytics-slutpunkten. Du kan åtgärda det här problemet 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 kan till exempel skapa en ny tabell i Lakehouse, men den visas ännu inte i SQL-analysslutpunkten. Eller så kan du skriva ett stort antal rader till en tabell i ett lakehouse, men de här uppgifterna är ännu inte synliga i SQL-analysslutpunkten. Du har möjlighet att starta metadatasynkronisering på begäran.
• Den automatiska synkroniseringsprocessen stöder inte alla Delta-funktioner. Mer information om de funktioner som stöds av varje motor i Fabric finns i samverkan med Delta Lake-tabellformat.
• Om det finns en mycket stor mängd tabelländringar under ETL-bearbetningen (Extract Transform and Load) inträffar en förväntad fördröjning tills alla ändringar bearbetas.

Optimera lakehouse-tabeller för att köra frågor mot SQL-analysslutpunkten

När SQL-analysslutpunkten läser tabeller som lagras i ett lakehouse beror frågeprestandan mycket på den fysiska layouten för de underliggande Parquet-filerna. Motorn parallelliserar skanningar på Parquet-filnivå. För många små filer ökar fil- och metadata-överhead, medan för få stora filer kan begränsa skanningsparallellismen.

För tabeller skrivna av Spark, använd standardinställningarna i Fabric Spark runtime 2.0 eller senare. Dessa runtimes möjliggör adaptiv målfilstorlek som standard för att välja den mest optimala målfilstorleken per tabell, från 128 MB för mindre tabeller upp till 1 GB för de största tabellerna. Undvik att sätta statiska mål eller godtyckliga radbegränsningar ovanpå standardkonfigurationerna. En radgräns tar inte hänsyn till radbredd och kan skapa små filer för smala tabeller.

Om du använder Fabric Spark runtime 1.3, aktivera adaptiv målfilstorlek och filnivåkompaktionsmål, som finns som opt-in-funktioner.

Du behöver inte V-Order för att förbättra prestandan för SQL-analysslutpunkter, eftersom Spark skriver Parquet-filer som Snappy-komprimeras för att minska både läs- och skriv-I/O.

Standardinställningar för skriv ersätter inte tabellunderhåll. Använd följande metoder för att bevara en hälsosam layout när tabellerna ändras:

• Aktivera automatisk komprimering för arbetsbelastningar där den periodiska tillkomna synkrona skrivlatensen är acceptabel. Automatisk komprimering är en Spark-funktion som bara körs när det finns för många små filer i en tabell.
• Schemalägg periodiska OPTIMIZE jobb för arbetsbelastningar där den periodiska extra latensen från automatisk komprimering inte uppfyller datauppdaterings-SLAs.
• Kör VACUUM enligt dina krav på lagring och tidsresor för att ta bort filer som Delta-loggen inte längre refererar till. VACUUM minskar behållen lagring men förbättrar inte den aktiva fillayouten.
• Undvik partitionering med hög kardinalitet och anpassade skrivarkonfigurationer som skapar många små filer.

Om du inte använder automatisk kompaktering använder du en datapipeline och den T-SQL-lagrade proceduren sys.sp_get_table_health_metrics för att identifiera tabeller som behöver underhåll innan du kör OPTIMIZE. Mer information finns i Optimera Lakehouse-tabeller baserat på hälsokontroller.

Överväganden för partitionsstorlek

Valet av partitionskolumn för en Delta-tabell i ett lakehouse påverkar också tiden det tar att synkronisera ändringar till SQL-analysändpunkten. 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. Använd en kolumn som resulterar i en partition på minst (eller nära) 1 GB. Följ bästa praxis för underhåll och partitionering av Delta-tabeller. För ett Python-skript för att utvärdera partitioner, se 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 sluta med ett stort antal Parquet-filer i en Delta-tabell av en eller flera anledningar:

• Om du väljer en partition för en Delta-tabell med ett stort antal unika värden partitioneras tabellen efter varje unikt värde och kan vara överpartitionerad. Välj en partitionskolumn som inte har hög kardinalitet och resulterar i enskilda partitioner minst 1 GB vardera.
• 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, vilket resulterar i små parquet-filer. Åtgärda problemet genom att implementera regelbundet underhåll av lakehouse-tabeller.

Exempelskript för partitionsinformation

Använd följande anteckningsbok för att skriva ut en rapport som beskriver storlek och detaljer om partitioner som ligger till grund för en Delta-tabell.

1. Först, ange ABFSS-sökvägen för din Delta-tabell i variabeln delta_table_path.
   • Du kan hämta ABFSS-sökvägen till en deltatabell från Fabric Portalutforskaren. Högerklicka på tabellnamnet och välj COPY PATH sedan i listan med alternativ.
2. Skriptet ger utdata till alla partitioner för Delta-tabellen.
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.

Du kan kopiera hela skriptet 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']}")

Automatiskt genererat schema i SQL-analysslutpunkten för Lakehouse

För varje Delta-tabell i Lakehouse genererar SQL-analysslutpunkten automatiskt en tabell i lämpligt schema. Motorn för SQL-analysslutpunkten baseras på motorn för Fabric Data Warehouse.

Mer information finns i SQL Analytics-slutpunktsmetadatasynkronisering. Du kan också programmatiskt framtvinga en uppdatering av den automatiska metadatagenomsökningen med rest-API:et Uppdatera SQL-slutpunktsmetadata.

Relaterat innehåll

• Underhåll och optimering av tabeller över olika arbetsbelastningar
• Delta Lake-tabelloptimering och V-ordning
• Tabellkomprimering
• Anpassa filstorlek
• Användningsfall för Lakehouse SQL-analysslutpunkter