Sdílet prostřednictvím

Osvědčené postupy pro efektivitu výkonu

  • Článek

Tento článek popisuje osvědčené postupy pro efektivitu výkonu uspořádané podle principů architektury uvedených v následujících částech.

1. Vertikální škálování, horizontální škálování a lineární škálovatelnost

Než se pustíme do osvědčených postupů, podívejme se na několik konceptů distribuovaného computingu: horizontální škálování, vertikální škálování a lineární škálovatelnost.

  • Vertikální škálování: Vertikální škálování: Vertikální škálování přidáním nebo odebráním prostředků z jednoho počítače, obvykle procesorů, paměti nebo GRAFICKÝch procesorů. Obvykle to znamená zastavení úlohy, jeho přesunutí na větší počítač a jeho restartování. Existují omezení vertikálního škálování: Nemusí existovat větší počítač nebo cena dalšího většího počítače může být zakázána.
  • Horizontální škálování: Horizontální škálování: Horizontální škálování přidáním nebo odebráním uzlů z distribuovaného systému Když dosáhnete limitů vertikálního škálování, řešení se škáluje horizontálně: Distribuované výpočty používají systémy s více počítači (označovanými jako clustery) ke spouštění úloh. Je důležité pochopit, že aby to bylo možné, musí být úlohy připravené na paralelní spouštění, jak jsou podporovány moduly platformy Databricks Data Intelligence Platform, Apache Spark a Photon. To umožňuje kombinaci několika levných počítačů do většího výpočetního systému. Pokud potřebujete více výpočetních prostředků, horizontální škálování přidá do clusteru další uzly a odebere je, když už je nepotřebujete. I když technicky neexistuje žádný limit (a modul Spark provádí složitou část vyrovnávání zatížení), velký počet uzlů zvyšuje složitost správy.
  • Lineární škálovatelnost, což znamená, že když do systému přidáte další prostředky, je vztah mezi využitou propustností a použitými prostředky lineární. To je možné pouze v případě, že jsou paralelní úkoly nezávislé. Pokud ne, budou k dalším výpočtům potřeba přechodné výsledky na jedné sadě uzlů v clusteru. Tato výměna dat mezi uzly zahrnuje přenos výsledků přes síť z jedné sady uzlů do jiné sady uzlů, což trvá poměrně dlouho. Distribuovaný computing má obecně určitou režii při správě distribuce a výměny dat. V důsledku toho můžou být malé úlohy sady dat, které je možné analyzovat na jednom uzlu, ještě pomalejší při spuštění v distribuovaném systému. Platforma Databricks Data Intelligence poskytuje flexibilní výpočetní prostředí (jeden uzel a distribuovaný) tak, aby splňovalo jedinečné potřeby vašich úloh.

2. Použití bezserverových architektur

Použití bezserverového výpočetního prostředí

Výpočetní vrstva bez serveru na platformě Databricks Data Intelligence běží v účtu Azure Databricks zákazníka. Služby jsou plně spravované a nepřetržitě vylepšené službou Databricks. Kromě zákazníků platí jenom za to, co používají, výsledkem je vyšší produktivita:

  • Správci cloudu už nemusí spravovat složitá cloudová prostředí, jako je úprava kvót, vytváření a údržba síťových prostředků a připojení ke zdrojům fakturace. Mohou se soustředit na projekty s vyšší hodnotou místo správy cloudových komponent nízké úrovně.
  • Uživatelé těží z latence téměř nulového spuštění clusteru a lepší souběžnosti dotazů.

Databricks poskytuje spravované služby pro různé úlohy:

  • Bezserverové sklady SQL pro úlohy SQL

    Správci pracovních prostorů můžou vytvářet bezserverové sklady SQL, které umožňují okamžité výpočty a spravují je Databricks. Používejte je s dotazy SQL Databricks stejně jako u původních skladů Sql Databricks. Bezserverové výpočetní prostředky mají velmi rychlý čas spuštění pro SQL Warehouse a infrastruktura je spravovaná a optimalizovaná službou Databricks.

  • Bezserverové úlohy pro efektivní a spolehlivé pracovní postupy

    Bezserverové výpočetní prostředky pro úlohy umožňují spouštět úlohu Databricks bez konfigurace a nasazování infrastruktury. Díky bezserverovým výpočetním prostředkům se zaměřujete na implementaci kanálů zpracování a analýzy dat a Databricks efektivně spravuje výpočetní prostředky, včetně optimalizace a škálování výpočetních prostředků pro vaše úlohy. Automatické škálování a Photon jsou automaticky povolené pro výpočetní prostředky, na kterých běží vaše úloha.

    Náklady na úlohy, které používají bezserverové výpočetní prostředky pro úlohy, můžete monitorovat dotazováním fakturovatelné systémové tabulky využití .

  • Výpočetní prostředí bez serveru pro poznámkové bloky

    Pokud je váš pracovní prostor povolený pro bezserverové interaktivní výpočetní prostředky, mají všichni uživatelé v pracovním prostoru přístup k bezserverovému výpočetnímu prostředí pro poznámkové bloky. Nejsou vyžadována žádná další oprávnění.

