Důležité informace o výkonu koncového bodu SQL Analytics

Platí pro:✅ Koncový bod analýzy SQL v Microsoft Fabric

Koncový bod analýzy SQL umožňuje dotazovat se na data v lakehouse pomocí jazyka T-SQL a protokolu TDS. Každý lakehouse má jeden koncový bod analýzy SQL. Počet koncových bodů analýzy SQL v pracovním prostoru odpovídá počtu lakehouse a zrcadlených databází zřízených v daném pracovním prostoru.

Proces na pozadí zodpovídá za kontrolu změn v jezeře a udržování koncového bodu SQL Analytics v aktualizovaném stavu pro všechny změny provedené v lakehouse v pracovním prostoru. Proces synchronizace je transparentně spravovaný platformou Microsoft Fabric. Když se v objektu lakehouse zjistí změna, proces na pozadí aktualizuje metadata a koncový bod analýzy SQL odráží změny potvrzené v tabulkách lakehouse. Za normálních provozních podmínek je prodleva mezi koncovým bodem služby Lakehouse a SQL Analytics menší než jedna minuta. Skutečná doba se může lišit od několika sekund po minuty v závislosti na řadě faktorů, které jsou v tomto článku dicussed.

Automaticky vygenerované schéma v koncovém bodu analýzy SQL lakehouse

Koncový bod analýzy SQL spravuje automaticky generované tabulky, aby je uživatelé pracovního prostoru nemohli upravovat. Uživatelé můžou databázový model rozšířit přidáním vlastních schémat SQL, zobrazení, procedur a dalších databázových objektů.

Pro každou tabulku Delta ve vašem Lakehouse koncový bod analýzy SQL automaticky vygeneruje tabulku v příslušném schématu. Datové typy automaticky generovaného schématu pro koncový bod analýzy SQL najdete v tématu Datové typy v Microsoft Fabric.

Tabulky v koncovém bodu analýzy SQL se vytvářejí s menším zpožděním. Po vytvoření nebo aktualizaci tabulky Delta Lake v jezeře se automaticky vytvoří nebo aktualizuje tabulka koncových bodů SQL Analytics, která odkazuje na tabulku Delta Lake.

Doba potřebnou k aktualizaci tabulky souvisí s tím, jak jsou optimalizované tabulky Delta. Další informace najdete v tématu Optimalizace tabulek Delta Lake a pořadí V-Order , kde najdete další informace o klíčových scénářích a podrobném průvodci efektivním udržováním tabulek Delta pro maximální výkon.

Aktualizaci automatické kontroly metadat můžete na portálu Fabric vynutit ručně. Na stránce koncového bodu analýzy SQL vyberte tlačítko Aktualizovat na panelu nástrojů Průzkumníka a aktualizujte schéma. Přejděte na dotaz na koncový bod analýzy SQL a vyhledejte tlačítko aktualizace, jak je znázorněno na následujícím obrázku.

Pokyny

• Automatické zjišťování metadat sleduje změny potvrzené ve službě Lakehouses a je to jedna instance na pracovní prostor Fabric. Pokud pozorujete zvýšenou latenci při synchronizaci změn mezi lakehousemi a koncovým bodem analýzy SQL, může to být způsobeno velkým počtem jezer v jednom pracovním prostoru. V takovém scénáři zvažte migraci jednotlivých jezer do samostatného pracovního prostoru, protože to umožňuje automatické zjišťování metadat ke škálování.
• Soubory Parquet jsou neměnné podle návrhu. Když dojde k aktualizaci nebo operaci odstranění, tabulka Delta přidá nové soubory parquet se sadou změn, což v závislosti na četnosti aktualizací a odstranění zvýší počet souborů v průběhu času. Pokud není naplánovaná údržba, nakonec tento model vytvoří režii čtení a to má vliv na dobu potřebnou k synchronizaci změn do koncového bodu analýzy SQL. Pokud chcete tento postup vyřešit, naplánujte pravidelné operace údržby tabulek lakehouse.
• V některých scénářích můžete vidět, že změny potvrzené do lakehouse nejsou viditelné v přidruženém koncovém bodu analýzy SQL. Mohli jste například vytvořit novou tabulku v lakehouse, ale není uvedená v koncovém bodu analýzy SQL. Nebo jste do tabulky v jezeře potvrdili velký počet řádků, ale tato data se v koncovém bodu analýzy SQL nezobrazují. Doporučujeme zahájit synchronizaci metadat na vyžádání aktivovanou z možnosti Aktualizovat pás karet editoru dotazů SQL. Tato možnost vynutí synchronizaci metadat na vyžádání a nečeká na dokončení synchronizace metadat na pozadí.
• Ne všechny funkce Delta jsou srozumitelné procesem automatické synchronizace. Další informace o funkcích podporovaných jednotlivými moduly v prostředcích infrastruktury najdete v tématu Delta Lake Interoperability.
• Pokud během zpracování extrakce transformace a načítání (ETL) dojde k extrémně velkému volumnu tabulek, může dojít k očekávanému zpoždění, dokud se nezpracují všechny změny.

