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.

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í se spustí jenom v době, kdy je aktivní koncový bod analýzy SQL a po 15 minutách nečinnosti se zastaví.

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áte možnost spustit synchronizaci metadat na vyžádání.
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.

Pro lepší výkon koncových bodů SQL Analytics nepotřebujete V-Order, protože Spark zapisuje soubory Parquet komprimované pomocí Snappy, aby se omezily vstupně-výstupní operace při čtení i zápisu.

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ů

Volba sloupce pro oddíly pro tabulku Delta v prostředí lakehouse také ovlivňuje dobu potřebnou k synchronizaci změn do koncového bodu SQL analýz. Počet a velikost oddílů partitionovacího sloupce jsou důležité pro výkon:

Sloupec s vysokou kardinalitou (většinou nebo zcela tvořený jedinečnými hodnotami) vede k velkému počtu particí. 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. Použijte sloupec, který vede k rozdělení o velikosti alespoň 1 GB (nebo přibližně 1 GB). Dodržujte osvědčené postupy pro údržbu a rozdělení tabulek Delta. Skript v jazyce Python pro vyhodnocení oddílů naleznete v části Ukázkový skript pro podrobnosti o oddílech.

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. Můžete mít velké množství souborů Parquet v tabulce Delta z jednoho či více důvodů:

Pokud pro tabulku Delta zvolíte oddíl s vysokým počtem jedinečných hodnot, tabulka bude rozdělena podle každé jedinečné hodnoty a může být nadměrně rozdělená do oddílů. Vyberte sloupec pro oddíl, který nemá vysokou kardinalitu, a zajistí, že jednotlivé oddíly mají alespoň 1 GB.
Rychlosti dávkového a streamovaného příjmu dat mohou také vést k tvorbě malých souborů v závislosti na frekvenci a velikosti změn, které se zapisují do datového skladiště. Může se například stát, že dojde k malému objemu změn v jezeře, což vede k malým souborům parquet. Pokud chcete tento problém vyřešit, implementujte pravidelnou údržbu tabulek lakehouse.

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

Automaticky generované schéma v SQL analytickém koncovém bodu lakehouse

Pro každou tabulku Delta ve vašem Lakehouse koncový bod analýzy SQL automaticky vygeneruje tabulku v příslušném schématu. Modul koncových bodů analýzy SQL je založený na modulu Fabric Data Warehouse.

Pro více informací viz synchronizace metadat endpointů SQL analytics. Můžete také programově vynutit obnovení automatického skenování metadat pomocí Refresh SQL analytics endpoint metadata REST API.

Váš názor

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

Last updated on 2026-08-27