Použití služby obsluhy modelu podnikové úrovně

Služba Rozhraní AI pro vytváření modelů SI pro architekturu AI poskytuje jednotné rozhraní pro nasazování, řízení a dotazování modelů AI. Každý model, který používáte, je k dispozici jako rozhraní REST API, které můžete integrovat do webové nebo klientské aplikace.

Poskytování modelů poskytuje vysoce dostupnou službu s nízkou latencí pro nasazování modelů. Služba automaticky vertikálně navyšuje nebo snižuje kapacitu tak, aby splňovala změny poptávky, což šetří náklady na infrastrukturu při optimalizaci výkonu latence. Tato funkce využívá výpočetní prostředky bez serveru.

3. Návrh úloh pro výkon

Principy ingestování a přístupu k datům

Z hlediska výkonu se vzory přístupu k datům – například agregace versus přístup k bodům nebo vyhledávání – chovají odlišně v závislosti na velikosti dat. Velké soubory jsou efektivnější pro prohledání dotazů a menší soubory jsou lepší pro hledání, protože potřebujete přečíst méně dat, abyste našli konkrétní řádky.

U vzorů příjmu dat je běžné používat příkazy DML. Příkazy DML jsou nejvýkonnější, když jsou data v clusteru, a můžete jednoduše izolovat oddíl dat. Je důležité zachovat data v clusteru a izolovat při příjmu dat: zvažte zachování přirozeného pořadí řazení času a použití co nejvíce filtrů pro ingestovanou cílovou tabulku. U úloh příjmu dat jen pro připojení a přepsání není příliš potřeba zvážit, protože se jedná o relativně levnou operaci.

Vzory příjmu dat a přístupu často odkazují na běžné rozložení dat a clustering. Pokud ne, rozhodněte se, co je pro vaši firmu důležitější, a zaměřte se na to, jak dosáhnout tohoto cíle lépe.

Použití paralelních výpočtů, kde je výhodné

Hodnota času je důležitou dimenzí při práci s daty. Mnoho případů použití lze snadno implementovat na jednom počítači (malá data, několik a jednoduchých výpočetních kroků), často existují případy použití, které potřebují zpracovávat velké datové sady, mají dlouhou dobu trvání kvůli složitým algoritmům nebo je potřeba opakovat 100 a 1000krát.

Prostředí clusteru platformy Databricks je skvělé prostředí pro efektivní distribuci těchto úloh. Automaticky paralelizuje dotazy SQL napříč všemi uzly clusteru a poskytuje knihovny pro Python a Scala , aby to bylo stejné. Pod kapotou moduly Apache Spark a Photon analyzují dotazy, určují optimální způsob paralelního spouštění a spravují distribuované spouštění odolným způsobem.

Strukturované streamování distribuuje úlohy streamování napříč clusterem stejným způsobem jako dávkové úlohy, aby byl co nejlepší výkon.

Jedním z nejjednodušších způsobů použití paralelního computingu je rozdílové živé tabulky. Deklarujete úkoly a závislosti úlohy v SQL nebo Pythonu a potom Delta Live Tables zpracovává plánování provádění, efektivní nastavení infrastruktury, provádění úloh a monitorování.

Pro datové vědce je pandas balíček Pythonu, který poskytuje snadno použitelné datové struktury a nástroje pro analýzu dat pro programovací jazyk Python. Pandas ale škáluje na velké objemy dat. Rozhraní Pandas API ve Sparku tuto mezeru vyplní tím, že poskytuje ekvivalentní rozhraní API pandas, která fungují na Apache Sparku.

Kromě toho se platforma dodává s paralelizovanými algoritmy strojového učení ve standardní knihovně strojového učení MLlib. Podporuje předefinované použití více GPU. Hluboké učení je také možné paralelizovat pomocí distributora DeepSpeed nebo TorchDistributoru.

