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. Den använder Fabric Data Warehouse-motorn.

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 medan SQL-analysändpunkten är aktiv och stannar efter 15 minuter utan frågeaktivitet.

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 kan starta on-demand metadata-synkronisering i Fabric-portalen eller använda Refresh SQL analytics endpoint metadata REST API.
• 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.

V-Order gynnar främst Power BI Direct Lake och, även om det kan förbättra komprimeringen för vissa arbetsbelastningar, är det generellt inte nödvändigt eller rekommenderat som standard för optimal prestanda för SQL-analysändpunkter.

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

Partitionslayouten påverkar hur lång tid SQL-analysändpunkten tar för att upptäcka och synka ändringar. Ett stort antal partitioner eller små Parquet-filer ökar overheaden vid skanning av metadata. Följ dessa metoder:

• Undvik partitionskolumner med hög kardinalitet, som kan skapa en partition för varje unikt värde. Välj en kolumn som producerar partitioner nära eller större än 1 GB. För mer information, se Delta Lake-tabellpartitionering.
• Batch- och streaminginsamling kan skapa små filer när ändringar är frekventa eller små. Använd underhåll av lakehouse-tabeller regelbundet för att komprimera dessa filer.

För att utvärdera storleken och filantalet för varje partition, använd exempelskriptet för partitionsdetaljer.

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

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