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

Koncový bod analýzy SQL umožňuje dotazovat se na data v lakehouse pomocí jazyka T-SQL a protokolu TDS. Využívá Fabric Data Warehouse engine.

Tip

Komplexní pokyny pro různé úlohy týkající se optimalizace tabulek Delta pro spotřebu koncových bodů analýzy SQL, včetně doporučení velikosti souborů a skupin řádků, najdete v tématu Údržba a optimalizace tabulek napříč úlohami.

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 vyhledávání změn v lakehouse a za udržování koncového bodu analýz SQL v aktuálním stavu pro všechny změny potvrzené v lakehousech v pracovním prostoru. Platforma Fabric transparentně řídí synchronizační proces. 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 mnoha faktorech, které tento článek popisuje. Proces na pozadí běží, zatímco je aktivní SQL analytics endpoint, a po 15 minutách bez dotazovací aktivity končí.

Doprovodné materiály

Automatické zjišťování metadat sleduje změny potvrzené ve službě Lakehouses a je to jedna instance na pracovní prostor Fabric. Pokud zaznamenáte zvýšenou prodlevu při synchronizaci změn mezi lakehousey a koncovým bodem analytiky SQL, může to být způsobeno velkým počtem lakehouseů 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 tento přístup umožňuje škálování automatického zjišťování metadat.
Soubory Parquet jsou ze své podstaty neměnné. Když dojde k aktualizaci nebo operaci odstranění, přidá tabulka Delta nové soubory Parquet se sadou změn, což v závislosti na frekvenci aktualizací a odstranění zvýší počet souborů v průběhu času. Pokud neplánujete údržbu, tento postup nakonec způsobí režii při čtení a tento stav ovlivní dobu potřebnou k synchronizaci změn do koncového bodu analýz SQL. Pokud chcete tento problém vyřešit, naplánujte pravidelné operace údržby tabulek lakehouse.
V některých scénářích můžete zjistit, že změny provedené v lakehouse nejsou viditelné v přidruženém analytickém koncovém bodu SQL. Můžete například vytvořit novou tabulku v lakehouse, ale zatím není uvedena v koncovém bodu pro analýzy SQL. Nebo můžete do tabulky v lakehouse zapsat velké množství řádků, ale tato data ještě nejsou viditelná v koncovém bodu analytiky SQL. Můžete v portálu Fabric spustit synchronizaci metadat na vyžádání nebo použít REST API pro aktualizaci metadat koncového bodu SQL Analytics.
Proces automatické synchronizace nepodporuje všechny funkce Delta. Další informace o funkcích podporovaných jednotlivými enginy v Fabricu najdete v tématu Interoperabilita formátů tabulek Delta Lake.
Pokud během zpracování extrakce, transformace a načítání (ETL) dojde k mimořádně velkému objemu změn v tabulkách, dochází k očekávanému zpoždění, dokud nejsou zpracovány všechny změny.

Optimalizace tabulek lakehouse pro dotazování na koncový bod analýzy SQL

Když koncový bod SQL Analytics čte tabulky uložené v jezeře, výkon dotazů výrazně závisí na fyzickém rozložení podkladových souborů Parquet. Modul paralelizuje prohledávání na úrovni souborů Parquet. Příliš mnoho malých souborů zvyšuje režii spojenou se soubory a metadaty, zatímco příliš málo velkých souborů může omezit paralelismus při skenování.

Pro tabulky psané Sparkem použijte výchozí nastavení v Fabric Spark runtime 2.0 nebo novějším. Tyto runtime umožňují adaptivní velikost cílového souboru ve výchozím nastavení pro výběr nejoptimálnější velikosti cílového souboru podle tabulky, od 128 MB pro menší tabulky až po 1 GB pro největší tabulky. Vyhněte se nastavování statických cílů nebo libovolného limitu počtu řádků nad výchozími konfiguracemi. Limit řádků nezohledňuje šířku řádku a může vytvářet malé soubory pro úzké tabulky.

Pokud používáte Fabric Spark runtime 1.3, povolte adaptivní cílovou velikost souboru a cíle komprese na úrovni souborů, které jsou k dispozici jako funkce, jež je třeba explicitně povolit.

V-Order primárně využívá Power BI Direct Lake a i když může zlepšit kompresi u některých pracovních zátěží, obecně není nutný ani doporučen ve výchozím nastavení pro optimální výkon SQL analytických endpointů.

Výchozí nastavení zápisu nenahrazuje údržbu tabulek. Použijte následující postupy, abyste zachovali zdravé rozložení při změně tabulek:

Povolte automatickou kompakci pro pracovní zátěže, kde je periodicky přidaná synchronní latence zápisu přijatelná. Automatická komprace je funkce Spark, která se spustí pouze tehdy, když je v tabulce příliš mnoho malých souborů.
Plánujte periodické OPTIMIZE úlohy pro úlohy, u nichž dodatečná latence způsobená pravidelnou automatickou kompakcí nesplňuje SLA pro aktualizace dat.
Postupujte VACUUM podle požadavků na uchovávání a cestování časem, abyste odstranili soubory, na které se Delta log již neodkazuje. VACUUM snižuje uložené úložiště, ale nezlepšuje aktivní rozložení souborů.
Vyhněte se dělení s vysokou kardinálností a přizpůsobeným konfiguracím zapisovačů, které vytvářejí mnoho malých souborů.

Pokud nepoužíváte automatickou kompakci, pro identifikaci tabulek, které potřebují údržbu, použijte datový pipeline a uloženou proceduru sys.sp_get_table_health_metrics T-SQL před spuštěním OPTIMIZE. Návod najdete v tématu Optimalizace tabulek Lakehouse na základě kontrol stavu.

Note

Pokyny k obecné údržbě tabulek lakehouse najdete v článku Spuštění údržby tabulek v prostředí Lakehouse.

Úvahy o velikosti oddílů

Rozložení oddílů ovlivňuje, jak dlouho trvá SQL analytickému endpointu objevit a synchronizovat změny. Velké množství particí nebo malých souborů Parquet zvyšuje režii při procházení metadat. Postupujte podle těchto postupů:

Vyhněte se vysokokardinálním oddílovým sloupcům, které mohou vytvořit oddíl pro každou jedinečnou hodnotu. Vyberte sloupec, který vytváří oddíly blízké nebo větší než 1 GB. Další informace naleznete v článku Dělení tabulek Delta Lake na oddíly.
Dávkové a streamované příjmové zpracování může vytvářet malé soubory, když jsou změny časté nebo malé. K zkomprimování těchto souborů používejte pravidelnou údržbu tabulek lakehouse.

Pro vyhodnocení velikosti a počtu souborů každé partition použijte ukázkový skript pro detaily partition.

Ukázkový skript pro podrobnosti oddílu

Použijte následující notebook k vytvoření sestavy s velikostí a podrobnostmi o particích, na nichž je tabulka Delta založena.

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

Úplný skript můžete 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']}")

Váš názor

Byla tato stránka užitečná?

Poslední aktualizace v 2026-09-16