Vyhodnocení a optimalizace kapacity Microsoft Fabric

Tento článek vysvětluje, jak vyhodnotit a optimalizovat zatížení kapacit Microsoft Fabric. Popisuje také strategie řešení situací přetížení a poskytuje pokyny, které vám pomohou optimalizovat výpočetní kapacity pro každou z Fabric prostředí.

I když model kapacity Fabric zjednodušuje nastavení a umožňuje spolupráci, existuje vysoká pravděpodobnost vyčerpání sdílených výpočetních prostředků kapacity. Může se také stát, že platíte za více prostředků, než je potřeba. K těmto situacím může dojít, když návrh některých zážitků Fabric nevyhovuje osvědčeným postupům.

Je důležité snížit riziko vyčerpání sdílených prostředků, Fabric jako spravovaná služba automaticky řeší tyto situace dvěma způsoby.

  • Burstování a vyrovnání zajišťuje rychlé dokončení aktivit náročných na procesor, aniž by vyžadovaly drahé specifikace (a lze je spustit kdykoli během dne).
  • Omezování výkonu či odmítání operací při stavu, kdy kapacita zažívá trvalou a vysokou poptávku po procesoru (nad limitem SKU).

Vyhlazování snižuje pravděpodobnost omezování, i když k němu stále může dojít. Vyhlazování je způsob přidělování využití ve vztahu k limitům, ale je nezávislé na výkonu úloh. Vyhlazování nemění výkon, jen rozloží účtování za spotřebovaný výpočetní výkon za delší období, takže větší typ produktu není potřebný ke zvládnutí špičkového výkonu.

Další informace o kapacitě Microsoft Fabric najdete v tématech Microsoft Fabric koncepty a licencování a Fabric Kapacity – Vše, co potřebujete vědět o novinkách a chystaných změnách.

Nástroje pro plánování a rozpočtování

Plánování velikosti kapacity může být náročné. Důvodem je to, že se požadované výpočetní prostředky můžou značně lišit díky provedeným operacím, způsobu jejich provedení (například efektivita dotazu DAX nebo kódu Python v poznámkovém bloku) nebo úroveň souběžnosti.

Abyste mohli určit správnou velikost kapacity, můžete zřídit zkušební kapacity nebo skladové položky F s průběžnými platbami , abyste před nákupem rezervované instance skladové položky F změřili skutečnou velikost kapacity.

Návod

Vždy je to dobrá strategie, jak začít malé, a podle potřeby postupně zvětšovat velikost kapacity.

Monitorování kapacit

Měli byste monitorovat využití, abyste z kapacit získali maximum. Především je důležité pochopit, že operace Fabric jsou interaktivní nebo na pozadí. Například dotazy DAX ze zprávy Power BI jsou požadavky na vyžádání, které probíhají interaktivně, zatímco aktualizace sémantického modelu jsou operace na pozadí. Další informace o operacích a o tom, jak spotřebovávají prostředky ve Fabricu, najdete v tématu Operace Fabricu.

Monitorování vám může odhalit, že dochází k omezování. K omezení výkonu může dojít, když existuje mnoho nebo dlouhotrvajících interaktivních operací. Operace na pozadí související s prostředím SQL a Spark jsou obvykle vyhlazené, což znamená, že jsou rozložené do 24hodinového období.

Aplikace Fabric Capacity Metrics je nejlepším způsobem, jak monitorovat a vizualizovat nedávné využití. Aplikace se rozdělí na typ položky (sémantický model, poznámkový blok, kanál a další) a pomůže identifikovat položky nebo operace, které používají vysoké úrovně výpočetních prostředků (aby je bylo možné optimalizovat).

Administrátoři mohou v katalogu OneLake použít zprávu Govern k získání informací o často používaných položkách, využití funkcí a celkovém přijetí. Zpráva shromažďuje širší informace o nájemcích z úložiště Admin Monitoring, včetně inventáře, sdílení, ochrany a poznatků o kurátorství. Administrátoři mohou také použít Monitoring hub k zobrazení aktuálních a nedávných aktivit v tenantu. Další informace o některých operacích můžou být dostupné také z Log Analytics nebo z protokolů místní brány dat on-premises data gateway.

Správa vysokého využití výpočetních prostředků

Pokud je kapacita vysoce využitá a začne se zobrazovat omezování nebo odmítnutí, existují tři strategie, jak ji vyřešit: optimalizaci, vertikální navýšení kapacity a horizontální navýšení kapacity.