Analýza celého řetězce provádění

Většina kanálů nebo vzorců spotřeby zahrnuje řetěz systémů. Například u nástrojů BI má výkon vliv několik faktorů:

  • Samotný nástroj BI.
  • Konektor, který připojuje nástroj BI a modul SQL.
  • Modul SQL, do kterého nástroj BI odešle dotaz.

V případě nejlepšího výkonu ve třídě musí být celý řetězec považovaný za nejlepší výkon a vybraný/vyladěný.

Preferovat větší clustery

Naplánujte větší clustery, zejména pokud se zatížení škáluje lineárně. V takovém případě není použití velkého clusteru pro úlohu dražší než použití menšího clusteru. Je to jen rychlejší. Klíčem je, že cluster pronajímáte po dobu trvání úlohy. Takže pokud spustíte dva clustery pracovních procesů a trvá to hodinu, platíte za tyto pracovníky za celou hodinu. Podobně platí, že pokud spustíte čtyři pracovní clustery a trvá to jen půl hodiny (to je místo, kde přichází lineární škálovatelnost), náklady jsou stejné. Pokud jsou náklady primárním faktorem s velmi flexibilní smlouvou SLA, cluster automatického škálování je obvykle nejlevnější, ale ne nutně nejrychlejší.

Poznámka:

U bezserverových výpočetních prostředků se nevyžaduje preferování velkých clusterů, protože automaticky spravuje clustery.

Použití nativních operací Sparku

Uživatelem definované funkce (UDF) představují skvělý způsob, jak rozšířit funkce Spark SQL. Pokud ale existuje nativní funkce, nepoužívejte funkce Definované uživatelem Python ani Scala:

Příčiny:

  • K přenosu dat mezi Pythonem a Sparkem se vyžaduje serializace. Tím se výrazně zpomalí dotazy.
  • Větší úsilí o implementaci a testování funkcí, které už na platformě existují.

Pokud chybí nativní funkce a měly by se implementovat jako funkce definované uživatelem Pythonu, použijte uživatelem definované funkce Pandas. Apache Arrow zajišťuje efektivní přesun dat mezi Sparkem a Pythonem.

Použití nativních modulů platformy

Photon je modul v Azure Databricks, který poskytuje rychlý výkon dotazů s nízkými náklady – od příjmu dat, ETL, streamování, datové vědy a interaktivních dotazů – přímo ve vašem data lake. Photon je kompatibilní s rozhraními Apache Spark API, takže začínáme je stejně snadné jako jeho zapnutí – bez změn kódu a bez uzamčení.

Photon je součástí vysoce výkonného modulu runtime, který spouští vaše stávající volání rozhraní SQL a DataFrame API rychleji a snižuje celkové náklady na úlohu. Photon se ve výchozím nastavení používá v datových skladech Databricks SQL.

Vysvětlení hardwaru a typu úlohy

Ne všechny cloudové virtuální počítače se vytvářejí stejně. Různé rodiny počítačů, které nabízejí poskytovatelé cloudu, se liší tak, aby na tom záleží. Existují zřejmé rozdíly – ram a jádra – a jemnější rozdíly – typ a generování procesoru, záruky šířky pásma sítě a místní vysokorychlostní úložiště a místní vysokorychlostní disk a vzdálený disk. Na "spotových" trzích existují také rozdíly. Před rozhodováním o tom, který typ virtuálního počítače pro vaši úlohu je nejvhodnější, by měly být srozumitelné.

Poznámka:

To není nutné pro bezserverové výpočetní prostředky, protože bezserverové výpočetní prostředky automaticky spravují clustery.

Použití ukládání do mezipaměti

Ukládání dat do mezipaměti ukládá často požadovaná data do rychlejšího média, což zkracuje dobu potřebnou k jejich načtení v porovnání s přístupem k původnímu zdroji dat. Výsledkem je nižší latence a rychlejší doba odezvy, která může výrazně zlepšit celkový výkon a uživatelské prostředí aplikace. Díky minimalizaci počtu požadavků na původní zdroj dat pomáhá ukládání do mezipaměti snížit náklady na síťový provoz a přenos dat. Tento nárůst efektivity může být zvlášť výhodný pro aplikace, které spoléhají na externí rozhraní API nebo databáze s platbami za použití. Může pomoct rovnoměrněji rozložit zatížení napříč systémem, což brání kritickým bodům a potenciálním výpadkům.

