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.

Velký počet malých souborů Parquet způsobuje režii a negativně ovlivňuje výkon dotazování. Pokud chcete zajistit předvídatelný a efektivní výkon, udržujte úložiště tabulek tak, aby každý soubor Parquet obsahoval dva miliony řádků. Tento počet řádků poskytuje vyváženou úroveň paralelismu bez fragmentování datové sady do příliš malých řezů.

Kromě pokynů k počtu řádků je velikost souboru stejně důležitá. Koncový bod analýzy SQL funguje nejlépe, když jsou soubory Parquet dostatečně velké, aby se minimalizovala režie zpracování souborů, ale ne tak velká, že omezují efektivitu paralelního prohledávání. Pro většinu pracovních zátěží představuje nejlepší kompromis, pokud mají jednotlivé soubory Parquet velikost kolem 400 MB. K dosažení tohoto zůstatku použijte následující kroky:

Nastavte maxRecordsPerFile na 2 000 000, než dojde ke změnám dat.
Proveďte změny dat (příjem dat, aktualizace, odstranění).
Nastavte maxFileSize na 4 GB.
Spusťte OPTIMIZE. Podrobnosti o použití OPTIMIZE najdete v tématu Spuštění údržby tabulek z Lakehouse.

Následující skript poskytuje šablonu pro tyto kroky a měla by se spustit na jezeře:

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
""")

Chcete-li udržet zdravé velikosti souborů, pravidelně spouštějte operace optimalizace Delta, jako je OPTIMIZE, zejména u tabulek, do kterých se často přírůstkově vkládají, aktualizují a odstraňují data. Tyto operace údržby komprimují malé soubory do vhodných velikostí, což pomáhá zajistit, aby koncový bod analýzy SQL mohl efektivně zpracovávat dotazy. Pokud chcete optimalizovat tabulky, které potřebují údržbu inteligentně, použijte datový kanál a uloženou proceduru sys.sp_get_table_health_metrics T-SQL k určení, kdy tabulka potřebuje OPTIMIZE příkaz. 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 oddílu pro tabulku Delta v lakehouse také ovlivňuje dobu potřebnou k synchronizaci změn do SQL analytics endpointu. 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 optimalizaci 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 skončit s velkým množstvím parketových souborů v Delta stole z jednoho nebo 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í zápisník k vytištění zprávy s podrobnými rozměry a detaily oddílů, které stojí za tabulkou Delta.

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.

Další informace najdete v tématu Synchronizace metadat koncových bodů služby SQL Analytics. Aktualizaci automatické kontroly metadat můžete také vynutit prostřednictvím kódu programu pomocí rozhraní REST API pro aktualizaci metadat koncového bodu SQL.

Váš názor

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

Last updated on 2026-06-24