Osvědčeným postupem je nastavit oznámení , která se dozví, kdy využití kapacity překročí nastavenou prahovou hodnotu. Zvažte také omezení velikosti operací (například Power BI omezení časového limitu dotazu nebo limitů řádků nebo Nastavení pracovního prostoruSpark).

Optimalizovat

Tvůrci obsahu by měli vždy optimalizovat návrh svých Fabric prvků, aby zajistili, že je efektivní a bude používat co nejméně výpočetních prostředků. Konkrétní pokyny pro každé prostředí Fabric najdete dále v tomto článku.

Navýšení kapacity

Kapacitu vertikálně navyšujete, abyste dočasně nebo trvale zvýšili velikost skladové položky (s větší výpočetní kapacitou). Škálování nahoru zajišťuje, že pro všechny položky v kapacitě je k dispozici dostatek výpočetních prostředků a nedochází k omezení.

Můžete také změnit velikost, pozastavit a obnovit skladové položky Fabric F tak, aby odpovídaly vzorům spotřeby.

Horizontální navýšení kapacity

Kapacitu můžete škálovat horizontálně přesunutím některých pracovních prostorů nebo položek do jiné kapacity Fabric, čímž rozložíte zátěž. Dobrou volbou může být, pokud jsou vyžadovány různé strategie kapacity, nastavení nebo správci. Zřizování více kapacit je také dobrou strategií, která pomáhá izolovat výpočetní prostředky pro položky s vysokou prioritou a také pro samoobslužný nebo vývojový obsah. Například vedoucí pracovníci ve vaší organizaci očekávají vysoce reaktivní zprávy a řídicí panely. Tyto sestavy a řídicí panely mohou být umístěny v samostatné kapacitě vyhrazené pro vytváření sestav pro vrcholové vedení.

Můžete také zvážit přesun pracovních prostorů Power BI do sdílené kapacity za předpokladu, že uživatelé mají licence Power BI Pro, které jim umožňují dál přistupovat k obsahu.

Konfigurace ochrany proti přepětí

ochrana proti přepětí pomáhá omezit nadměrné využití kapacity omezením celkového množství výpočetních úloh na pozadí. To snižuje celkové výpočetní prostředky, takže interaktivní zpoždění nebo zamítnutí jsou méně pravděpodobné. Pomáhá také rychlejšímu zotavení kapacity v případě, že dojde k období omezování nebo zamítnutí. Pro každou kapacitu nakonfigurujete ochranu proti přepětí. Ochrana proti přepětí pomáhá zabránit omezování výkonu a zamítnutí, ale není náhradou za optimalizaci kapacity, škálování vertikálně a horizontálně.

Když je aktivní ochrana proti přepětí, úlohy na pozadí se zamítnou. To znamená, že to má dopad na vaši kapacitu i v případě, že je povolená ochrana proti přepětí. Pomocí ochrany proti přepětí naladíte kapacitu tak, aby zůstala v rozsahu využití, které nejlépe vyrovnává požadavky výpočetních prostředků v rámci kapacity. Pokud chcete plně chránit kritická řešení, doporučujeme je izolovat ve správné kapacitě.

Optimalizace výpočetních prostředků podle prostředí Fabric

Zkušenosti a položky ve Fabric pracují odlišně, takže je nemusíte nutně optimalizovat stejným způsobem. Tato část uvádí položky platformy Fabric podle uživatelských zkušeností a akce, které můžete provést k jejich optimalizaci.

Datový sklad typu Fabric

Datový sklad používá bezserverovou architekturu a její uzly se automaticky spravují službou. Využití kapacity se počítá na základě aktivního počtu sekund kapacitních jednotek za dotaz, nikoli podle času, po který jsou front-end a back-end uzly zřizovány.

Všechny operace datového skladu jsou operace na pozadí a jsou vyhlazené po dobu 24 hodin.

Cílem SQL Analytics koncového bodu je poskytovat výchozí výkonnostní zážitek. K tomuto účelu je k dispozici méně možností ladění dotazů ve srovnání s SQL Server nebo Azure Synapse Analytics vyhrazenými fondy SQL.