V Azure Databricks je k dispozici několik typů ukládání do mezipaměti. Tady jsou vlastnosti každého typu:

  • Použití mezipaměti disku

    Mezipaměť disku (dříve označovaná jako "Delta cache") ukládá kopie vzdálených dat na místních discích (například SSD) virtuálních počítačů. Může zvýšit výkon pro širokou škálu dotazů, ale nelze ho použít k uložení výsledků libovolných poddotazů. Mezipaměť disku automaticky rozpozná, kdy se datové soubory vytvoří nebo odstraní, a odpovídajícím způsobem aktualizuje jeho obsah. Doporučeným (a nejsnadnějším) způsobem použití ukládání do mezipaměti na disku je zvolit typ pracovního procesu se svazky SSD při konfiguraci clusteru. Tyto pracovní procesy jsou povolené a nakonfigurované pro ukládání do mezipaměti na disku.

  • Vyhněte se ukládání do mezipaměti Sparku

    Mezipaměť Sparku (pomocí .persist() a.unpersist()) může ukládat výsledek všech dat poddotazů a dat uložených ve formátech jiných než Parquet (například CSV, JSON a ORC). Pokud se ale použije v nesprávných umístěních v dotazu, může spotřebovat veškerou paměť a dokonce i výrazně zpomalit dotazy. Obecně platí, že pokud nevíte přesně, jaký dopad to bude mít , vyhněte se ukládání Sparku do mezipaměti .

  • Mezipaměť výsledků dotazu

    Ukládání výsledků dotazů do mezipaměti pro jednotlivé clustery pro všechny dotazy prostřednictvím SQL Warehouse. Pokud chcete využít ukládání výsledků dotazů do mezipaměti, zaměřte se na deterministické dotazy, které například nepoužívají predikáty, jako = NOW()je . Pokud je dotaz deterministický a podkladová data jsou ve formátu Delta a beze změny, sql Warehouse vrátí výsledek přímo z mezipaměti výsledků dotazu.

  • Ukládání uživatelského rozhraní SQL Databricks do mezipaměti

    Výsledkem ukládání všech dotazů a starších výsledků řídicího panelu u jednotlivých uživatelů do mezipaměti je uživatelské rozhraní SQL Databricks.

Použití komprimace

Delta Lake v Azure Databricks může zlepšit rychlost čtení dotazů z tabulky. Jedním ze způsobů je shodovat malé soubory do větších. Komprimace se aktivuje spuštěním příkazu OPTIMIZE. Viz Optimalizace rozložení datového souboru.

Delta Lake poskytuje možnosti pro automatickou konfiguraci velikosti cílového souboru pro zápisy a pro operace OPTIMIZE. Databricks automaticky naladí mnoho z těchto nastavení a umožňuje funkce, které automaticky zlepšují výkon tabulky hledáním souborů správné velikosti:

  • Automatické komprimování kombinuje malé soubory v rámci oddílů tabulky Delta, aby se automaticky snížily malé problémy se soubory. Automatické komprimace nastane po úspěšném zápisu do tabulky a synchronně se spustí v clusteru, který provedl zápis. Automatické komprimace zkomprimuje pouze soubory, které nebyly dříve komprimovány.
  • Optimalizované zápisy zlepšují velikost souboru při zápisu dat a výhodou následných čtení v tabulce. Optimalizované zápisy jsou nejúčinnější pro dělené tabulky, protože snižují počet malých souborů zapsaných do každého oddílu.

Další podrobnosti najdete v tématu Konfigurace Delta Lake pro řízení velikosti datového souboru.

Použití přeskakování dat

Přeskočení dat může výrazně zlepšit výkon dotazů přeskočením dat, která nesplňují kritéria dotazu. Tím se snižuje množství dat, která je potřeba číst a zpracovávat, což vede k rychlejší době provádění dotazů.

Abyste toho dosáhli, data se při zápisu dat do tabulky Delta automaticky shromažďují (ve výchozím nastavení Delta Lake v Azure Databricks shromažďuje statistiky o prvních 32 sloupcích definovaných ve schématu tabulky). Delta Lake v Azure Databricks používá tyto informace (minimální a maximální hodnoty) v době dotazu k zajištění rychlejších dotazů. Viz Vynechání dat pro Delta Lake.

