Sdílet prostřednictvím

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 mnoha faktorech, které jsou popsány v tomto článku. 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í.

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.

Snímek obrazovky z portálu Fabric s tlačítkem Aktualizovat schéma koncového bodu analýzy SQL

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.

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 pro synchronizaci mezi lakehousemi a koncovým bodem SQL Analytics, může to být způsobeno velkým počtem lakehouse platforem 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 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í uvedená v koncovém bodu analýzy SQL. Nebo jste zapsali velký počet řádků do tabulky v datovém lakehouse, ale tato data ještě nejsou viditelná v koncovém bodu SQL analýzy. Doporučujeme zahájit synchronizaci metadat na vyžádání, aktivovanou z možnosti Aktualizace editoru dotazů SQL nebo rozhraní REST API pro aktualizaci metadat koncového bodu 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 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 extrémně velkému objemu změn tabulek, může nastat očekávané zpoždění, než se všechny změny zpracují.

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

Když koncový bod SQL Analytics čte tabulky uložené v Lakehouse, je výkon dotazů silně ovlivněn fyzickým uspořádáním podkladových souborů Parquet.

Velký počet malých souborů Parquet vytváří režii a negativně ovlivňuje výkon dotazů. Pokud chcete zajistit předvídatelný a efektivní výkon, doporučujeme udržovat ú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 minimalizovaly režijní náklad na zpracování souborů, ale ne tak velké, aby omezovaly efektivitu paralelního prohledávání. U většiny úloh dosáhnete nejlepší rovnováhy s jednotlivými parquetovými soubory o přibližné velikosti 400 MB. K dosažení tohoto zůstatku použijte následující kroky:

  1. Nastavte maxRecordsPerFile na 2 000 000, než dojde ke změnám dat.
  2. Proveďte změny dat (příjem dat, aktualizace, odstranění).
  3. Nastavte maxFileSize na 400 MB.
  4. Spusťte OPTIMIZE. Podrobnosti o použití OPTIMIZEnajdete v tématu Operace údržby tabulek.

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 (~400 MB)
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", 400 * 1024 * 1024)

# 4. RUN OPTIMIZE (bin-packing)
spark.sql("""
    OPTIMIZE myTable
""")

Aby uživatelé zachovali správné velikosti souborů, měli by pravidelně spouštět operace optimalizace Delta, jako je OPTIMALIZACE, zejména u tabulek, které přijímají časté přírůstkové zápisy, aktualizace a odstranění. 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.

Poznámka:

Pokyny k obecné údržbě tabulek lakehouse najdete v tématu Provádění ad hoc údržby tabulek u tabulky Delta pomocí Lakehouse.

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á. Vyberte sloupec pro oddíl, který nemá vysokou kardinalitu, a zajistí, že jednotlivé oddíly mají 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 stát, že dojde k malému objemu změn v jezeře, což vede k malým souborům 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

  • Last updated on