Zdieľať cez


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

Vzťahuje sa na:✅ Koncový bod analýzy SQL v službe Microsoft Fabric

Koncový bod analýzy SQL umožňuje dotazovať údaje v prostredí lakehouse pomocou jazyka T-SQL a protokolu TDS. 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 skenovanie domov pre zmeny a zabezpečovanie aktuálneho koncového bodu analýzy SQL pre všetky zmeny vykonané v službe lakehouse v pracovnom priestore. Proces synchronizácie je transparentne spravovaný platformou Microsoft Fabric. 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 času sa môže líšiť od niekoľkých sekúnd po minúty v závislosti od počtu faktorov, ktoré sú otrasné v tomto článku.

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

Koncový bod analýzy SQL spravuje automaticky generované tabuľky, takže používatelia pracovného priestoru ich nemôžu upravovať. Používatelia môžu obohatiť model databázy pridaním vlastných schém SQL, zobrazení, postupov a ďalších objektov databázy.

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. Informácie o typoch údajov automaticky generovanej schémy pre koncový bod analýzy SQL nájdete v téme Typy údajov v službe Microsoft Fabric.

Tabuľky v koncovom bode analýzy SQL sa vytvárajú s nepatrným oneskorením. Po vytvorení alebo aktualizácii tabuľky Delta Lake v jazere sa tabuľka koncového bodu analýzy SQL, ktorá odkazuje na tabuľku Delta lake, vytvorí/obnoví automaticky.

Čas potrebný na obnovenie tabuľky súvisí s tým, ako sú optimalizované tabuľky Delta. Ďalšie informácie nájdete v téme Optimalizácia tabuliek Delta Lake a poradie V, aby ste sa dozvedeli viac o kľúčových scenároch, a podrobnú príručku o tom, ako efektívne udržiavať tabuľky Delta na dosiahnutie maximálneho výkonu.

Obnovenie automatického skenovania metaúdajov na portáli služby Fabric môžete vynútiť manuálne. Na stránke koncového bodu analýzy SQL vyberte tlačidlo Obnoviť na paneli s nástrojmi Prieskumníka, čím obnovíte schému. Prejdite na položku Dotazovanie koncového bodu analýzy SQL a vyhľadajte tlačidlo obnovenia, ako je to znázornené na nasledujúcom obrázku.

Snímka obrazovky z portálu služby Fabric zobrazujúca tlačidlo na obnovenie schémy analýzy SQL.

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 sledujete zvýšené časové oneskorenie pri zmenách synchronizácie medzi jazerami a koncovým bodom analýzy SQL, môže to byť spôsobené veľkým počtom domov jazier v jednom pracovnom priestore. V takomto scenári zvážte migráciu jednotlivých úchytov jazera do samostatného pracovného priestoru, pretože to umožňuje škálovanie automatického vyhľadávania metaúdajov.
  • Parquet súbory sú nemenné podľa návrhu. Keď dôjde k aktualizácii alebo operácii odstránenia, tabuľka Delta pridá nové súbory s množinou zmien, čím sa zvýši počet súborov v priebehu času v závislosti od frekvencie aktualizácií a odstraňovania. Ak nie je k dispozícii žiadne naplánované údržby, tento vzor vytvorí režijné náklady na čítanie, čo má vplyv na čas potrebný na synchronizáciu zmien do koncového bodu analýzy SQL. Na vyriešenie tohto problému plánujete pravidelné operácie údržby tabuľky lakehouse.
  • V niektorých scenároch môžete pozorovať, že zmeny vykonané v službe LakeHouse nie sú viditeľné v súvisiacom koncovom bode analýzy SQL. Napríklad ste mohli vytvoriť novú tabuľku v objekte lakehouse, ale nie je uvedená v koncovom bode analýzy SQL. Prípadne ste zaviazali veľký počet riadkov k tabuľke v úchyte jazera, ale tieto údaje nie sú viditeľné v koncovom bode analýzy SQL. Odporúčame začať synchronizáciu metaúdajov na požiadanie, ktorá sa spustí pomocou možnosti obnoviť pás s nástrojmi editora dotazov SQL. Táto možnosť vynúti synchronizáciu metaúdajov na požiadanie, namiesto čakania na dokončenie synchronizácie metaúdajov na pozadí.
  • Nie všetkým funkciám Delta proces automatickej synchronizácie rozumie. Ďalšie informácie o funkciách podporovaných jednotlivými motormi v technológii Fabric nájdete v téme Delta Lake Interoperability.
  • Ak sa počas spracovania jazyka ETL (Extract Transform and Load) zmení veľmi veľký objem tabuliek, môže dôjsť k očakávanému oneskoreniu až do spracovania všetkých zmien.

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í. Odporúča sa použiť stĺpec, ktorý by mal za následok rozdelenie minimálne (alebo v blízkosti) 1 GB. Odporúčame postupovať podľa osvedčených postupov na údržbu delta tabuliek; optimalizácia. Informácie o skripte jazyka Python na vyhodnotenie oblastí nájdete v časti Ukážkový skript, kde nájdete podrobnosti o oblasti.

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 oblasť pre tabuľku delta s vysokým počtom jedinečných hodnôt, rozdelí sa podľa každej jedinečnej hodnoty a môže sa rozdeliť na viaceré oblasti. Vyberte stĺpec oblasti, ktorý nemá vysokú kardinalitu, a výsledkom bude veľkosť jednotlivých oblastí s veľkosťou aspoň 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, tam môže byť malý objem zmien prichádza do jazera, a to by malo za následok malé parketové súbory. Na riešenie tohto problému odporúčame zaviesť pravidelnú údržbu tabuľky lakehouse.

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.

  1. Najprv musíte zadať cestu ABSFF 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í.
  2. Skript bude výstupom všetkých oblastí pre delta tabuľku.
  3. Skript iteruje cez každú oblasť a vypočíta celkovú veľkosť a počet súborov.
  4. Výstupom skriptu sú podrobnosti o oblastiach, súboroch na oblasti a veľkosti na oblasť v GB.

Úplný skript je možné skopírovať z nasledujúceho bloku kódu:

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