Tady je několik bodů, které je potřeba zvážit, abyste minimalizovali výpočetní prostředky.

  • Zapisujte dotazy pomocí nejoptimálnějšího možného T-SQL. Pokud je to možné, omezte počet sloupců, výpočtů, agregací a dalších operací, které by zbytečně zvýšily využití prostředků dotazů.
  • Tabulky navrhujte tak, aby používaly nejmenší možné datové typy . Váš výběr datového typu může výrazně ovlivnit plány dotazů vygenerované modulem SQL. Například snížení délky pole VARCHAR z 500 na 25 nebo změna DECIMAL(32, 8) na DECIMAL(10, 2) může vést ke značnému snížení prostředků přidělených pro dotaz.
  • Pomocí návrhu hvězdicového schématu můžete snížit počet přečtených řádků a minimalizovat spojení dotazů.
  • Ujistěte se, že statistiky existují a že jsou aktuální. Statistiky hrají zásadní roli při generování optimálního plánu provádění. Vytvářejí se automaticky za běhu, ale možná je budete muset aktualizovat ručně, zejména po načtení nebo aktualizaci dat. Zvažte vytvoření statistiky pomocí FULLSCAN možnosti místo toho, abyste se spoléhali na automaticky generované statistiky, které používají vzorkování.
  • Pomocí integrovaných zobrazení můžete monitorovat dotazy a využití, zejména při řešení potíží.
    • Zobrazení dynamického řízení (DMV) sys.dm_exec_requests poskytuje informace o všech aktivně spouštěných dotazech, ale neuchovává žádné historické informace. Sada fabric nástrojů poskytuje dotaz, který používá toto zobrazení dynamické správy a výsledek dotazu zpřehledňuje tak, že se propojí s jinými zobrazeními a poskytnou podrobnosti, jako je text dotazu.
    • Postřehy z dotazů, což je funkce datové sklady Fabric, poskytuje ucelený přehled o historické aktivitě dotazů na konečném bodu analýzy SQL. Konkrétně queryinsights.exec_requests_history zobrazení poskytuje informace o každém dokončeném SQL požadavku. Nejdůležitější sloupce pro monitorování využití kapacity jsou: distributed_statement_id, příkaz (dotazovací text),sql_pool_name, allocated_cpu_time_ms, start_time a end_time sloupce.

Inženýrství datových systémů Fabric a Datová věda Fabric

Zkušenosti s datovým inženýrstvím a datovou vědou používají výpočetní prostředí Spark k zpracování, analýze a ukládání dat v rámci Fabric lakehouse. Výpočetní prostředí Spark se nastavuje a měří z hlediska virtuálních jader. Fabric ale používá jednotky CUs jako míru výpočetních prostředků spotřebovaných různými položkami, včetně poznámkových bloků Sparku, definic úloh Sparku a úloh lakehouse.

Ve Sparku jedna CU znamená dvě Spark vCore výpočetní kapacity. Například když zákazník koupí F64 SKU, je k dispozici 128 Spark vCore pro zážitky se Sparkem.

Všechny operace Sparku jsou operace na pozadí a jsou vyhlazené po dobu 24 hodin.

Další informace naleznete v Sestavy fakturace a využití ve Fabric Sparku.

Tady je několik bodů, které je potřeba zvážit, abyste minimalizovali výpočetní prostředky.

  • Vždy se snažte psát efektivní kód Sparku. Další informace najdete v tématu Optimalizace úloh Apache Spark v Azure Synapse Analytics a Potřeba optimalizace zápisu v Apache Spark.
  • Rezervujte požadované exekutory pro úlohy ve Spark, abyste uvolnili prostředky pro jiné úlohy ve Spark nebo další pracovní zátěže. Jinak zvýšíte pravděpodobnost, že úlohy Sparku selžou se stavem HTTP 430, což znamená příliš mnoho požadavků na kapacitu. Můžete zobrazit počet vykonávačů přidělených notebooku v Fabric monitoring hub, a také zde zjistit skutečný počet vykonávačů používaných notebookem. Úlohy Sparku si zarezervují jen požadované uzly a umožňují paralelní odesílání v rámci limitů typu SKU.
  • Pool Sparku je možné nakonfigurovat jen tak, aby používal maximální počet virtuálních jader podporovaných SKU. Úlohy přípravy dat ale můžete škálovat tak, že v rámci limitů skladových položek přijmete paralelní úlohy Sparku. Tento přístup se běžně označuje jako faktor náhlého navýšení a ve výchozím nastavení je povolený pro úlohy Sparku na úrovni kapacity. Pro více informací si přečtěte Omezování průběžné zátěže a frontování.
  • Aktivní relace Sparku mohou zvyšovat využití CU v rámci kapacity. Z tohoto důvodu je důležité zastavit aktivní relace Sparku, pokud se nepoužívají. Všimněte si, že výchozí doba vypršení platnosti relace Sparku je nastavená na 20 minut. Uživatelé můžou časový limit relace změnit v poznámkovém bloku nebo v definici úlohy Spark.