Pro přeskočení dat je možné použít následující techniky:

  • Řazení podle Z-orderu, technika pro seskupování souvisejících informací ve stejné sadě souborů. Tato společné umístění se automaticky používá v Azure Databricks algoritmy pro přeskakování dat Delta Lake. Toto chování výrazně snižuje množství dat, která musí Delta Lake číst.

  • Liquid clustering zjednodušuje rozhodování o rozložení dat a optimalizuje výkonnost dotazů. V průběhu času nahradí dělení a pořadí vykreslování. Databricks doporučuje clustering liquid pro všechny nové rozdílové tabulky. Clustering Liquid poskytuje flexibilitu opětovného vytváření klíčů clusteringu, aniž byste museli přepisovat stávající data, což umožňuje vývoj rozložení dat s analytickými potřebami v průběhu času. Databricks doporučuje clustering liquid pro všechny nové rozdílové tabulky.

    Tabulky s následujícími vlastnostmi jsou přínosem pro shlukování kapalin:

    • Filtrované podle sloupců s vysokou kardinalitou
    • S výrazně nerovnoměrnou distribucí dat.
    • To rychle roste a vyžaduje údržbu a ladění úsilí.
    • Souběžné požadavky na zápis
    • S přístupovými vzory, které se v průběhu času mění.
    • Kde by typický klíč oddílu mohl opustit tabulku s příliš velkým nebo příliš malým počtem oddílů.

Další podrobnosti a techniky najdete v komplexní příručce k optimalizaci úloh Databricks, Spark a Delta Lake.

Povolení prediktivní optimalizace pro Delta Lake

Prediktivní optimalizace eliminuje potřebu ruční správy operací údržby pro tabulky Delta v Databricks. S povolenou prediktivní optimalizací databricks automaticky identifikuje tabulky, které by mohly těžit z operací údržby a spouští je pro uživatele. Operace údržby se spouštějí pouze podle potřeby, takže eliminují nepotřebná spuštění operací údržby a zatížení spojené se sledováním a řešením potíží s výkonem.

Vyhněte se nadměrnému dělení

V minulosti bylo dělení nejběžnějším způsobem, jak přeskočit data. Dělení je však statické a manifesty samotné jako hierarchie systému souborů. Vzhledem k tomu, že se vzory přístupu mění v průběhu času, neexistuje žádný snadný způsob, jak změnit oddíly. Dělení často vede k nadměrnému dělení – jinými slovy, příliš mnoho oddílů s příliš malými soubory, což vede k nízkému výkonu dotazů.

Databricks doporučuje, abyste tabulky pod velikostí 1 TB neposílali a že pokud očekáváte, že data v každém oddílu budou alespoň 1 GB, rozdělíte je jenom podle sloupce.

Do té doby je lepší volbou než dělení pořadí Z nebo novější clustering Liquid (viz výše).

Optimalizace výkonu spojení

  • Zvažte optimalizaci spojení rozsahu.

    Spojení rozsahu nastane, když jsou dvě relace spojeny pomocí bodu v intervalu nebo intervalu překrývající podmínky. Podpora optimalizace spojení rozsahu v Databricks Runtime může přinést řádové zlepšení výkonu dotazů, ale vyžaduje pečlivé ruční ladění.

  • Použijte adaptivní spouštění dotazů.

    Adaptivní provádění dotazů (AQE) představuje opětovnou optimalizaci dotazů, ke které dochází během provádění dotazů. Má 4 hlavní funkce:

    • Dynamicky se mění sloučení spojení sloučení do spojení hash všesměrových přenosů.
    • Dynamicky sluhuje oddíly po výměně náhodného prohazování.
    • Dynamicky zpracovává nerovnoměrnou distribuci spojení sloučení řazení a shuffle hash join.
    • Dynamicky rozpoznává a šíří prázdné relace.

    Doporučujeme nechat AQE povolené. Různé funkce je možné konfigurovat samostatně.

Další podrobnosti najdete v komplexní příručce pro optimalizaci úloh Databricks, Spark a Delta Lake.

Spuštěním analýzy tabulky shromážděte statistiky tabulky.

Příkaz ANALYZE TABLE shromažďuje statistiky o tabulkách v zadaném schématu. Tyto statistiky používá optimalizátor dotazů k vygenerování optimálního plánu dotazu, výběru správného typu spojení, výběru správné strany sestavení ve spojení hash nebo kalibraci pořadí spojení ve vícecestovém spojení.

