Dôležité informácie o výkone koncového bodu analýzy SQL

SQL analytický endpoint vám umožňuje dotazovať dáta v lakehouse pomocou jazyka T-SQL a protokolu TDS. Využíva Fabric Data Warehouse motor.

Tip

Pre komplexné usmernenia o optimalizácii Delta tabuliek pre spotrebu SQL analytických koncových bodov, vrátane odporúčaní veľkosti súboru a skupín riadkov, pozri Údržba a optimalizácia tabuliek naprieč záťažami.

Každý domov jazera má jeden koncový bod analýzy SQL. Počet koncových bodov analýzy SQL v pracovnom priestore zodpovedá počtu domov jazera a zrkadlových databáz poskytovaných v tomto jednom pracovnom priestore.

Proces na pozadí je zodpovedný za prehľadávanie lakehouse kvôli zmenám a udržiavanie SQL analytics endpointu up-todátume pre všetky zmeny uložené v lakehouse v pracovnom priestore. Platforma Fabric transparentne riadi proces synchronizácie. Keď sa v objekte lakehouse zistí zmena, proces na pozadí aktualizuje metaúdaje a koncový bod analýzy SQL odráža zmeny vykonané v tabuľkách lakehouse. Za bežných prevádzkových podmienok je oneskorenie medzi koncovým bodom služby Lakehouse a analýzou SQL menšie ako minútu. Skutočná dĺžka trvania sa môže líšiť od niekoľkých sekúnd až po minúty v závislosti od mnohých faktorov, ktoré tento článok rozoberá. Proces na pozadí beží, kým je SQL analytics endpoint aktívny, a zastaví sa po 15 minútach bez aktivity dotazov.

Sprievodný materiál

Automatické vyhľadávanie metaúdajov sleduje zmeny vykonané v objektoch lakehouse a je jedinou inštanciou na pracovný priestor služby Fabric. Ak si všimnete zvýšenú latenciu pri zmenách synchronizácie medzi lakehouse a SQL analytics endpointom, môže to byť spôsobené veľkým počtom lakehouse v jednom pracovnom priestore. V takomto prípade zvážte migráciu každého jazerného domu do samostatného pracovného priestoru, pretože tento prístup umožňuje automatické objavovanie metadát škálovať.
Parquet súbory sú nemenné podľa návrhu. Keď prebieha aktualizácia alebo operácia vymazania, tabuľka Delta pridáva nové súbory Parquet so sadou zmien, čo časom zvyšuje počet súborov v závislosti od frekvencie aktualizácií a vymazaní. Ak neplánujete údržbu, tento vzorec nakoniec vytvorí režijné náklady na čítanie a táto podmienka ovplyvňuje čas potrebný na synchronizáciu zmien do SQL analytics endpointu. Aby ste tento problém vyriešili, naplánujte pravidelné údržbárske operácie na stole pri jazere.
V niektorých situáciách si môžete všimnúť, že zmeny uložené v lakehouse nie sú viditeľné v príslušnom SQL analytickom endpointe. Napríklad môžete vytvoriť novú tabuľku v lakehouse, ale ešte nie je uvedená v SQL analytics endpointe. Alebo môžete commitovať veľký počet riadkov do tabuľky v lakehouse, ale tieto dáta ešte nie sú viditeľné v SQL analytics endpointe. Môžete spustiť synchronizáciu metadát na požiadanie v Fabric portáli alebo použiť REST API metadát Refresh SQL analytics endpoint.
Proces automatickej synchronizácie nepodporuje všetky funkcie Delty. Ďalšie informácie o funkciách podporovaných jednotlivými motormi v technológii Fabric nájdete v téme Interoperabilita formátu tabuľky Delta Lake.
Ak počas spracovania Extract Transform and Load (ETL) dôjde k extrémne veľkému množstvu zmien v tabuľke, očakáva sa oneskorenie, kým sa všetky zmeny spracujú.

Optimalizácia lakehouse tabuliek na dotazovanie SQL analytics endpointu

Keď SQL analytický endpoint číta tabuľky uložené v lakehouse, výkon dotazov závisí výrazne od fyzického rozloženia podkladových súborov Parquet. Engine paralelizuje skeny na úrovni súboru Parquet. Príliš veľa malých súborov zvyšuje režijné náklady na súbory a metadáta, zatiaľ čo príliš málo veľkých súborov môže obmedziť paralelizmus skenovania.