Analýza v reálném čase

Spotřeba CU databáze KQL se vypočítá na základě počtu sekund, po který je databáze aktivní, a počtu použitých virtuálních jader. Pokud například vaše databáze používá čtyři virtuální jádra a je aktivní po dobu 10 minut, spotřebujete 2 400 (4 x 10 x 60) sekund CU.

Všechny databázové operace KQL jsou interaktivní operace.

Mechanismus automatického škálování se využívá k určení velikosti databáze KQL. Zajišťuje, aby se na základě vzorů využití dosáhlo optimálního výkonu z hlediska nákladů a nejlepší účinnosti.

Aby bylo možné zpřístupnit data jiným strojům Fabric, databáze KQL se synchronizuje s OneLake. Na základě počtu transakcí čtení a zápisu, které vaše databáze KQL provádí, jsou jednotky výpočetní kapacity (CUs) využívány z vaší kapacity. Využívá měřiče čtení a zápisu OneLake, které jsou ekvivalentní operacím čtení a zápisu u účtů Azure Data Lake Storage (ADLS) Gen2.

Data Factory

Tato část se zabývá optimalizacemi toků dat a kanálů ve službě Data Factory.

Všechny operace probíhají na pozadí a jsou vyhlazovány během 24 hodin.

Tady je několik bodů, které je potřeba zvážit, abyste minimalizovali výpočetní prostředky.

  • Vyhněte se neefektivní Power Query logiky, abyste minimalizovali a optimalizovali nákladné transformace dat, jako je slučování a řazení.
  • Snažte se dosáhnout posouvání dotazů, kdykoli je to možné. Může zlepšit výkon toků dat snížením množství dat, která je potřeba přenášet mezi zdrojem dat a cílem. Pokud k posouvání dotazů nedojde, Power Query načte všechna data ze zdroje dat a provede transformace místně, což může být neefektivní a pomalé.
  • Zakážete předzpracování, pokud pracujete s malými objemy dat nebo provádíte jednoduché transformace. V některých případech může být potřeba příprava, například při načítání datového skladu.
  • Vyhněte se častější aktualizaci dat, než vyžaduje zdroj dat. Pokud se například zdroj dat aktualizuje jenom jednou za 24 hodin, nebude aktualizace dat za hodinu poskytovat žádnou další hodnotu. Místo toho zvažte aktualizaci dat s příslušnou frekvencí, abyste měli jistotu, že jsou aktuální a přesná.

Power BI

operace Power BI jsou interaktivní nebo na pozadí.

Následující interaktivní operace obvykle vedou k vysokému využití výpočetních prostředků.

  • Sémantické modely, které nedodržují osvědčené postupy. Například nemusí přijmout návrh hvězdicového schématu s relacemi 1:N. Nebo můžou zahrnovat složité a nákladné filtry zabezpečení na úrovni řádků (RLS). Zvažte použití tabulkového editoru a analyzátoru osvědčených postupů k určení, jestli jsou dodrženy osvědčené postupy.
  • Míry DAX jsou neefektivní.
  • Stránky sestavy obsahují příliš mnoho vizuálů, což může vést k pomalé aktualizaci vizuálu.
  • Vizuály sestav zobrazují výsledky s vysokou kardinalitou (příliš mnoho řádků nebo sloupců) nebo obsahují příliš mnoho měr.
  • Kapacita zažívá vysoké zatížení, protože počet uživatelů přesahuje její velikost. Zvažte povolení horizontálního navýšení kapacity dotazů, aby se zlepšilo uživatelské prostředí pro sémantické modely s vysokou souběžností (ale nemá za následek více celkového výpočetního výkonu).

Následující operace na pozadí obvykle vedou k vysokému využití výpočetních prostředků.

  • Neefektivní nebo příliš složité transformace dat v logice Power Query
  • U velkých tabulek faktů chybí posouvání dotazů nebo přírůstková aktualizace.
  • Shlukování sestav, což je v případě, že se současně generuje velký počet sestav Power BI nebo stránkovaných sestav.

Související obsah

Máte ještě další otázky? Zkuste se zeptat komunity Fabric.

  • Poslední aktualizace v