Sdílet prostřednictvím

Vyhodnocení a optimalizace kapacity Microsoft Fabric

  • Článek

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 pomůžou optimalizovat výpočetní prostředky pro každou z prostředí infrastruktury.

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 prostředí Infrastruktury nevyhovuje osvědčeným postupům.

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

  • Rozšíření a vyhlazování zajišťuje rychlé dokončení aktivit náročných na procesor, aniž by vyžadovaly vyšší skladovou položku (a je možné je spustit kdykoliv).
  • Zpoždění omezování nebo odmítnutí operací v případě, že kapacita udrží trvalou a vysokou poptávku po procesoru (nad limitem skladové položky).

Vyhlazování snižuje pravděpodobnost omezování (i když může dojít k omezování). Vyhlazování je způsob přidělování využití proti limitům, ale je nezávislé na provádění úloh. Vyhlazování nemění výkon, jen rozloží účtování spotřebovaných výpočetních prostředků za delší období, takže větší skladová položka není potřebná ke zpracování výpočetních prostředků ve špičce.

Další informace o kapacitě Prostředků infrastruktury najdete v tématu Koncepty a licencea kapacity Prostředků infrastruktury Microsoft Fabric – Vše, co potřebujete vědět o novinkách a co se chystá.

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, jejich provedení (například efektivita dotazu DAX nebo kódu Pythonu 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.

Tip

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 prostředků infrastruktury jsou interaktivní nebo na pozadí. Například dotazy DAX ze sestavy Power BI jsou požadavky na vyžádání, které jsou interaktivní operace, zatímco sémantické aktualizace modelu jsou operace na pozadí. Další informace o operacích a způsobu, jakým spotřebovávají prostředky v rámci prostředků infrastruktury, najdete v tématu Operace s prostředky infrastruktury.

Monitorování vám může odhalit, že dochází k omezování. K omezování 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).

Správci můžou pomocí pracovního prostoru monitorování správy zjistit informace o často používaných položkách (a celkovém přijetí). Mohou také použít centrum monitorování k zobrazení aktuálních a nedávných aktivit v tenantovi. Další informace o některých operacích můžou být také dostupné v Log Analytics nebo v protokolech místní brány dat.

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é použití nastavení specifických pro úlohy k omezení velikosti operací (například omezení časového limitu dotazu Power BI nebo limitů řádků nebo nastavení pracovního prostoru Spark).

Optimalizovat

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

Vertikální 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). Vertikální navýšení kapacity zajišťuje, že pro všechny položky v kapacitě je k dispozici dostatek výpočetních prostředků a aby nedocházelo k omezování.

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 přesunutím některých pracovních prostorů nebo položek do jiné kapacity prostředků infrastruktury, aby se úloha rozložila. Může být dobrou volbou, když se vyžadují 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 responzivní sestavy a řídicí panely. Tyto sestavy a řídicí panely se můžou nacházet v samostatné kapacitě vyhrazené pro vytváření sestav vedoucích pracovníků.

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

Prostředí a položky v prostředcích infrastruktury fungují jinak, takže je nemusíte nutně optimalizovat stejným způsobem. Tato část uvádí položky prostředků infrastruktury podle zkušeností a akce, které můžete provést k jejich optimalizaci.

Datový sklad prostředků infrastruktury

Datový sklad používá bezserverovou architekturu a její uzly se automaticky spravují službou. Využití kapacity se počítá na základě aktivní jednotky kapacity dotazu v sekundách, nikoli na dobu, po kterou se zřizují front-endové a back-endové uzly.

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

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

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 zmenšení VARCHAR pole z délky 500 na 25 nebo změna DECIMAL(32, 8) na může vést k DECIMAL(10, 2) významnému poklesu 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é správy (DMV) sys.dm_exec_requests poskytuje informace o všech aktivně spouštěných dotazech, ale neukládá žádné historické informace. Sada nástrojů prostředků infrastruktury poskytuje dotaz, který používá toto zobrazení dynamické správy a zpřístupňuje výsledek dotazu tak, že se připojí k jiným zobrazením a poskytne podrobnosti, jako je text dotazu.
    • Přehledy dotazů, což je funkce datových skladů v prostředcích infrastruktury, poskytuje ucelený přehled o historické aktivitě dotazů na koncovém bodu analýzy SQL. Konkrétně zobrazení queryinsights.exec_requests_history poskytuje informace o každém úplném požadavku SQL. Zobrazí všechny relevantní podrobnosti pro každé spuštění dotazu, které je možné korelovat s ID operací nalezenými v aplikaci metrik kapacity. Nejdůležitějšími sloupci monitorování využití kapacity jsou: distributed_statement_id, příkaz (text dotazu), start_time a end_time.

Datoví technici prostředků infrastruktury a Datová Věda prostředků infrastruktury

Prostředí Datoví technici a Datová Věda používají výpočetní prostředí Sparku ke zpracování, analýze a ukládání dat v objektu Fabric Lakehouse. Výpočetní prostředí Spark se nastavuje a měří z hlediska virtuálních jader. Prostředky infrastruktury ale používají jednotky CU 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 se jedna CU přeloží na dvě virtuální jádra Sparku výpočetních prostředků. Například když zákazník zakoupí skladovou položku F64, pro prostředí Sparku je k dispozici 128 virtuálních jader Sparku.

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

Další informace najdete v tématu Vytváření sestav fakturace a využití v 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 Sparku ve službě Azure Synapse Analytics a nutnost optimalizace zápisu v Apache Sparku.
  • Zarezervujte požadované exekutory pro úlohy Sparku, abyste uvolnili prostředky pro jiné úlohy nebo úlohy Sparku. 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 exekutorů přidělených poznámkovému bloku v centru monitorování prostředků infrastruktury, kde můžete také určit skutečný počet exekutorů používaných poznámkovým blokem. Úlohy Sparku si zarezervují jenom požadované uzly a umožňují paralelní odesílání v rámci limitů skladové položky.
  • Fond Sparku je možné nakonfigurovat jenom tak, aby používal maximální počet virtuálních jader podporovaných skladovou jednotkou. Ú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árazu a ve výchozím nastavení je povolený pro úlohy Sparku na úrovni kapacity. Další informace najdete v tématu Omezování souběžnosti a zařazení do fronty.
  • Aktivní relace Sparku můžou nabíhání využití CU na kapacitě. 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 definici úlohy Sparku.

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 nejnákladnějšího a nejlepšího výkonu.

Aby bylo možné zpřístupnit data jiným modulům Infrastruktury, 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í, se Z vaší kapacity využívají jednotky CU. Využívá měřiče čtení a zápisu OneLake, které jsou ekvivalentní operacím čtení a zápisu v účtech Azure Data Lake Storage (ADLS) Gen2.

Data Factory

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

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

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

  • Vyhněte se neefektivní logice Power Query, abyste minimalizovali a optimalizovali nákladné transformace dat, jako je sloučení 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é.
  • Zakažte přípravu při práci s malými objemy dat nebo provádění jednoduchých transformací. 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 má vysokou souběžnost, protože velikost kapacity je příliš mnoho uživatelů. 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 prostředků infrastruktury.