Pre tabuľky písané Sparkom použite predvolené nastavenia v runtime Fabric Spark 2.0 alebo novšom. Tieto runtime umožňujú adaptívnu cieľovú veľkosť súboru v predvolenom nastavení na výber najoptimálnejšej cieľovej veľkosti súboru podľa tabuľky, od 128 MB pre menšie tabuľky až po 1 GB pre najväčšie tabuľky. Vyhnite sa nastavovaniu statických cieľov alebo ľubovoľného limitu počtu riadkov nad predvolenými konfiguráciami. Limit riadkov nezohľadňuje šírku riadku a môže vytvárať malé súbory pre úzke tabuľky.

Ak používate Fabric Spark runtime 1.3, povolte adaptívne cieľové ciele veľkosti súboru a úrovne kompakcie súboru, ktoré sú dostupné ako voliteľné funkcie.

V-Order primárne využíva Power BI Direct Lake a hoci môže zlepšiť kompresiu pre niektoré pracovné záťaže, vo všeobecnosti nie je štandardne povinný ani odporúčaný pre optimálny výkon SQL analytických koncových bodov.

Predvolené nastavenia zápisu nenahrádzajú údržbu stolov. Použite nasledujúce postupy na zachovanie zdravého rozloženia pri zmene tabuliek:

Zapnite automatickú kompakciu pre pracovné záťaže, kde je periodicky pridaná synchronná latencia zápisu prijateľná. Automatická kompakcia je funkcia Sparku, ktorá sa spustí len vtedy, keď je v tabuľke príliš veľa malých súborov.
Plánujte periodické úlohy OPTIMIZE pre pracovné zaťaženia, kde periodická pridaná latencia z automatickej kompaktácie nespĺňa SLA aktualizácie dát.
Postupujte VACUUM podľa požiadaviek na uchovávanie a cestovanie v čase, aby ste odstránili súbory, na ktoré sa Delta log už neodkazuje. VACUUM znižuje zachované úložisko, ale nezlepšuje aktívne rozloženie súboru.
Vyhnite sa rozdeleniu s vysokou kardinálnosťou a prispôsobeným konfiguráciám zapisovača, ktoré vytvárajú veľa malých súborov.

Ak nepoužívate automatickú kompakciu, na identifikáciu tabuliek, ktoré potrebujú údržbu, použite dátový pipeline a uloženú sys.sp_get_table_health_metrics procedúru T-SQL pred spustením OPTIMIZE. Pre návod pozri Optimalizovať tabuľky Lakehouse na základe zdravotných kontrol.

Poznámka

Pre rady o všeobecnej údržbe stolov lakehouse pozri Údržba stolov behu od Lakehouse.

Dôležité informácie týkajúce sa veľkosti oblasti

Rozloženie partície ovplyvňuje, ako dlho trvá SQL analytickému endpointu na objavenie a synchronizáciu zmien. Veľký počet partícií alebo malých súborov Parquet zvyšuje režijné náklady na skenovanie metadát. Dodržujte tieto postupy:

Vyhnite sa stĺpcom rozdelenia s vysokou kardinálnosťou, ktoré môžu vytvoriť partíciu pre každú jedinečnú hodnotu. Vyberte stĺpec, ktorý vytvára partície blízke alebo väčšie ako 1 GB. Pre viac informácií pozri Delta Lake tabuľkové rozdelenie.
Dávkové a streamovanie môže vytvárať malé súbory, keď sú zmeny časté alebo malé. Na zhutnenie týchto súborov používajte pravidelnú údržbu stola v lakehouse .

Na vyhodnotenie veľkosti a počtu súborov každej partície použite vzorový skript pre detaily partície.

Ukážkový skript s podrobnosťami o oblasti

Použite nasledujúci zápisník na vytlačenie správy, ktorá podrobne popisuje veľkosť a detaily partícií, na ktorých stojí tabuľka Delta.

Najprv poskytnite ABFSS cestu pre vašu Delta tabuľku v premennej delta_table_path.
- Cestu ABFSS k tabuľke delta môžete získať z portálu Explorera služby Fabric. Kliknite pravým tlačidlom myši na názov tabuľky a potom vyberte COPY PATH zo zoznamu možností.
Skript generuje všetky partície pre tabuľku Delta.
Skript iteruje cez každú oblasť a vypočíta celkovú veľkosť a počet súborov.
Výstupom skriptu sú podrobnosti o oblastiach, súboroch na oblasti a veľkosti na oblasť v GB.

Kompletný skript môžete skopírovať z nasledujúceho kódového bloku:

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

Pripomienky

Bola táto stránka užitočná?

Last updated on 2026-09-16