Důležité informace o velikosti oddílů

Volba sloupce oddílu pro rozdílovou tabulku v lakehouse má vliv také na dobu potřebnou k synchronizaci změn koncového bodu analýzy SQL. Počet a velikost oddílů sloupce oddílu jsou důležité pro výkon:

• Sloupec s vysokou kardinalitou (většinou nebo zcela tvořený jedinečnými hodnotami) má za následek velký počet oddílů. Velký počet oddílů má negativní vliv na výkon zjišťování metadat, ve které se hledají změny. Pokud je kardinalita sloupce vysoká, zvolte jiný sloupec pro dělení.
• Velikost každého oddílu může mít vliv také na výkon. Naším doporučením je použít sloupec, který by způsoboval alespoň (nebo blízko) oddílu 1 GB. Doporučujeme postupovat podle osvědčených postupů pro údržbu tabulek delta; optimalizace. Skript Pythonu pro vyhodnocení oddílů najdete v ukázkovém skriptu s podrobnostmi o oddílu.

Velký objem malých souborů parquet zvyšuje dobu potřebnou k synchronizaci změn mezi lakehousem a přidruženým koncovým bodem analýzy SQL. V tabulce Delta můžete skončit s velkým počtem souborů parquet z jednoho nebo více důvodů:

• Pokud zvolíte oddíl pro rozdílovou tabulku s vysokým počtem jedinečných hodnot, rozdělí se podle každé jedinečné hodnoty a může být předělaná. Zvolte sloupec oddílu, který nemá vysokou kardinalitu, a výsledkem je velikost jednotlivých oddílů alespoň 1 GB.
• Frekvence dávkového a streamovaného příjmu dat může také vést k malým souborům v závislosti na četnosti a velikosti změn, které se zapisují do jezera. Může se například jednat o malý objem změn přicházejících do jezera a výsledkem by byly malé soubory parquet. Pokud chcete tento postup vyřešit, doporučujeme implementovat pravidelnou údržbu tabulek lakehouse.

Ukázkový skript pro podrobnosti oddílu

Pomocí následujícího poznámkového bloku můžete vytisknout velikost sestavy s podrobnostmi a podrobnosti oddílů, které tvoří základ tabulky Delta.

1. Nejprve je nutné zadat cestu ABSFF pro tabulku delta v proměnné delta_table_path.
   • Cestu ABFSS tabulky Delta můžete získat z Průzkumníka portálu Fabric. Klikněte pravým tlačítkem myši na název tabulky a pak vyberte COPY PATH ze seznamu možností.
2. Skript vypíše všechny oddíly tabulky Delta.
3. Skript prochází jednotlivé oddíly a vypočítá celkovou velikost a počet souborů.
4. Skript vypíše podrobnosti o oddílech, souborech na oddíly a velikosti na oddíl v GB.

Úplný skript lze zkopírovat z následujícího 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']}")

Související obsah

• Lepší společně: jezero a sklad
• Pokyny k výkonu datového skladu Synapse v Microsoft Fabric
• Omezení koncového bodu SQL Analytics