Prediktivní optimalizace automaticky spouští příkaz pro shromažďování statistik ANALYZE (Public Preview) ve spravovaných tabulkách Katalogu Unity. Databricks doporučuje povolit prediktivní optimalizaci pro všechny spravované tabulky Katalogu Unity, aby se zjednodušila údržba dat a snížily náklady na úložiště. Vizte prediktivní optimalizace pro tabulky spravované pomocí Unity Catalogu.

4. Spouštění testování výkonnosti v oboru vývoje

Testování na základě zástupce produkčních dat

Spusťte testování výkonu na produkčních datech (jen pro čtení) nebo podobných datech. Při použití podobných dat by měly být charakteristiky, jako je svazek, rozložení souborů a nerovnoměrná distribuce dat, podobné produkčním datům, protože to má významný dopad na výkon.

Zvažte předběžné vytváření prostředků.

Bez ohledu na formát dotazu a dat je první dotaz v clusteru vždy pomalejší než následné dotazy. Důvodem je to, že se spouští všechny různé subsystémy a čtou všechna potřebná data. Prewarming má významný dopad na výsledky testů výkonnosti:

  • Předwarmové clustery: Prostředky clusteru je potřeba inicializovat na více vrstvách. Clustery je možné předem připravit: Fondy Databricks jsou sadou nečinných instancí připravených k použití. Při vytváření uzlů clusteru pomocí těchto nečinných instancí se sníží doba spouštění clusteru a automatického škálování.
  • Předwarm mezipaměti: Při ukládání do mezipaměti je součástí instalace, první spuštění zajistí, že data jsou v mezipaměti a urychlí následné úlohy. Mezipaměti můžou být předem připravené spuštěním konkrétních dotazů pro inicializaci mezipamětí (například po restartování clusteru). To může výrazně zlepšit výkon prvních několika dotazů.

Abyste tedy pochopili chování různých scénářů, otestujte výkon prvního spuštění s předpřipravením a následnými spuštěními.

Identifikace kritických bodů

Kritické body jsou oblasti ve vaší úloze, které by mohly snížit celkový výkon při nárůstu zatížení v produkčním prostředí. Identifikace těchto úloh v době návrhu a testování na vyšších úlohách pomůže udržet úlohy stabilní v produkčním prostředí.

5. Monitorování výkonu

Monitorování výkonu dotazů

Monitorování výkonu dotazů vám pomůže pochopit, jak se prostředky používají různými dotazy. Můžete identifikovat dotazy, které běží pomalu, což vám umožní určit kritické body výkonu ve vašem systému. Můžete také identifikovat dotazy, které spotřebovávají významné systémové prostředky, což může vést k nestabilitě nebo výpadku. Tyto informace vám pomůžou optimalizovat přidělování prostředků, snižovat plýtvání a efektivně využívat prostředky.

Platforma Databricks Data Intelligence má různé možnosti monitorování (viz Efektivita provozu – Nastavení monitorování, upozorňování a protokolování), z nichž některé se dají použít k monitorování výkonu:

  • Profil dotazu: Funkce profilu dotazu slouží k řešení potíží s kritickými body výkonu během provádění dotazu. Poskytuje vizualizaci jednotlivých úloh dotazů a souvisejících metrik, jako je čas strávený, počet zpracovaných řádků a využitá paměť.
  • Monitorování SLUŽBY SQL Warehouse: Monitorování skladů SQL zobrazením živé statistiky, grafy počtu dotazů ve špičce, spuštěnými grafy clusterů a tabulkou historie dotazů

Monitorování úloh streamování

Monitorování streamování umožňuje analyzovat data a zjišťovat problémy při jejich výskytu a poskytovat přehledy o výkonu a chování systému v reálném čase. Analýzou streamovaných dat můžete identifikovat trendy, vzory a příležitosti pro optimalizaci. To vám může pomoct vyladit systém, zlepšit využití prostředků a snížit náklady.

Pro dotazy streamování použijte integrované monitorování strukturovaného streamování v uživatelském rozhraní Sparku nebo nasdílejte metriky externím službám pomocí rozhraní naslouchacího procesu Dotazů streamování Apache Spark.

Monitorování výkonu úloh

Monitorování úloh pomáhá identifikovat a řešit problémy v úlohách Databricks, jako jsou selhání, zpoždění nebo kritické body výkonu. Monitorování úloh poskytuje přehled o výkonu úloh, díky čemuž můžete optimalizovat využití prostředků, snížit fázi a zlepšit celkovou efektivitu.