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.

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 Microsoft Fabric transparentne spravuje 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ží iba vtedy, keď je SQL analytics endpoint aktívny a zastaví sa po 15 minútach nečinnosti.

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áte možnosť spustiť synchronizáciu metadát na požiadanie.
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.

Veľké množstvo malých súborov Parquet vytvára režijné náklady a negatívne ovplyvňuje výkon dotazov. Aby ste zabezpečili predvídateľný a efektívny výkon, udržiavajte ukladanie tabuliek tak, aby každý súbor Parquet obsahoval dva milióny riadkov. Tento počet riadkov poskytuje vyváženú úroveň paralelizmu bez toho, aby sa dátová množina roztrieštila na príliš malé rezy.

Okrem riadenia počtu riadkov je rovnako dôležitá aj veľkosť súboru. SQL analytický endpoint funguje najlepšie, keď sú súbory Parquet dostatočne veľké na minimalizáciu režijných nákladov na spracovanie súborov, ale nie také veľké, aby obmedzovali efektivitu paralelného skenovania. Pre väčšinu pracovných záťaží je najlepšie udržiavať jednotlivé Parquet súbory blízke 400 MB. Na dosiahnutie tejto rovnováhy použite nasledujúce kroky:

Nastavte maxRecordsPerFile na 2 000 000 pred zmenou dát.
Vykonávajte zmeny dát (príjem, aktualizácie, vymazania).
Nastavte maxFileSize na 4 GB.
Spustite príkaz OPTIMIZE. Podrobnosti o používaní OPTIMIZEnájdete v článku Údržba stola z Lakehouse.

Nasledujúci skript poskytuje šablónu pre tieto kroky a mal by sa vykonať na jazernom dome:

from delta.tables import DeltaTable

# 1. CONFIGURE LIMITS

# Cap files to 2M rows during writes. This should be done before data ingestion occurs. 
spark.conf.set("spark.sql.files.maxRecordsPerFile", 2000000)

# 2. INGEST DATA
# Here, you ingest data into your table 

# 3. CAP FILE SIZE (~4GB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 4 * 1024 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Na udržanie zdravých veľkostí súborov pravidelne spúšťajte optimalizačné operácie Delta, ako napríklad OPTIMIZE, najmä pre tabuľky, ktoré dostávajú časté inkrementálne vkladanie, aktualizácie a mazanie. Tieto údržbové operácie kompaktujú malé súbory do primerane veľkých, čo pomáha zabezpečiť, že SQL analytický endpoint dokáže efektívne spracovávať dotazy. Na inteligentnú optimalizáciu tabuliek, ktoré vyžadujú údržbu, použite dátový pipeline a uloženú sys.sp_get_table_health_metrics proceduru T-SQL na určenie, kedy tabuľka potrebuje príkaz.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

Výber stĺpca oblasti pre delta tabuľky v lakehouse má tiež vplyv na čas potrebný na synchronizáciu zmien koncového bodu analýzy SQL. Počet a veľkosť oblastí stĺpca oblasti sú dôležité pre výkon:

Stĺpec s vysokou kardinalitou (väčšinou alebo úplne vyrobený z jedinečných hodnôt) má za následok veľký počet oblastí. Veľký počet oblastí negatívne ovplyvňuje výkon vyhľadávania metaúdajov v rámci vyhľadávania zmien. Ak je kardinalita stĺpca vysoká, vyberte iný stĺpec na rozdelenie.
Výkon môže ovplyvniť aj veľkosť jednotlivých oblastí. Použi stĺpec, ktorý vytvorí partíciu aspoň (alebo blízko) 1 GB. Dodržiavajte najlepšie postupy pri údržbe a optimalizácii delta tabuliek. Pre Python skript na vyhodnotenie partícií pozri Sample script pre detaily partícií.

Veľký objem malých parketových súborov zvyšuje čas potrebný na synchronizáciu zmien medzi jazerom a súvisiacim koncovým bodom analýzy SQL. Veľký počet súboroch na parketoch môžete mať v delta tabuľke z jedného alebo viacerých dôvodov:

Ak vyberiete partíciu pre tabuľku Delta s vysokým počtom unikátnych hodnôt, tabuľka je rozdelená podľa každej jedinečnej hodnoty a môže byť nadmerne rozdelená. Vyberte stĺpec oblasti, ktorý nemá vysokú kardinalitu, a výsledkom bude, že každá z oblastí bude mať veľkosť minimálne 1 GB.
Miera príjmu údajov šarží a streamovania môže mať za následok aj malé súbory v závislosti od frekvencie a veľkosti zmien zapísaných do útla Lakehouse. Napríklad môže prejsť, že do jazerného domu prichádza malý objem zmien, čo vedie k malým parketovým súborom. Aby ste tento problém vyriešili, zavádzajte pravidelnú údržbu stolov v jazerných domčekoch.

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

Na tlač zostavy s podrobnosťami o veľkosti a podrobnostiach oblastí, ktoré sú základom delta tabuľky, použite nasledujúci poznámkový blok.

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 bude výstupom všetkých oblastí pre delta tabuľku.
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']}")

Automaticky generovaná schéma v koncovom bode analýzy SQL služby Lakehouse

Pre každú tabuľku Delta v službe Lakehouse koncový bod analýzy SQL automaticky vygeneruje tabuľku v príslušnej schéme. SQL analytický endpointový engine je založený na Fabric Data Warehouse engine.

Pre viac informácií pozri synchronizáciu metadát koncových bodov SQL analytics. Môžete tiež programovo vynútiť obnovenie automatického skenovania metadát pomocou REST API metadát Refresh SQL endpoint.

Pripomienky

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

Last updated on 2026-05-26